[Bug 531240] Re: breaking raid: root raid_member opened as luks

[ceg]

>[cryptsetup] waits for the physical device to be available, decrypts it
as needed, then mounts it. No other event handling is required or
appropriate.

Think of the following example.

As far as I can see cryptsetup in initramfs is not called on the event
that a crypt device appears. It seems cryptsetup in initramfs is
currently rather linear script driven: the cryptsetup script has its own
while loop waiting for $cryptsource after all other "local top" scripts.
"Failure hooks" have been introduced in initramfs and mdadm, but I don't
see one for cryptsetup. And I have doubts that such a two step design
can cope with the general case of devices depending on others.)

The simple case: rootfs on lvm on crypt on raid:

0) The md0 raid (sda,sdb) got degraded during power down,
1 udev/mdadm does not start the array,
2) crypt on raid does not come up for 2,5 minutes until ROOTDELAY timeout and init-top fails  (putting aside this bug, that cryptsetup is wrongly opening a member device)
3) mdadm failure hook runs the array degraded
4) boot currently fails never the less (but could be made to work with a cryptsetup failure-hook for this case)

If however the rootfs is actually located on md1 assembled of md0 (the
internal disks) an sdc, with the failure hook design there is no further
timeout given or failurehook available after md0 is started degraded to
bring the rootfs up if the (external backup disk) sdc is not connected.

(This is not far fetched because only stacking raids this way allows to
take advantage of write intent bitmaps for a (backup) disk that are not
connected all the time. (sdc in this case))

So to handle the genreal case with unforeseen combinations, I think in
initramfs:

- cryptsetup udev rules should be supplied into initrams as well (new_crypt_device event, restriced to the rootfs dependency devices)
- The initramfs should have just one ROOTDELAY waiting loop in its script (or faster loading upstart/mountall binary?) started upon initramfs_start, that is paused however while cryptsetup it is prompting for a passphrase (prompt_start/stop events).
- Package mdadm needs to supply a MIN_COMPLETION_WAIT value and the dependency tree of arrays for the root device on mkinitramfs.
- During boot when time_elapsed == MIN_COMPLETION_WAIT (raid_start_degrated event)
   -If a next level in the dependency tree exists and the remaining root delay timer is lower then MIN_COMPLETION_WAIT the rootdelay_timer is increased by MIN_COMPLETION_WAIT.
   -The degraded arrays of the current dependency level are started degraded.

related cryptsetup bug:
Bug #251164  boot impossible due to missing initramfs failure hook integration
Bug #247153  encrypted root initialisation races/fails on hotplug devices (does not wait)


To fix this bug # however cryptsetup must not open individual raid members directly.
I can run "cryptsetup isLuks" on such a raid member but don't know how get to the response code (true/false?).
:~# cryptsetup isLuks /dev/hda7
:~# (empty prompt with no visibe output)

-- 
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to util-linux in ubuntu.