[Bug 223722] New: Resume from suspend to disk fails after kernel upgrade
https://bugzilla.novell.com/show_bug.cgi?id=223722 Summary: Resume from suspend to disk fails after kernel upgrade Product: openSUSE 10.2 Version: RC 1 Platform: i686 OS/Version: SuSE Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: james@usr-local-bin.org QAContact: qa@suse.de I upgraded to RC1 from the Factory tree. The new kernel image was added to the GRUB menu, at the bottom of list although it was set, correctly, to be the default. This is fine for a simple boot. However, when I then suspended the laptop and booted it back up, it booted the failsafe system. When I moved the new kernel image to the top of list (changing no other settings), rebooted and then suspended again, it resumed fine. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #1 from rmyster@gmail.com 2006-11-26 07:33 MST ------- You didn't mention what you upgraded from but you may want to note that the suspend utilty has changed from 10.1 to 10.2. Read the release notes under New Power Management Options. Also make sure you have suspend enabled in yast power management under the suspend permissions. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 james@usr-local-bin.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED ------- Comment #4 from james@usr-local-bin.org 2006-11-28 09:43 MST ------- Created an attachment (id=107241) --> (https://bugzilla.novell.com/attachment.cgi?id=107241&action=view) tarball of files requested Here's the files requested, with the exception of /var/run/pm-suspend which doesn't exist on my system at the moment for some reason. The version information is: riggwelter:~ # rpm -q powersave pm-utils suspend dbus-1 hal powersave-0.15.10-3 pm-utils-0.20.0.20061114-5 suspend-0.50-6 dbus-1-1.0.0-7 hal-0.5.8_git20061106-18 riggwelter:~ # uname -r 2.6.18.2-31-default -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 duwe@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|duwe@novell.com |seife@novell.com ------- Comment #5 from duwe@novell.com 2006-12-01 03:47 MST ------- Stefan, can you please have a look and reassign it accordingly? This is unlikely a grub problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 seife@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fseidel@novell.com, hmacht@novell.com, | |seife@novell.com, duwe@novell.com AssignedTo|seife@novell.com |jplack@novell.com ------- Comment #6 from seife@novell.com 2006-12-01 06:00 MST ------- Yes, that's a problem with the "select the kernel to boot on resume"-code in pm-utils (it was the same code in powersaved in former times). It selects the first matching kernel (which is in your non-working case the failsafe kernel), and i do not know how i should fix this. I think the guys who rewrite the menu.lst and move the default entry to be the last entry in the list screwed up here. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #7 from jplack@novell.com 2006-12-01 07:38 MST ------- The list is not screwed up. It's correct always. Anybody could do that. And he should be on the save side. Let's get back to cooperation. Have to find a way to remember what has been booted for resume to work again. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #8 from fseidel@novell.com 2006-12-01 09:00 MST ------- IMHO that not as easy as it looks in the first place: e.g. what if the user added some options manually when booting (which of course wont be reflected in grubs menu.lst). In this case even comparing currently used options (out of /proc/cmdline e.g.) with all grub menuentries wont work. Without grub writing somewhere which exact entry was used for currently running kernel, this cannot be done in a fully stable and transparent way. And as failsafe kernel was always (up to now) the last entry for the current kernel we had a special (at least implicit) arrangement of kernels in the grub list so the selection could work. If we give this up now for having some more freedom, we need it to be detectable in a comprehensible way (e.g. by grub writing the indexnumber). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #9 from seife@novell.com 2006-12-01 09:30 MST ------- But the index number probably will change if i install an additional kernel or something like that. I noticed that i had, on my 10.2RC2: OpenSUSE 10.2 Windows (i'm not sure if there was a failsafe entry) After updating via yast->system update, i have Windows Kernel-2.6.18.2-34-default Which is why i did not notice the bug yet: if there was a failsafe entry before, it is gone now, so it cannot interfere with resume. But why is there no "openSUSE 10.2" entry anymore as the first entry as it was in RC2? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #10 from fseidel@novell.com 2006-12-01 19:53 MST ------- Just to make this fully clear: do we talk about (the sequence) kernel update, suspend and resume or kernel update, reboot, suspend and resume? If we get a reboot after the kernel update the index number will hence change, but if grub reports the last used index this should always work. Of course if you suspend directly after the kernel update (without reboot) this'll still be tricky. But do we really support resuming with a updated kernel a image created with the old one? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #11 from james@usr-local-bin.org 2006-12-02 05:15 MST -------
Just to make this fully clear: do we talk about (the sequence) kernel update, suspend and resume
not this one
or kernel update, reboot, suspend and resume?
this one -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #12 from seife@novell.com 2006-12-02 15:29 MST ------- (In reply to comment #10)
Just to make this fully clear: do we talk about (the sequence) kernel update, suspend and resume
no. In this case we won't suspend, since we know we cannot resume.
or kernel update, reboot, suspend and resume?
I was thinking about "boot, install 5 additional kernel versions, suspend". As the entries in menu.lst seem to be random, i would not bet that the index is still correct :-)
Of course if you suspend directly after the kernel update (without reboot) this'll still be tricky. But do we really support resuming with a updated kernel a image created with the old one?
No, the changed kernel won't even be able to resume. That's why we refuse to suspend in this case. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
(In reply to comment #10)
Just to make this fully clear: do we talk about (the sequence) kernel update, suspend and resume
no. In this case we won't suspend, since we know we cannot resume.
or kernel update, reboot, suspend and resume?
I was thinking about "boot, install 5 additional kernel versions, suspend". Well, then this scenario is as well unsupported as you didn't reboot after
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #13 from fseidel@novell.com 2006-12-04 03:15 MST ------- (In reply to comment #12) those kernelupdates.
As the entries in menu.lst seem to be random, i would not bet that the index is still correct :-) .as above: and if you reboot (supported sequence) you have known indexes (as written in comment #8 if grub tells us which entry/index was used).
Of course if you suspend directly after the kernel update (without reboot) this'll still be tricky. But do we really support resuming with a updated kernel a image created with the old one?
No, the changed kernel won't even be able to resume. That's why we refuse to suspend in this case.
Then it should also be refused in your case above where you have 5 kernelupdates. I really have the feeling we're talking at cross-purposes here. Stefan, i think we should discuss this on 1:1 today and give a our outcome here afterwards. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #14 from seife@novell.com 2006-12-04 04:59 MST ------- (In reply to comment #13)
I was thinking about "boot, install 5 additional kernel versions, suspend". Well, then this scenario is as well unsupported as you didn't reboot after those kernelupdates.
Wrong. This is supported as long as the original kernel image (the one that is running _now_ ist still available in /boot and an entry for it exists in menu.lst. At least this is supported up to now and i'd like to keep it that way (just because i install an additional kernel for debugging, i do not want to loose the ability to suspend)
No, the changed kernel won't even be able to resume. That's why we refuse to suspend in this case. Then it should also be refused in your case above where you have 5 kernelupdates.
Wrong. It is not "kernelupdates", it is "additional kernel". Following scenario: Boot with: Opensuse-10.2 Windows Opensuse-10.2-failsafe. You decide to build some additional kernels to test some new features, but not now, so you install them. Afterwards you have got: kernel-2.6.19-mm1 kernel-2.6.19-mm2 kernel-2.6.18-mm3-reallyfsckedupdebugpatch Opensuse-10.2 Windows Opensuse-10.2-failsafe. With the "index", you are no longer able to suspend. With my method (find the matching kernel), you are still able to suspend. We'll discuss this. :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #15 from fseidel@novell.com 2006-12-04 05:26 MST ------- Ah, ok, now i got it. Which makes my statements of course invalid, yes. ;-) So, you're fully right. In this scenario havin this index from grub doesn't help, but a macht-search is much more promising, eventhough this bug shows that this'll fail if e.g. a corresponding failsaife kernel appears first with a also matching kernel. Perhaps we really should first parse all matching kernel entries (mandatory) and choose the (first) one of those which matches most of the current options found in /proc/cmdline. Or something like that. But of course if we had a somewhat stable entryorder (e.g. failsafe always last) this would be much better IMHO. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #16 from fseidel@novell.com 2006-12-04 06:34 MST ------- Created an attachment (id=108115) --> (https://bugzilla.novell.com/attachment.cgi?id=108115&action=view) quick'n'dirty fix Stefan, this is a (more or less) untested patch to show what how i meant my last proposal. Do you think this could/should be done/solved like this? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #17 from seife@novell.com 2006-12-19 02:15 MST ------- Sorry, but this is too simple :-) For example i have "PROFILE=test" in my commandline (from SCPM), but this is not even in menu.lst, but gets added from gfxboot IIUC. One thing i could imagine is "skip all kernel entries that have Failsafe in their title", but right now we don't even look at the titles, so this is also additional stuff. The best fix for the bug would be if the default kernel would stay in front of the failsafe kernel, like it did for quite some years now. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 jplack@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jplack@novell.com |seife@novell.com ------- Comment #18 from jplack@novell.com 2006-12-19 08:13 MST ------- But things are achanging, config files can basically be changed in any way and are still valid. - The most complete fix would be to add a 'savedefault' flag to every entry and extend /usr/sbin/grubonce so that one can set the one-time flag only. Thus you only would have to do a '/usr/sbin/grubonce saved'. But this is grub only. - next way could be to go with the upcoming internal interface/tool bl_config in perl-Bootloader and get a consistent architecture independent way o 'parsing' the bootloader configuration. For now (10.2.) I would like you Stefan to go with the work around described above and then pass back the bug to me. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 seife@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |230005 nThis| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 seife@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|230005 | nThis| | Status|NEW |ASSIGNED ------- Comment #19 from seife@novell.com 2006-12-20 10:49 MST ------- I went for this solution in pm-utils (the first part is even cosmetic): --- old/pm-utils-suse/hooks/99Zgrub 2006-11-08 13:55:49.000000000 +0100 +++ new/pm-utils-suse/hooks/99Zgrub 2006-12-20 18:36:36.000000000 +0100 @@ -27,10 +27,14 @@ # DEBUG "Found grub menu entry #${J}: '${LINE}'" INFO ;; default*) - DUMMY=($LINE) # "default 0 #maybe a comment" + DUMMY=($LINE) # "default 0 #maybe a comment" echo "DEFAULT_BOOT=${DUMMY[1]}" # ^^[0]^^ 1 ^^[2]^ 3 ^^[4]^^ # DEBUG "Default boot entry is '${DUMMY[1]}'" INFO ;; + kernel*noresume*) + # we probably found the "failsafe" kernel that won't resume... + echo " Skipping grub entry #${J}, because it has the noresume option" >&2 + ;; kernel*) DUMMY=($LINE) # kernel (hd0,1)/boot/vmlinuz-ABC root=/dev/hda2 echo "KERNELS[$I]='${DUMMY[1]##*/}'" # vmlinuz-ABC ------ because it makes no sense to select a kernel that has "noresume" set for suspend. Fortunately, the failsafe entry also has "noresume" set, so this is good as a workaround. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 seife@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |230005 nThis| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 seife@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|seife@novell.com |jplack@novell.com Status|ASSIGNED |NEW ------- Comment #20 from seife@novell.com 2007-01-08 08:56 MST ------- the pm-utils update with the workaround is out, so back to jack for fixing perl-bootloader :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 ------- Comment #21 from seife@novell.com 2007-01-10 10:08 MST ------- we will face the same problem in SLES10SP1, so i implemented the same workaround in powersaved for SLES10SP1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 jplack@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Comment #22 from jplack@novell.com 2007-01-12 08:54 MST ------- ok, will do later -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722 seife@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|230005 | nThis| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=223722
User jplack@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=223722#c23
Joachim Plack
https://bugzilla.novell.com/show_bug.cgi?id=223722
User jplack@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=223722#c24
Joachim Plack
https://bugzilla.novell.com/show_bug.cgi?id=223722
User jplack@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=223722#c25
Joachim Plack
https://bugzilla.novell.com/show_bug.cgi?id=223722
User jreidinger@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=223722#c26
Josef Reidinger
https://bugzilla.novell.com/show_bug.cgi?id=223722
User seife@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=223722#c27
Stefan Seyfried
https://bugzilla.novell.com/show_bug.cgi?id=223722
Josef Reidinger
https://bugzilla.novell.com/show_bug.cgi?id=223722
User jreidinger@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=223722#c28
Josef Reidinger
participants (1)
-
bugzilla_noreply＠novell.com