Just installed lucid beta2-alternate with luks on raid in virtualbox.
Guess what, all turning down of this seems to be based on false speculations.
If I boot the CD again in rescue mode after the install
* It wants to open all md member devices as luks and asks for passphrases for
each member.
* It does not seem to detect nor being able to open the actual luks on the md
devices.
** Changed in: ubuntu-release-notes
Status: Invalid => New
** Description changed:
Binary package hint: util-linux
When using luks on top of software raid devices, linux_raid_member
devices can get opened as luks instead of being assembled into md
- devices. It is adviseable not to use luks on raid.
+ devices. It is adviseable not to use luks on raid since some updates
+ introduced in karmic and until a fix is released for this.
----
After the member is opened as luks device it is booted instead of the md
device, while the raid remains "inactive".
I first noticed /proc/mdstat reported the root raid as inactive
(although the system seemed to run fine!).
Looking further it seemed like during boot the system has unlocked and
mounted the rootfs using (only) one raid_member located on an external usb disk
directly. ("dmsetup deps" pointed to it for mdX_crypt)
I guess since the usb raid_member was busy then, the system was not able to
start the raid, and so it remained inactive.
Which part of the system is involved in setting up the root and could
have messed things up here?
Calling "sudo blkid" reported what actually is an USB
"linux_raid_member" as TYPE="crypto_LUKS".
@util-linux
I found the following in the util-linux changelog:
* Always return encrypted block devices as the first detected encryption
system (ie. LUKS, since that's the only one) rather than probing for
additional metadata and returning an ambivalent result. LP: #428435.
might that cause the precedence of reporing luks over raid_member for the usb
disk?
@cryptsetup
Also "cryptsetup isLuks" gives a false positve. "cryptsetup isLuks <raid
member device with luks on it>" returns $?=0 (success/true) That is the reason
why the initramfs check implemented in scripts/local-top/cryptroot does not
prevent this bug from having its bad effects.
Edit: Happens according to the order of device enumeration on boot
(random assembly). Another symptom is the alternate CD's rescue-mode
wants to open internal raid members just as well, so it's not usb
dependent.
--
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 Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
