Kernel upgrades without reboot break resume from hibernation

Thanks for your bug report. With which particular version of the kernel did you test this with? Thanks in advance.

applies to all versions.

You cannot do any dist-upgrade or update-manager kernel upgrade, hibernate and resume. GRUB picks the new kernel (which won't read the suspend image) instead of the old one which can.

I've also been annoyed by this for quite a while... Here are some of the solutions I thought of:

- Insist on rebooting after a kernel upgrade. This is indeed the only time where rebooting is really needed (in comparison to another well-known OS where it is a common habit...). If the user declined, offers to remind her periodically (maybe a Gnome/KDE applet would be a good way to do it - as when there are updates available).
- Before doing a Hibernate, check whether a kernel upgrade occurred. In that case, options are:
  - Remind the user that on next boot, she should choose the XXX line in GRUB.
  - Offer the user to do a shut-down instead,
  - If GRUB is configured to boot with "default saved", change the default to the currently used kernel.
  - Change GRUB to have no time-out...

Note that if Hibernate is mostly used on laptops, it can also be used with desktops. So having different behaviours based on laptop/desktop detection doesn't sound good to me.

Another idea:
I don't know how this is done, but when the kernel boots it can detect if hibernate was used instead of plain shutdown. So maybe it could also detect if the swap contains a hibernate image from another kernel version. In that case, it should present the user with the following options:
- continue booting and lose the previous hibernate (with a big, fat warning),
- continue booting and don't use that swap partition,
- stop booting (and return to grub through a reboot).

Since the consequences of that problem are similar to a "hard reboot" with configuration/data of all opened windows/programs being lost, I'd vote for the importance of this bug being rated as HIGH.

I added the linux-source package as well in hope this will make things move and since the solution could be at that level...

Please include the following additional information, if you have not already done so (please pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.

For your reference, the full description of procedures for kernel-related bug reports is available at [WWW] http://wiki.ubuntu.com/KernelTeamBugPolicies. Thanks in advance!

it's due to booting the NEW kernel which won't resume from the state written by the OLD kernel.

The fix is to boot the old kernel instead if there's an image to be restored.

Jérôme this bug isn't related to a given version of the kernel. However I can still answer the uname request:
Linux dell630 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

On the other hand, the 2 remaining requests are absolutely not relevant. The problem is neither hardware related nor a bug per se. It is just that it would be really, really nice to be reminded -in one way or another- when you resume from a suspend to disk to select in GRUB the previous kernel. Up to now, the new kernel version silently ignores the swapped memory and the plain result is very similar to a hard reset.

At the kernel level, it'd be nice to have a "safe_resume" option that, when present, would stop the kernel from loading if a resume image is present in swap partition and versions don't match.

This isn't a bug as much as a feature request. Anyway, a proper entry in the bugzilla.kernel.org would be adviceable as this isn't a Ubuntu specfic issue

I don't see how a situation that causes data loss with the simple act of hibernate/resume is a feature request...

It would work to just update the default kernel for grub in the shutdown scripts instead of on package upgrade.

As Erik suggested, it'd be good indeed to create an entry in bugzilla.kernel.org.

Anyone having an account there?

My system has just experienced an "oops" and a kernel panic upon resume from hibernation; I think this bug might have caused it. My caps and scroll-lock LEDs are flashing but the suspended session came up anyway and the system is, amazingly, still running. The relevant dmesg output is attached. The kernel version is:

2.6.22-9-generic #1 SMP Fri Aug 3 00:20:35 GMT 2007 x86_64 GNU/Linux

edschofield - your bug report is actually about a different issue and is most likely a duplicate of bug 129226 which should be fixed with the next kernel update.

how does one downgrade from a kernel update?

say go from 2.6.20-16.32 back to 2.6.-16.31 (after I inadvertently apt-get clean'ed)...where can I find the *debs?

I need a working suspend

I can confirm that it is annoying when trying a resume after a kernel update. I had to deinstall uswsusp and hibernate before my Thinkpad started again. Afterwards the swap partiton was not readable and had to be reformatted. I propose to prevent a hibernate or suspend to RAM after updating the kernel.

Still here in Gutsy. I've just fallen prey to this myself and the system has to do a regular boot (and open partitions have to be fixed up) due to the change in the kernel version.

This also mildly ties into Bug #3221 . Until grub is set to automatically boot the old kernel when hibernating, I think that hibernation should be disabled with an explanation until the system is rebooted after a kernel upgrade.

Can someone test with the latest Hardy Alpha release and verify this is still an issue? http://www.ubuntu.com/testing . We'll keep this report open against the actively developed kernel bug against 2.6.20 this will be closed. Thanks.

Leann:
It's going to still be there - to the best of my knowledge there hasn't been any change to the way Ubuntu deals with old kernels (it removes them) nor a change to when hibernation is possible.

I can confirm that this, let's call it 'misbehaviour', still exists in Hardy Heron Alpha 6.
As mentioned by Sitsofe, old kernels are removed automatically, so it isn't possible to just set GRUB to boot the old kernel automatically. But keeping backups of kernels all the time isn't a nice solution either.

What would be possible is a simple if-clause in /usr/lib/hal/scripts/linux/hal-system-power-hibernate-linux

8a9,12
> if [ -f /var/run/reboot-required ] ; then
> unsupported
> fi
>

That definitly isn't the nicest way of doing it, but it works and prevents the user from accidently hibernating and crashing all his data.

Despite that, suspend isn't related to this issue at all, as far as i know, as long as it is plain suspend and not hybrid mode. Suspend doesn't even unload the kernel or load a new kernel.

I can confirm that this still exists in Hardy. Even though I don't think they are necessary I have included the Kernel's team requested files for reporting a Kernel bug.
This bug relates to the way Ubuntu chooses to do updates.

The computer system should strive to follow the user's intent in the system, if the system has hibernated successfully in the past then the user intends for it to hibernate when pressing the hibernate button. The user expects that the system will boot correctly after resuming from the hibernation. Any behavior that deviates from that expectation violates the user's expectation and reflects negatively on Ubuntu. The way I see it there are a few possible fixes to this issue:

1- Do not allow the hibernation feature if the kernel has been upgraded and the system is currently running the old kernel. Advise the user to suspend or shut down instead.
2- During hibernation, temporarily force grub to boot into the kernel the system is currently running on next boot. This way the hibernation will work as expected.

Fix #1 will annoy users, but seems like it might be easier to implement then fix #2. Of course, with fix #2, if the user always chooses to hibernate and never shuts down or restarts the computer then the user will always have an out of date kernel version. Thus, the current icon saying a restart is required to update the computer would probably need to be present to remind the user.

$ uname -a
Linux ubuntu-desktop 2.6.24-18-386 #1 Wed May 28 19:30:01 UTC 2008 i686 GNU/Linux
$ cat /proc/version_signature
Ubuntu 2.6.24-18.32-386

The kernel's postinst script already provide a way to prevent hibernation:

# Let programs know not to hibernate if the kernel that would be used for
# resume-from-hibernate is likely to differ from the currently running kernel.
system("mountpoint -q /var/run");
if ($? eq 0) {
        system("touch /var/run/do-not-hibernate");
}

I therefore think that this bug is actually in the gnome UI and/or the hibernate script, which both ignores the file created by the kernel and allow the user to hibernate the system anyway.

I'm adding hal as affected as well. According to comment 21, the behaviour could also be fixed by applying the patch included in the comment.

Fixing this bug *somewhere* should really be possible now.

the bug is not a gnome-panel one

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Problem persists in intrepid. Seems to be the best of all possible options is:
1) Whenever you hibernate, save a copy of the grub menu.lst to a backup location
2) Change menu.lst to boot the currently running kernel by default, with a label simply reading "Resume from Hibernation".
3) If possible, add a warning message to the grub menu that booting any other option will result in a loss of the hibernated state
4) On resume from hibernation, restore the backup menu.lst from step 1.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

It's also been filed against redhat. https://bugzilla.redhat.com/show_bug.cgi?id=451266

Since it's pretty easy to have a complete loss of data, shouldn't this be a significantly higher importance?

Certainly when a system automatically hibernates because its power source is depleted, and then resumes when the power is restored, if there has been a new kernel update, the system will boot the wrong kernel, and consequently lose all data in the running system.

The Red Hat bug is somewhat different as I believe they keep more old kernels around than Ubuntu. A broken resume from hibernate rarely results in complete data loss as the kernel buffers are usually flushed before the computer is hibernated. It's about as bad as doing as resetting after having run sync and having watied for it to finish.

You're assuming the user has attempted to save before hand. Data in memory that hasn't been written to disk is gone.

I think this bug should also have a Grub task, since most probably it will be Grub's responsibility to check the kernel's version and boot the correct kernel to not lose the hibernated state.