[pkg-cryptsetup-devel] Bug#511840: Bug#511840: Initrd fails to find root device after boot into system following install
p.g.berezhkov at gmail.com
Sat Feb 21 12:44:16 UTC 2009
On 19 Feb 09, Jonas Meurer wrote:
> Maks, I spent several hours now on debugging this issue, and all I found
> out is that the patch by Pyotr is correct if you don't want to change
> the way, how initramfs manages /dev/root.
Thanks for taking the time to examine my patch.
Basically, the problem is this: The major/minor of the root device can
change from one boot to another. This happens in the following cases:
1) when booting into the system after installing to or from removable
devices, i.e. USB sticks;
2) when adding/removing removable devices;
3) when adding/removing/recabling hard drives;
3) when adding/removing LVM volumes.
Therefore, relying on hardcoded root device names/numbers (i.e. 'dev/sda1' or
'Oxfe4') in the initrd leads to failure to mount the root device in
The solution is to use persistent device names. If we're using LVM, we
use the names under '/dev/mapper' ('/dev/mapper/foo-bar' for unencrypted
LVM, or '/dev/mapper/foo-bar_crypt' for encrypted LVM). In all other
cases we can use the names provided for us by udev under
These names are passed to the initrd on the kernel command line and work
for any bootloader, whether Lilo, GRUB, or whatever.
'/dev/root' should point to the real root device.
In the case of encrypted and LVM root devices, third-party scripts are
responsible for creating and setting up the root device. Therefore, it
makes sense to have these scripts set up '/dev/root' also.
That's all there is to it. My patch solves the problem for the case of
dm-crypt+LVM. The case of unencrypted LVM will require another patch.
The remaining cases would require some patching of the top-level
initramfs code. parse_numeric() would then be unnecessary and could be
More information about the pkg-cryptsetup-devel