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

[ceg]

** 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 Kernel
Bugs, which is subscribed to util-linux in ubuntu.