[pkg-cryptsetup-devel] Bug#511840: Bug#511840: Initrd fails to find root device after boot into system following install

[Pyotr Berezhkov]

On 19 Feb 09, Jonas Meurer wrote:
> Hey,
> 
> 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
these cases.

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
'/dev/disk/by-id'.

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
safely removed.

  -PGB