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

[ceg]

> it's still a bug in blkid. It's blkid that wrongly detects the LUKS
UUID on a device that's a RAID member.

Yes, your of course right, and if "cryptsetup isLuks" is itself scanning
for a luks signature (without giving RAID precedence) it got the same
bug. Can you rule that out / know for sure that cryptsetup depends
on/uses blkid? (the cryptsetup package does not depend on util-linux
package)


> Could you provide...

Yes, (as it happened again now) I can provide the shorthand output:

#blkid
/dev/sda1: UUID="de" TYPE="ntfs" 
/dev/sda2: UUID="a0" TYPE="ext2" 
/dev/sda3: UUID="a1" TYPE="linux_raid_member" 
/dev/sda5: UUID="3a" TYPE="linux_raid_member" 
/dev/sda7: UUID="19" TYPE="linux_raid_member" 
/dev/md1: UUID="f1" TYPE="linux_raid_member" 
/dev/md0: UUID="b1" TYPE="crypto_LUKS" 
/dev/md2: UUID="df" TYPE="crypto_LUKS" 
/dev/sdb1: UUID="fd" TYPE="ext2" 
/dev/sdb2: UUID="A9" TYPE="vfat" 
/dev/sdb3: UUID="a1" TYPE="linux_raid_member" 
/dev/sdb5: UUID="f1" TYPE="linux_raid_member" 
/dev/sdb6: LABEL="boot" UUID="df" TYPE="ext2" 
/dev/sdb7: UUID="11" TYPE="crypto_LUKS" 
/dev/mapper/md3_crypt: UUID="aL" TYPE="LVM2_member" 
/dev/mapper/vg0-lv_swap: UUID="4b" TYPE="swap" 
/dev/mapper/vg0-lv_root: UUID="66" TYPE="ext4" 
/dev/mapper/md2_crypt: UUID="09" TYPE="ext4" 

# cat /proc/mdstat 
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
md2 : active raid1 sdb5[1] md1[0]
      17719488 blocks [2/2] [UU]
      bitmap: 3/136 pages [12KB], 64KB chunk

md0 : active raid1 sdb3[0] sda3[1]
      78123968 blocks [2/2] [UU]
      bitmap: 0/150 pages [0KB], 256KB chunk

md1 : active raid1 sda5[0]
      17719552 blocks [2/1] [U_]
      bitmap: 80/136 pages [320KB], 64KB chunk

md3 : inactive sda7[0](S)
      19334080 blocks

sdb7 should be the second member of md3 (/home fs) and have the same
RAID UUID as sda7 "19". Instead sdb7 is reported with "11", the UUID of
the luks signature of md3 (stored on sda7 and sdb7 of course).


> this is a case where a given partition has both LUKS and RAID

Yes, always give RAID and LUKS signatures preference over filesystem
signatures because they are a containers, and you can give RAID
preference over LUKS because it is a container for LUKS and when its set
up/ment the other way around (RAID member contained in LUKS partition)
the RAID signature is not visible.

AIUI this doesn't have to do much with requiring configuration to be
activated. Redundant raids should never need user intervention to be run
even degraded after a timeout, and luks can be supplied with a keyfile
that gets available opening another (possibly unencrypted) partition or
a cardreader or fingerprint reader that may get available. (As you see
lots of other events that the initramfs has to handle for the general
case, so it may pay out well to use the same and known upstart/mountal"
mechanisms in initramfs, too.)

-- 
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.