From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040308 Description of problem: An automated kernel install via up2date creates an unbootable kernel under some circumstances. When the root filesystem in on LVM and the first, root entry in /etc/fstab uses LABEL= similar to "LABEL=/root / ext3 defaults 1 1", then mkinitrd fails to create a correct initrd for the system. The mkinitrd program does not detect that the root filesystem is on LVM and so does not include the vgscan, vgchange and vgwrapper modules in the initrd nor the "vgscan" or "vgchange -ay" commands in the initrd. This results in a kernel panic due to not being able to find the root filesystem. This situation does not occur when the entry in /etc/fstab does not use the LABEL= syntax and instead refers to the LVM volume similar to "/dev/Volume00/root / ext3 defaults 1 1" If the use of LABEL= and LVM is not supported, then this is an enhancement request, but since I haven't read any documentation that says it can't be done, I'll log it as a bug. Version-Release number of selected component (if applicable): 3.5.13-1 How reproducible: Always Steps to Reproduce: 0. Setup system with an LVM root filesystem 1. boot to your default kernel 1. e2label /dev/root "/root" (no /dev/root but you get the idea.) 1. echo "LABEL=/root / ext3 defaults 1 1" > /tmp/foo 2. cat /etc/fstab | grep -v " / " >> /tmp/foo 3. cat /tmp/foo > /tmp/fstab && rm -f /tmp/foo 5. rm -f /boot/initrd-`uname -r`.img 6. mkinitrd /boot/initrd-`uname -r`.img `uname -r` 7. Reboot 8. Kernel panic - cannot find init. Actual Results: The kernel could not find the root filesystem because the LVM volume was not detected with "vgscan" and was not activated with "vgchange -ay", and as a result the kernel panicked becaus eit could not find init. Expected Results: The kernel should have booted in my opinion. :-) Additional info: My fstab currently starts with the following 7 lines. # LABEL=/root / ext3 defaults 1 1 # The above entry causes mkinitd to leave out vgscan, vgchange # and vgwrapper and the associated entries in linuxrc such as # "vgscan" and "vgchange -ay", and as a result a boot to an kernel # that has been upgraded with up2date automatically will fail. # /dev/Volume00/root / ext3 defaults 1 1
Using labels for mounting filesystems only makes sense in the case where there's not a persistent name. With LVM, the name is persistent (the metadata on the device includes both the volume group and logical volume name) and thus there's no need for using labels.