initramfs uses bad lvm lvname to mount /

[Thomas Debesse]

Binary package hint: initramfs-tools

First symptom : at boot, the message "No init found. Try passing init= bootarg."
Boot fails.

I'm upgrading to Natty from Maverick

My configuration :
/dev/sda1 : /boot
/dev/sda5 : an encrypted luks volume containing an LVM physical volume

the volume groupe name is "arwen", the logical volume name for / is "racine"
the device containing rootfs is named /dev/mapper/arwen-racine

hence, my grub menuentry looks like this :

menuentry 'Ubuntu, avec Linux 2.6.38-8-generic' --class ubuntu --class gnu-linux --class gnu --class os {
 recordfail
 savedefault
 set gfxpayload=$linux_gfx_mode
 insmod part_msdos
 insmod ext2
 set root='(hd0,msdos1)'
 search --no-floppy --fs-uuid --set=root uuiduuid-uuid-uuid-uuid-uuiduuiduuid
 linux /vmlinuz-2.6.38-8-generic root=/dev/mapper/arwen-racine ro quiet splash vt.handoff=7
 initrd /initrd.img-2.6.38-8-generic
}

Sometimes, the error is more verbose, I've get yesterday a message which said the system attempt to mount /dev/mapper/arwen on initramfs' /root, but it's a mistake, my rootfs is on /dev/mapper/arwen-racine.
The root= kernel argument is correct, but an initramfs script mades a mistake.

From initramfs' shell I've mounted my /boot partition, then create a new initrd.img hardcoding /dev/mapper/arwen-racine path on the line 91 of scripts/local, then reboot, then choose my new initramfs from the grub editor…
The boot does'nt complain and I'm writing this bug report from Natty. :)

So, there is a bug in one script into initramfs which troncate the volume group name of / .
I've not found where.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: initramfs-tools 0.98.8ubuntu3
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
Architecture: amd64
Date: Thu Apr 28 12:21:09 2011
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=fr_FR:en
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: initramfs-tools
UpgradeStatus: Upgraded to natty on 2011-04-21 (6 days ago)

[Thomas Debesse (illwieckz)]

For people which encounter same problem, here a detailed howto to temporarily repare your distro :

# from initramfs'hell :

# mount correctly your rootfs
mount /dev/mapper/vgname-lvname /root

# and the bootfs
mount /dev/sda1 /root/boot

# then chroot into rootfs
chroot /root /bin/bash

# create a clean directory then go into
mkdir /plop; cd plop

# uncompress an initrd
gunzip < /boot/initrd.img-2.6.38-8-generic | cpio -idmv

# edit the "local" script (which mount local file system)
vim scripts/local
# comment the line 91
> mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
# then hardcode your device
> mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} /dev/mapper/vgname-lvname ${rootmnt}
# close your favorite editor and build a new initramfs
find . | cpio -ov -H newc | gzip > /boot/initrd.img-rescue

# add a grub custom entry into /boot/grub/custom.cfg
# coppying an actual entry from /boot/grub/grub.cfg
vim /boot/grub/grub.cfg /boot/grub/custom.cfg

# mine looks like this :
> menuentry 'rescue' --class ubuntu --class gnu-linux --class gnu --class os {
> recordfail
> set gfxpayload=$linux_gfx_mode
> insmod part_msdos
> insmod ext2
> set root='(hd0,msdos1)'
> search --no-floppy --fs-uuid --set=root uuiduuid-uuid-uuid-uuid-uuiduuiduuid
> linux /vmlinuz-2.6.38-8-generic root=/dev/mapper/vgname-lvname ro quiet splash vt.handoff=7
> initrd /initrd.img-rescue
> }
# then... reboot, and to next boot, choose "rescue" in grub menu.

[Phillip Susi (psusi)]

Natty and Maverick have been end of life for some time. Are you able to reproduce this on 12.04 or 13.10?

[Thomas Debesse (illwieckz)]

Hum, sorry, I forgot to mention here that I had investigated.

It was in fact a bug inside a lilo-compatibility layer in grub (or initramfs-tools, I do not know since the time) when using grub. A lilo-compatibility layer reconfigured encrypted bootdrive management regardless of the kernel boot parameter. Another solution was to configure crypttab with less information so the lilo-compatibility layer failed and and let grub do its job…

This is very old but it is probable that the bug is still there in more recent distribtuions. The bug appears only when you are too verbose in crypttab, so the default installation does not seem affected. I will reproduce the test.

[Launchpad Janitor (janitor)]

[Expired for initramfs-tools (Ubuntu) because there has been no activity for 60 days.]