Hello all,

I open this discussion to tell you my (bad) experience with Solus updates.

Yesterday, as every friday, I launched Solus Software Center and updated my packages.
I reboot -> black screen.
I tried the usual stuff like described in Solus Boot Rescue with no luck. In the end I fixed the problem by reverting to a previous update using eopkg history (that's a great feature!).

Back in my system I run
sudo eopkg check | grep Broken | awk '{print $4}' | xargs sudo eopkg it --reinstall
then I update again (via sudo eopkg upgrade this time), but before rebooting I also run
eopkg check to check if all went well and... I find many new broken packages.
I run the reinstall script again, reboot and now it is all fine.

However a package manager that breaks so easily is really a pain as I had this kind of problems a few times and I've not used Solus for long (less than 2 months).
Now, for me it's a lesson learned and I will always check package integrity after an update, but wouldn't it be wiser to run it automatically, at lease when updating via GUI?

    Lahiri I have no such issues, no broken packages and no boot issues. So maybe some specific package is causing the issue? Agee that it should not happen, but don't think it's a general issue of eopkg. In the past I had also issues on Ubuntu/debian systems with apt, so nothing is perfect.

      This for example is screenshot of the packages that were broken after my last update:

      I have no idea why this happens tbh. May it be related to unstable network? However I never have problems when I download from other sources.

        Lahiri No, it wouldn't install a "broken" package because the shasums for the files and package wouldn't match the index to begin with.

        Some of those may report as broken if they're modifying their files, modifying /var or other places, etc. since the file hashes are different. Common with udev, as an example, and doesn't necessarily mean the packages are broken.

        If you are having issues with lightdm then journalctl from the last boot, Xorg log, etc. are needed otherwise we're just speculating.

          Lahiri I run the reinstall script again, reboot and now it is all fine.

          Are you already aware of the occasional problem with the RIT servers being too busy and timing out before a set of downloads is completed? Is it possible you only got most of the upgrades the first time?

          When that happens, it's okay to press Ctrl+C to stop the process without waiting for the timeout to finish, and start the update process again. It will quickly return to the point where it stopped, and begin downloading again. Sometimes that's not needed at all, and sometimes it's needed more than once if the servers are really busy. But if that IS the problem you had, there's no need to do anything but restart the process.

          I think a quick recovery like that is one of eopkg's best features. The Solus team doesn't control the servers at RIT, so occasional timeouts aren't a problem they can resolve.

          If you already knew about this issue, and you're sure that's not the current problem, perhaps someone can think of another cause. That's all that occurs to me.

              WetGeek I also had the problem with the timeout today, I stopped the process and tried again later then everything went through. I always do updates with the terminal

                  putzerstammer I stopped the process and tried again later

                  You don't even need to wait and try again later. Every time it's hung for me, I've restarted immediately, and it's always worked. Yes, updating at the terminal is the best way to do it by far.

                      Lahiri I'm not quite sure why (maybe it has something to do with what @JoshStrobl explained) but these same packages are reported as broken on my system if you run the check without admin privileges (eopkg check rather than sudo eopkg check). And I've never had any issues in over 2 years with said packages). So I feel pretty confident that it's more of an issue of what the check reports as broken, rather than what is indeed broken.

                      As for the root cause of your black screen issue, I feel that @WetGeek and @putzerstammer already provided a likely explanation.

                          WetGeek Yes, updating at the terminal is the best way to do it by far.

                          without question.

                            nathanpainchaud but these same packages are reported as broken on my system if you run the check without admin privileges (eopkg check rather than sudo eopkg check). And I've never had any issues in over 2 years with said packages). So I feel pretty confident that it's more of an issue of what the check reports as broken, rather than what is indeed broken.

                            yeah some of these are known 'false positives'. I totally forgot about the privileges thing regarding CHECK. I will stick that back in my brain!

                              Yep @nathanpainchaud hit the nail on the head. You need to use sudo eopkg check.

                              The OP has false positives due to not running the command with sufficient privileges to assess the integrity of every file in every package installed. Which is why the documentation shows it being used with sudo

                              Example:

                              eopkg check gvfs

                              Checking integrity of gvfs    Broken
Missing file: /usr/share/polkit-1/rules.d/org.gtk.vfs.file-operations.keyrules
Missing file: /usr/share/polkit-1/rules.d/org.gtk.vfs.file-operations.rules

                              sudo eopkg check gvfs

                              Checking integrity of gvfs    OK