This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 202410 - Kernel mismatch discards resume info
Kernel mismatch discards resume info
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-14 04:43 EDT by Gianluca Sforna
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-28 16:02:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Gianluca Sforna 2006-08-14 04:43:08 EDT
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 14:17:15 EDT
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 17:56:26 EDT
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 01:04:20 EDT
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 12:45:59 EDT
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.
Comment 5 Daniel Walsh 2006-09-19 13:07:34 EDT
Fixed in selinux-policy-2.3.14-4

Will update in next release.
Comment 6 Daniel Walsh 2007-03-28 16:02:33 EDT
Closing bugs

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