Bug 202410 - Kernel mismatch discards resume info
Summary: Kernel mismatch discards resume info
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2006-08-14 08:43 UTC by Gianluca Sforna
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2007-03-28 20:02:33 UTC

Attachments (Terms of Use)

Description Gianluca Sforna 2006-08-14 08:43:08 UTC
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?

Comment 1 Dave Jones 2006-08-14 18:17:15 UTC
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".

Comment 2 Gianluca Sforna 2006-08-14 21:56:26 UTC
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?

Comment 3 Dave Jones 2006-08-15 05:04:20 UTC
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.

Comment 4 Gianluca Sforna 2006-09-18 16:45:59 UTC
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
Sep 18 18:37:34 hal9001 avahi-daemon[1990]: Withdrawing address record for on eth0.
Sep 18 18:37:34 hal9001 dhclient: DHCPRELEASE on eth0 to 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
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.

Comment 5 Daniel Walsh 2006-09-19 17:07:34 UTC
Fixed in selinux-policy-2.3.14-4

Will update in next release.

Comment 6 Daniel Walsh 2007-03-28 20:02:33 UTC
Closing bugs

Note You need to log in before you can comment on or make changes to this bug.