Just booted a 10.04 machine with "root on lvm on on luks on raid" with an incomplete array.
It failed to degrade the array and boot of course because the mdadm package is broken and unmaintained since years in ubuntu, but what is relevant here is the cryptsetup prompt that showed before failing instead of asking for the password:
cryptsetup: lvm device name (/dev/disk/by-uuid/...) does not begin with /dev/mapper/
Boy, that was close! Seems like cryptsetup was about to open a root raid_member a luks.
I am glad somebody introduced at least that check and it was able prevented breaking the raid array,
despite you guys denying that cryptsetup checks would be relevant.
Yet, this shows there is still a fundamental problem with detecting raid_members as devices they contain in the long term stable bug release.
Just booted a 10.04 machine with "root on lvm on on luks on raid" with an incomplete array.
It failed to degrade the array and boot of course because the mdadm package is broken and unmaintained since years in ubuntu, but what is relevant here is the cryptsetup prompt that showed before failing instead of asking for the password:
cryptsetup: lvm device name (/dev/disk/ by-uuid/ ...) does not begin with /dev/mapper/
Boy, that was close! Seems like cryptsetup was about to open a root raid_member a luks.
I am glad somebody introduced at least that check and it was able prevented breaking the raid array,
despite you guys denying that cryptsetup checks would be relevant.
Yet, this shows there is still a fundamental problem with detecting raid_members as devices they contain in the long term stable bug release.