initramfs/udev/mdadm/lvm2 integration

[Phillip Susi]

Kees Cook wrote:
> In Gutsy, the udev rules work for systems that have been set up
> correctly using UUIDs[1] in their /etc/fstab.  If there are
> (non-degraded) situations where LVM-on-MD does _not_ boot, it should be
> considered a bug, and a new report should be opened.

LVM-on-MD works, but is a hack.  LVM on dmraid does not work ( see bug 
#129285 ).  The discussion for the proper fix is at:

https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain

The LVM and dmraid tools are fundamentally broken as designed with 
respect to udev and need fixed to support being told what devices to 
muck with by udev instead of scanning for things that look proper 
devices in /dev.

The hacks that currently allows lvm on md to work are:

1) lvm explicitly refuses to scan partitions with the md type tag, which 
prevents it from activating a pv directly instead of via md, which is 
the problem with the above bug and why lvm on dmraid does not work.

2) For every block device add event, udev runs mdadm again to scan for 
all devices it can find in /dev and probe them for md volumes and 
activate any it finds which are not already active.

Instead, udev needs to identify block devices as pvs ( of an lvm or md 
or dm set ), and set they belong to, then attempt to activate only that 
set, directing the relevant tool to scan only those devices which have 
already been identified as members of that set.

> Right, the initramfs already drops to a shell after the 3 min timeout.
> (Unless you have a buggy BIOS that causes your ACPI timer not to tick --
> have I mentioned all the crazy stuff I've banged my head against on this
> desktop?)  I'd agree, 3 minutes seems too long.  I think it would be safe
> to lower this to 1 minute (or even 30 seconds) since it should only be a
> timeout for the root device. 

I'd like to see it do something along the lines of print a message to 
the console saying not all the devices have been found after say, 15 
seconds.  Then they can hit a key to stop waiting and activate the set 
in a degraded state, or simply continue to wait for 3 minutes.

> I like the idea of local-timeout, though I'm still generally against
> automatically bring up the degraded arrays -- however, a detailed report
> that tries to figure out what's wrong and spews help to the console would
> be nice, something like:

Having an option would be nice, but for unattended servers, they need to 
  not require attention if possible, so eventually it should give up 
waiting and activate the set degraded.