** 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 since some updates
- introduced in karmic and until a fix is released for this.
+ Note:
+ When using luks encryption on top of software raid devices, it can eventually
break because linux_raid_member devices get opened directly as luks instead of
being assembled into md devices (Bug #531240), and all this happens silently
because mdadm monitoring is not set up (Bug #491443). Additionally luks on raid
root filesystems can not boot if the array is degraded (Bug #488317). It is
advisable not to rely on luks on raid until a fix is released.
----
- After the member is opened as luks device it is booted instead of the md
- device, while the raid remains "inactive".
+ After the member was opened as luks device it was booted instead of the
+ md device, while the raid remains "inactive". I don't know what
+ triggered this, but it happened repeatedly after a couple of reboots.
+ May happens according to the order of device enumeration on boot (random
+ assembly).
- I first noticed /proc/mdstat reported the root raid as inactive
- (although the system seemed to run fine!).
+ By chance I noticed this because /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.
+ Looking further it seems 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)
- Which part of the system is involved in setting up the root and could
- have messed things up here?
+ "sudo blkid" now also reported what actually is an USB
+ "linux_raid_member" as TYPE="crypto_LUKS".
- Calling "sudo blkid" reported what actually is an USB
- "linux_raid_member" as TYPE="crypto_LUKS".
+ After booting into a rescue system and reassembling the array everything
+ seemed back to normal (including blkid output) until this bug hit again
+ a couple reboots later.
+
+ A better replicable symptom seems to be that the alternate CD's rescue-
+ mode also wants to open the raid members devices.
+
+ ---
@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.
--
silently breaking raid: root raid_members 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
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
