Complex and stacked root file systems are not handled correctly

[gutschke]

Binary package hint: initramfs-tools

I noticed this bug with Ubuntu intrepid (8.10) and initramfs-tools 0.92ubuntu2, but I believe it actually exists in all older releases, too. Possibly even upstream, but I did not check.

I have a server with several harddrives spread across multiple distinct controller. These drives are joined in an md RAID6 array, and then organized into logical lvm partitions.

"mkinitramfs" complete fails to understand this configuration and "update-initramfs" subsequently fails to run. I managed to track down the bug to "dep_add_modules()" in "/usr/share/initramfs-tools/hook-functions".

This function attempts to find the root device in order to add the appropriate kernel modules to the ram disk image. It correctly determines that my root devices is "/dev/mapper/sys-sys", then looks up the /sys entry "/dev/block/dm-0/slaves", finds the underlying md device, and ends up setting "$block" to "md0".

So far, so good. But it then erroneously assumes that all LVM devices manage physical harddrives, and thus removes the trailing number from the device name, assuming that it denotes a partition number. My device name now becomes just "md" which is a non-existent device.

Not surprisingly, "mkinitramfs" then errors out when it tries to check for the existence of "/sys/block/md".

The root cause of this error is the incorrect assumption that there is only ever one level of indirection when stacking block devices. Instead, after resolving the LVM device, it should proceed to check whether this device is maybe part of another level of indirection. Typically, this would be an md device (as it is in my case), but it could be a nested LVM device.

I fixed this particular problem in my copy of the script (by commenting out the line that removes the "partition" number) and discovered a second related problem. When resolving md devices, "dep_add_modules()" assumes that it only ever needs to look at the first member of the RAID array. This assumption holds true only if all devices are connected to identical controllers. But many motherboards these days have distinct SATA chipsets for the different on-board ports. And a user might also have added another PCI card to add additional ports.

So, instead of having a single "$block" variable, the code should create a list of block devices when encountering md devices, and consider all of the list entries as possible candidates for kernel module dependencies.

I was able to temporarily avoid this second issue by building all necessary device drivers into my kernel image, but that is obviously only a band-aid solution.

[Andres Mujica (andres.mujica)]

Hi thanks for your report. Would it be possible for you to report this issue upstream?

Thanks

[Neil Perry (nperry)]

This bug is still marked as Incomplete so we are now going to close this bug report. Please upgrade to the latest release Karmic 9.10 - If this bug is still reproducible please reopen the bug by setting the status to New. Thanks

[Alejandro Mery (amery)]

This is supposed to be fixed upstream (debian), but the version of initramfs-tools in 10.04 is still the same broken one as 2 years ago. can you please update it? it makes impossible to install LTS