Bugzilla – Bug 133993
resume line missing from grub's menu.lst
Last modified: 2006-03-27 15:19:06 UTC
diff -u /boot/grub/menu.lst.old /boot/grub/menu.lst --- /boot/grub/menu.lst.old 2005-09-29 14:32:35.000000000 +0200 +++ /boot/grub/menu.lst 2005-11-16 10:32:00.000000000 +0100 @@ -1,4 +1,4 @@ -# Modified by YaST2. Last modification on Thu Sep 29 14:32:35 CEST 2005 +# Modified by YaST2. Last modification on Wed Nov 16 10:32:00 CET 2005 color white/blue black/light-gray default @@ -6,13 +6,13 @@ gfxmenu (hd0,5)/boot/message ###Don't change this comment - YaST2 identifier: Original name: linux### -title SUSE LINUX 10.0.42.42 +title SUSE LINUX 10.0.42 root (hd0,5) - kernel /boot/vmlinuz root=/dev/hda6 vga=0x317 selinux=0 resume=/dev/hda5 splash=silent showopts + kernel /boot/vmlinuz root=/dev/hda6 vga=0x317 selinux=0 splash=silent showopts initrd /boot/initrd ###Don't change this comment - YaST2 identifier: Original name: failsafe### -title Failsafe -- SUSE LINUX 10.0.42.42 +title Failsafe -- SUSE LINUX 10.0.42 root (hd0,5) kernel /boot/vmlinuz root=/dev/hda6 vga=normal showopts ide=nodma apm=off acpi=off noresume selinux=0 nosmp noapic maxcpus=0 edd=off 3 initrd /boot/initrd
So, resume= is missing - this was an update from 10.1 Alpha1 to 10.1 Alpha3.
Created attachment 57518 [details] Yast log files
Reasigning to new maintainer
This is still happening with Alpha4, please get this fixed asap.
Is this fixed now?
Still with 10.1 Beta1.
Finally got a test-inst-sys on an x86_64 machine running. The bug does not reproduce on my test machine with SLES10 Beta1. As I doubt this is specific to 10.1 Beta1 it seems to depend on the machine. To avoid a lot of guesswork, I need to do some testing in an inst-sys on a machine where the bug reproduces. Maybe also newer logs may sched some light on the problem, although I doubt they will answer all questions.
Have you done an update from a previous system? Come to my office on monday and let's talk, I have my machine with me.
Ah right, this was an update. Bootloader installation for updates is done from the post-install script of the kernel RPM. AFAI have been told and AFAICS YaST is not directly involved here (other than providing hints like $YAST_IS_RUNNING). But this may not be completely accurate. Anyway this seems to point to package kernel-source, post.sh and further to /sbin/new-kernel-pkg from mkinitrd as well as probably /sbin/update-bootloader (and all the perl functions involved) from perl-Bootloader. As I have not pinpointed the problematic code yet, comments from the maintainers of these packages should be most helpful. Putting them in CC:.
*** Bug 145025 has been marked as a duplicate of this bug. ***
same problem after updating to 10.1 beta2...
Created attachment 65582 [details] menu.lst created during upgrade from 10.0 to 10.1beta2 Me too, upgraded from 10.0 to beta2. Was unable to suspend as a result (#146103).
After upgrading 10.1 beta1 to 10.1 beta2 I still had the problem, once I added resume=/dev/hda5 like I was told before everything worked again. If you think it's machine specific I have a pentium 4 with hyper threading.
*** Bug 148208 has been marked as a duplicate of this bug. ***
Bug is still in Beta3.
Could so. please post the yast2-logs? To comment #13: So this entry was there with Beta1 (resume worked) and disappeared after an update to beta2? A fresh installation of beta2 has this parameter, btw.
See comment #2 for the log files when this was first reported. I fixed it manually with each installation, so the entry was there when I did the update from Beta1/Beta2 to the next BETA - and disappeared through the beta process.
For log files see also the duplicate of this PR: 148208. If you need current ones, please ask again.
you can find the actual logs in Bug 148208 (Upgrade from Beta1 -> Beta3) additional info: It seems that also the memory parameter for xen was lost
The bootloader does not provide a resume parameter because it does not find any available swap partitions: 2005-08-24 01:58:13 <1> linux(3031) [YCP] bootloader/routines/misc.ycp:1296 Available swap partitions: $[] The disk still has a swap partition after the update (from "disk_hda"): Partition: 5 /dev/hda5 2096419 3 5 0 261 82 logical But in the y2log-2 the last time I see the "mount" "swap" assigned to /dev/hda5 is before package installation: 2005-08-24 00:57:17 <1> linux(3031) [YCP] RootPart.ycp:762 mounting /dev/hda5 to swap But this information comes from RootPart.ycp in yast2-update, which reads the fstab itself. (The last time Storage.ycp has a ``"mount":"swap"´´ in the TargetMap is earlier.) After RootPart.ycp, libstorage does this: 2005-08-24 00:57:17,161 INFO libstorage - Storage.cc(changeMountPoint):1142 device:/dev/hda5 mount: 2005-08-24 00:57:17,161 INFO libstorage - Storage.cc(findVolume):3140 device:/dev/hda5 ret:1 c->device:/dev/hda v->device:/dev/hda5 2005-08-24 00:57:17,161 INFO libstorage - Partition.cc(changeMount):195 device:/dev/hda5 val: 2005-08-24 00:57:17,161 INFO libstorage - Volume.cc(changeMount):377 device:/dev/hda5 mount: 2005-08-24 00:57:17,161 INFO libstorage - Volume.cc(changeMount):396 ret:0 2005-08-24 00:57:17,161 INFO libstorage - Partition.cc(changeMount):200 ret:0 After this the ``"mount":"swap"´´ is gone from the TargetMap: 2005-08-24 00:56:57 <1> linux(3031) [YCP] Storage.ycp:1113 getContainerInfo container [...]$["detected_fs":`swap, "device":"/dev/hda5", "fsid":130, "fstype":"Linux swap", "inactive":true, "mount":"swap", "name":"hda5", "nr":5, "region":[0, 261], "size_k":2096419, "type":`logical, "used_fs":`swap],[...] This seems to be a problem in yast2-storage.
Created attachment 69782 [details] I could reproduce this. These are the logs from /var/log/YaST2.
*** Bug 157010 has been marked as a duplicate of this bug. ***
*** Bug 156598 has been marked as a duplicate of this bug. ***
*** Bug 157452 has been marked as a duplicate of this bug. ***
Jiri from the logs it looks like the map given to Storage::SetTargetMap in SetFormatPartitions in RootPart.ycp contains the wrong (empty) mount point settings. Maybe it would make sense to add a log line with the variable target_map. Otherwise I do not have any idea why Storage.ycp should forget about the swap mount point.
This is a problem happening during update so I do not see why Olaf should be involved. Jiri, are you still resonsible for yast2-update?
Yes, I am. I added more verbose logging, so that it is clear what OnDiskTarget returned, what was sent for SetTargetMap and also which operations no the target map were performed. Done in SVN, will go to build in a moment. But this code has not changed since ages...
Might very well be that the code is still ok, and the problem is interaction with changed yast2-storage. But we should see that with your added log entries. Might also be that all this works fine with a current beta, beta#3 is pretty old.
I can not see why this bug was reassigned to me. From the comments this seems to be between yast2-update and yast2-storage. Tentatively assigning to fehr@suse.de.
Jiri, could you try an update with more verbose yast2-update, so that we can see why this gets lost.
Created attachment 73776 [details] Log from build 801 Look for "On disk target map". IMHO this log looks OK...
No, there is no call to SetPartitionData for setting the mount point of the swap partition /dev/hda2 to "swap" in the target map. Therefore later the bootloader is not able to find an active swap partition in the target map. Active for a swap partition means is has mount points "swap", since it is also possible to explicity not use a existing swap partition. This results in the missing resume parameter. You should call SetPartitionData also for the swap partition like for all other partitions with a non-empty mount points.
This bug still exists in today's Build 806 :-(