Sometimes, when my laptop running Fedora workstation resumes from hibernation, I encounter weird bugs that resolve with a reboot which I have suspected may be due to the system booting into a newer kernel than what was running when the system entered hibernation. Am I correct that this is likely to cause bugs, and if so, do Fedora atomic distros avoid this problem altogether?
Hibernation or suspend?
In neither case should a laptop load a different kernel than was operating when activity ceases. With suspend activity ceases but the kernel remains in RAM as does all app data. With hibernation AFAIK the kernel running at the time of hibernation resumes action.
There may be (possibly) a difference when resuming from hibernation in the case where a newer kernel was installed but never booted before placing the machine in hibernation and the system always tries to boot the newest kernel.
I would be more liable to believe this is related to a system where updates are performed but the updated apps were never restarted so resuming from hibernation may try to start the older version of that app but only the newer libraries are available and could (potentially) cause weird behavior. In that case, pages cached in swap might also be the cause
In both cases it is always advisable after performing updates to reboot the system before either suspend or hibernation.
1 Like
When it resumes from hibernation it’s either restoring memory as it was when it was hibernated, or it’s been in sleep, in which case it’s the same memory contents in RAM anyway.
There is no way you can go to sleep running kernel X and resume using kernel Y.
1 Like
Oh interesting. When it boots back up from hibernate, it presents me with a list of kernels to select. There have definitely been times when the most recent kernel, which it defaulted to, was not the one I was running when it hibernated. But I just tested it and even if you select the most recent one (6.18.13 in my case), if you run uname -r, it reports that the previous kernel (6.18.12) which was running before the system hibernated is actually the one currently running. Kind of odd that it presents users with the kernel select screen even thought it apparently ignores the selection.
I feel like I have definitely had to restart certain apps due to buggy behavior like this when they get updated in the background, but I thought that the kernel was the only software that requires a reboot for the update to actually get implemented.
That does not sound like it’s hibernating - it sounds like it’s a straight reboot from cold.
When a system hibernates it dumps the entire contents of RAM into a file on disk. When it re-awakens, it reloads that file and applies it to RAM (effectively). This is how it starts running exactly what you had running when it hibernated, down to the file you had open, changed and had not yet saved. Unplug the power, leave it off for a month and then turn it back on again and you should go straight to how it was when you hibernated.
It is hibernating though. It resumes my system just as it was previously with all my apps exactly as they were, including unsaved files etc.
Right, but break down what happens when you turn the machine back on again.
- Firmware starts booting up as usual
- (On most Linux systems) that takes you into GRUB
- The user selects a GRUB command line (or allows the default one)
- The GRUB command line passes the kernel parameter
resume=, which tells the initramfs that it should look for a previously suspended session on the given swap partition - Initramfs initiates the restore-from-hibernate if appropriate
I don’t know all the ins and outs here but it seems not inconceivable that booting into a kernel/initramfs version different from what was running in the suspended session could cause some wrinkles?
Background updates are often misunderstood and users can ignore them at their own peril.
It is always best in all cases when updating a kernel to reboot, and when updating an app to always restart that app. There are some things beyond the kernel that also always require a reboot.
1 Like
In this case it would not matter what kernel you picked from Grub - it would be overwritten with the contents of the hibernation file. All you’re effectively doing is “pick anything to get past this grub screen” and supplying an “Enter”, all of which is overwritten with whatever the hiber file contains.
Edit: which is basically what the Op states in his “But I just tested it and even if you select the most recent one (6.18.13 in my case), if you run uname -r, it reports that the previous kernel (6.18.12) which was running before the system hibernated is actually the one currently running.”
1 Like