Description of problem: In case of a mismatch between the suspended kernel version and the one currently booting, the behaviour is to drop the resume information and make a normal boot. Steps to Reproduce: 1. Update the kernel 2. suspend the machine 3. resume (forgetting to select the older kernel on grub...) Actual results: The suspended session is lost Expected results: Anything else... My preferences would be (from most to least ideal): 1. Detect the correct one and boot it instead 2. Ask the user if it is ok to discard the resume info 3. Warn the user about the problem and stop boot Alternatively, could the suspend routine check in grub.conf if it is going to be resumed with the same kernel version and warn about it?
When we suspend we set the kernel to boot into in grub.conf to be the same as the one running. If you then choose a different one, there's not much we can do about that. We can't really ask the user anything at this stage because we'd need to do this from kernel-space, where we have no user input at all. And stopping the boot in this situation is guaranteed to annoy someone who prefers the current behaviour. There's not much we can do here really other than to suggest "don't do that".
Thanks for the prompt reply. The point is (sorry if the report was not clear enough on this) I __did not__ choose by hand another kernel upon boot, it just started with a grub timeout. I assumed the step "set the kernel to boot into in grub.conf to be the same as the one running" was not there because the resume did not worked right after a kernel update. Now, either I stepped on a bug in the procedure, or I am doing something wrong. I have an hand edited grub.conf here, since I don't use rhgb and I like vga=791: could this cause what I saw?
Shouldn't make any difference. The only thing that gets changed is the 'default' line. This is done by pm-utils, so I'll reassign there for now, hopefully someone else has some idea why that didn't work for you.
ok. after the last kernel update I think I found the culprit; here is (part of) the kernel log upon suspend: Sep 18 18:37:33 hal9001 gnome-power-manager: Hibernating computer because the DBUS method Hibernate() was invoked Sep 18 18:37:33 hal9001 NetworkManager: <information> Going to sleep. Sep 18 18:37:34 hal9001 avahi-daemon[1990]: Interface eth0.IPv4 no longer relevant for mDNS. Sep 18 18:37:34 hal9001 avahi-daemon[1990]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.99. Sep 18 18:37:34 hal9001 avahi-daemon[1990]: Withdrawing address record for 192.168.1.99 on eth0. Sep 18 18:37:34 hal9001 dhclient: DHCPRELEASE on eth0 to 192.168.1.2 port 67 Sep 18 18:37:34 hal9001 dhclient: send_packet: Network is unreachable Sep 18 18:37:34 hal9001 dhclient: send_packet: please consult README file regarding broadcast address. Sep 18 18:37:34 hal9001 named[3482]: D-BUS: dhclient for interface eth0 released lease - removing forwarders. Sep 18 18:37:35 hal9001 kernel: audit(1158597455.579:5): avc: denied { write } for pid=21051 comm="grub" name="stage2" dev=hda2 ino=20166 scontext=system_u:system_r:bootloader_t:s0 tcontext=system_u:object_r:boot_runtime_t:s0 tclass=file Sep 18 18:37:40 hal9001 ntpd[1889]: ntpd exiting on signal 15 Sep 18 18:38:52 hal9001 kernel: Stopping tasks: ======================================================================================================================| So chances are this could be reassigned to selinux-policy.
Fixed in selinux-policy-2.3.14-4 Will update in next release.
Closing bugs