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

[ceg]

** Description changed:

  Binary package hint: util-linux
  
  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
-  "cryptsetup isLuks" and "cryptsetup luksOpen" are not checking for luks devices correctly: "cryptsetup isLuks <raid member device with luks on it>" returns $?=0 (success/true) which it should not.
+ 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.
  
- [I first did not notice this happening with non-usb disks, and also it
- did not happen right after initial install. (so it might happen related
- to a recent update or when the mountall/cryptsetup times out?) How to
- get more details? Edit: Happens according order of device enumeration on
- boot (random assembly), the alternate CD's rescue-mode wants to open
- internal raid members just as well, and it's not usb dependent.]
+ 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 Kernel
Bugs, which is subscribed to util-linux in ubuntu.