Axios I made the decision to use UEFI and disable CSM on all my computers, and use GPT formatting on all drives in my computers, several years ago. I will not install any OS that is not fully compatible with UEFI, period. If an OS is that far behind the curve, I don't trust it not to be behind the curve in other important respects.

That sounds very dogmatic, I know. However, for the reasons explained in the article you posted, UEFI handles multi-boot, single-OS-per-disk setups more reliably than BIOS, in my opinion, and I have not had an issue with multi-boot on any of my computers since becoming hard-nosed about UEFI-only and following the single-OS-per-disk convention.

      Axios Not sure in my mind why installing kde solved your issue or just the way they install something I got to think on awhile.

      I wonder, too. It seems to me that the Solus, rather than either DE, controls the boot process, in the sense that whatever happens during the boot process to access the defective Hitachi drive precedes activation of either DE, so there should be no difference.

      Specifically, I wonder whether the Budgie issues would have been resolved by a clean -- that is, wipe the entire drive and start over from scratch -- installation of Budgie. I can't think of a reason why Budgie would try to access the defective Hitachi drive during boot and KDE would not.

      But speculating is water over the dam because the system is now working until the Hitachi blows up and causes the next problem.

          7 months later

          I don't mean to bump this thread but I also seem to be running into the same issue as a new user 😅
          I'm running Solus KDE on my desktop and using a 2tb Seagate SSD, with Solus being the only OS on it yet it takes about a minute and a half to get from bios to login screen. I've got a newer system with a Ryzen 5600x, where Windows on a different SSD only takes a few seconds to boot. I put Solus Budgie on my laptop as well and it boots in 8 seconds or less while being the only OS on the SSD there. I was able to run those logs the other day and see quite a few red and yellow lines throughout, but I'm not entirely sure what they mean. It doesn't seem like the forums like me uploading the logs as .txt files or .pdfs, so what would be the best way to share those?

          If someone could run the following it'd be really helpful for troubleshooting exactly what's taking so long.

          sudo journalctl -b0 --no-pager > boot.log
sudo systemd-analyze blame --no-pager > blame.log

          And then upload those to hastebin or something. You should skim your boot.log for anything sensitive that you might want to redact before doing this.

            Looks like this is the issue:

            Dec 01 04:39:55 solus systemd-journald[281]: Journal stopped
Dec 01 11:40:20 sw0leypc systemd-journald[281]: Received SIGTERM from PID 1 (systemd).

            There's a 25 second gap there which is interesting. I wonder if it has to do with the time change, usually that kind of clock change is caused because Windows stores the time in the hardware clock in local time while Linux stores it in UTC time. Does this issue happen only when you boot into Solus directly after using Windows? Does it happen if you shutdown from within Solus and then boot back in to Solus on the next boot?

            I'd recommend taking a look at the instructions here and following the "Make Windows use UTC" steps.