I recently reinstalled Solus 4.3, this time specifying a swap partition equal to the size of my RAM, with the plan of enabling Hibernation because I'm running it on a laptop and I consider Hibernation to be a make-or-break feature for portable computing. The installation went fine, I edited /etc/default/grub to include the UUID of the swap partition in the GRUB_CMDLINE_LINUX_DEFAULT setting, and then I Hibernated my laptop to test the configuration. It appeared to work, but I got a black screen with a blinking cursor on startup, and the Resume never completed. Oh well, I rebooted...and it tried to Resume again. And again. And again.
Eventually I had a lightbulb moment and edited the GRUB entry to remove the UUID of the swap partition, and Solus booted successfully. So I removed the UUID from /etc/default/grub, and then ran update-grub to write the new settings into /boot/grub/grub.cfg. I rebooted...and it tried to Resume from the swap partition again! I edited the GRUB entry again and got back into Solus, and when I examined /boot/grub/grub.cfg I saw that the UUID of the swap partition hadn't been removed when I ran update-grub. I double-checked /etc/default/grub and confirmed that I had saved my previous edit, so the UUID of the swap partition was no longer present, and I ran update-grub again. I checked /boot/grub/grub.cfg, and the UUID of the swap partition was still in there! So I ran install-grub instead. That made no difference either!
Then I edited /boot/grub/grub.cfg manually, saved the changes, reopened the file to make sure the changes were saved, and then ran update-grub again, to see if update-grub just wasn't doing anything at all. The UUID of the swap partition had been reinserted into /etc/grub/grub.cfg! Now I was pissed. I deleted the swap partition entirely, created a new partition, zero-filled it to erase any trace of the previous partition, then deleted the new partition too, so all that was left was a bunch of zeroes on the disk, to make sure there was no way any automated script could possibly be detecting the swap partition and inserting it into /boot/grub/grub.cfg against my will. That made no difference either. (I didn't think it would, but I wanted to be thorough.)
Finally I had another lightbulb moment and I examined the files in /etc/grub.d, and I found the UUID for the now-deleted swap partition hard-coded into /etc/grub.d/10_com.solus-project! This is not how the /etc/grub.d files are supposed to work; when I run update-grub, any changes I made to /etc/default/grub are supposed to be propagated everywhere else they need to go.
All of this doesn't solve my original problems:
1) Resume from Hibernate failed, and ;
2) Solus wouldn't stop trying to Resume after a single failed attempt;
...but the fact that old settings were hardcoded into /etc/grub.d files and overlooked by update-grub sure made it a lot harder to get back to an OS that would at least reliably boot-up.
If update-grub is supposed to update the files in /etc/grub.d, then that functionality needs to be fixed. If those files aren't supposed to be updated by update-grub, then they need to not have UUIDs hard-coded into them during initial setup. And finally, if anyone has any suggestions on how to make Hibernate/Resume work correctly, I'd appreciate it. Solus seems like a nice clean Linux distro, but I can't keep using it if Hibernate/Resume doesn't work. Lack of support for this feature is also not a viable option, because every major paid OS supports it and so do most of the Linux distros I've tried (Fedora, openSUSE, Manjaro, *ubuntu, even Salix).
