Bugzilla – Bug 439103
LVM / boot fails on 2.6.27.1-2
Last modified: 2010-12-18 16:16:41 UTC
Created attachment 248038 [details] config data as indicated Tail of boot messages: ... Reading all physical volumes. This may take a while... Volume Group "VolGroup00" not found Volume Group "VolGroup00" not found Could not find /dev/VolGroup00/LogVol01. Reading all physical volumes. This may take a while... Volume Group "VolGroup00" not found Volume Group "VolGroup00" not found Could not find /dev/VolGroup00/LogVol01. Want to fall back to /dev/VolGroup00/LogVol01? (Y/n) This happened after full Smart update last night from download.opensuse.org. Smart has flag lock set for kernel-pae & kernel-pae-base, so I installed current kernel with rpm -ivh after all other updates completed. Previous updates included 2.6.27.rc7-12 just after mirrors update to Beta 2 was announced. Previous initrd is considerably larger than initrd created by rpm last night. After failure, I ran mkinitrd myself, and got a much smaller initrd for the previous kernel and a significantly smaller initrd for the current kernel. The new for previous kernel works, but the new for current fails in same manner as the original. Attachment is output of lsmod, plus fstab and mtab files, and HD partitioning details. I'll further attach the initrds and/or /proc/config.gz and/or anything else if requested. I have no idea how to figure out what's wrong with the current kernel/initrds. This is initrds listing: 5507554 2008-10-05 00:41 initrd-2.6.27-rc7-12-pae1-OK 3903724 2008-10-26 00:42 initrd-2.6.27.1-2-pae1-bad 3687830 2008-10-26 20:25 initrd-2.6.27.1-2-pae2-bad 3640452 2008-10-26 20:25 initrd-2.6.27-rc7-12-pae2-OK Sole system HD is on IDE/via82cxxx.
Created attachment 248090 [details] config data as indicated in comment 0 oops, attached wrong file
Alexander, can you have a look here?
Could you please attach the broken as well as the working initrds? I'd like to compare the contents to see what exactly changed for you.
Created attachment 248501 [details] initrd-2.6.27-rc7-12-pae1 OK
Created attachment 248502 [details] initrd-2.6.27-rc7-12-pae2 OK
Created attachment 248503 [details] initrd-2.6.27.1-2-pae1 bad
Created attachment 248504 [details] initrd-2.6.27.1-2-pae2 bad Mandriva has a lsinitrd command that would have allowed me to see for myself.
Neat idea. Let's see ...
Created attachment 248532 [details] lsinitrd lsinitrd script.
Felix, thanks for the idea. I'll add it to our mkinitrd rpm. Enhancements etc are welcome.
Same problem with 2.6.27.4-2 after full update of everything else to current Factory mirror state.
Same as https://bugzilla.novell.com/show_bug.cgi?id=440986 - underlying problem seems to be explained there.
I read that as system was using libata and upgrade tried to switch to legacy. Here, system is already using legacy.
I got 2.6.27.1-2 & 2.6.27.4-2 to work by rebuilding their initrds after changing /etc/sysconfig/kernel as follows: --- kernel-libata-kt880 2008-06-06 15:04:09.000000000 -0400 +++ kernel-kt880-ide 2008-11-04 09:22:07.000000000 -0500 @@ -7,7 +7,7 @@ # ramdisk by calling the script "mkinitrd" # (like drivers for scsi-controllers, for lvm or reiserfs) # -INITRD_MODULES="processor thermal pata_via sata_via fan jbd ext3 dm_mod edd" +INITRD_MODULES="processor thermal via82cxxx fan jbd ext3 dm_mod edd" ## Type: string ## Command: /sbin/mkinitrd
This looks like a YaST update problem. mkinitrd certainly do _not_ touch INITRD_MODULES, and what's more it actually works if the correct module is specified.
Hannes, why YaST problem? Felix said he upgraded using 'smart'. So the problem seems to be a more general (kernel) packaging problem? Can we mark this a duplicate of bug 440986?
I did not upgrade kernel using Smart - kernel was installed using rpm directly. System was using legacy driver initially, the opposite of bug 440986.
I would think this is a kernel split issue. Are both rpms 'kernel-pae-base' and 'kernel-pae' installed? If so, what is the output of the mkinitrd run?
(In reply to comment #19 from Hannes Reinecke) > I would think this is a kernel split issue. Are both rpms 'kernel-pae-base' and > 'kernel-pae' installed? Yes. > If so, what is the output of the mkinitrd run? I don't know how to answer this. Do you want an initrd attached?
Well, I thought of something like 'mkinitrd -k vmlinux-XXX -i initrd-XXX > initrd.log' ...
Scanning scripts ... Resolve dependencies ... Install symlinks in /lib/mkinitrd/setup ... Install symlinks in /lib/mkinitrd/boot ... Kernel image: /boot/vmlinuz-2.6.27.5-3-pae Initrd image: /boot/initrd-2.6.27.5-3-pae Kernel Modules: hwmon thermal_sys processor thermal ide-core via82cxxx fan jbd mbcache ext3 dm-mod edd dm-snapshot dock scsi_mod libata pata_via ata_generic ide-pci-generic ide-disk usbcore ohci-hcd uhci-hcd ehci-hcd ff-memless hid usbhid linear Features: dm block usb lvm2 Bootsplash: openSUSE (1024x768) Note that since my comment 14 fix this bug no longer exists.
Hmm. Yes, this is a problem. mkinitrd doesn't modify the sysconfig variable, it only reads them. So if they contain a wrong value it's either a user error or YaST is to blame.
I have the same exact problem after a straight upgrade from 11.0 to 11.1 GA. Everything went smooth, but I cannot boot anymore. This is 32-bits. I am on the -pae kernel. How do we go about fixing this?
ok, so I had to boot in rescue mode, and rebuild the initrd. It works now. I guess I hit another bug then.
After analyse of the bug yast2-bootloader didn't modify /etc/sysconfig/kernel in this case. Update kernel package was done via calling rpm. Next it is true that yast2-bootloader write INITRD_MODULES but it is only during installation/update. BTW I just reread INITRD_MODULES export them in yast2-bootloader autoyast profile and write it back. There are some filtered modules but is about MODULES_LOADED_ON_BOOT. y2-bootloader filter modules: "cdrom", "ide-cd" and "ide-scsi" nothing more. Sorry I am sure that it is not yast2-bootloader issue. Maybe bug#505670 describe same issue but I am not sure in this case. reassign back to Hannes
And again, mkinitrd doesn't modify the variable INITRD_MODULES. So we need to find the program / package which does. Assigning to the rpm gods. They might know.
Huh, how should I know that? Try someone else.
Yast folks should know.
If the updated is being done via RPM directliy (which it was in this particular case), then the only one who can do it is RPM in the post-installation script.
Which mkinitrd doesn't have. And we certainly don't handle any IDE<>libata renaming issues. Milan, can you track this?
11.1 will soon be out of support, while this is WORKSFORME in 11.2 and up.