Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 613662 - sys-fs/cryptsetup now fails to find LUKS on mdraid device at boot time
Summary: sys-fs/cryptsetup now fails to find LUKS on mdraid device at boot time
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-23 17:52 UTC by David Flogeras
Modified: 2019-08-14 10:43 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Flogeras 2017-03-23 17:52:24 UTC
I have a system which has a system disk which holds /boot and a LUKS encrypted partition.  On the LUKS partition is a Volume Group which contains all relevant OS partitions.  I use a dracut initramfs to boot and it works as expected.

Next, I have a 4 disk RAID array, upon which is a LUKS partition, inside that is another volume group I use for data partitions.

I have both mdraid and dmcrypt in the boot runlevel, and for years this has worked as expected.  I get a LUKS password prompt to unlock the root partition, then booting continues, and when it finds the LUKS parition on the RAID device, it asks me for its password, after which LVM finds the volumes, and they are finally mounted.

Recently (I'm not sure when, since I only reboot this machine when new kernels are stabled), this stopped working.  The dracut portion of unlocking LUKS and finding the OS Volume group works fine, but it does not stop to ask about the LUKS partition on RAID.  Obviously then the boot process complains that it cannot find all the partitions listed on the missing VG.

I tried adding
RC_AFTER="mdraid"
in /etc/conf.g/dmcrypt, but to no avail.

Not sure what might have changed.  I'm not ruling out the possibility that it is a configuration issue, but I don't recall any changes to the mdraid dmcrypt or even LVM config files since this problem appeared.

Reproducible: Always
Comment 1 Francesco Turco 2017-03-23 19:03:00 UTC
You should probably tell us which version of cryptsetup and dracut you are using.
Comment 2 David Flogeras 2017-03-23 20:07:22 UTC
Sorry, amd64 stable all around. So:

[I] sys-fs/cryptsetup (1.7.2{tbz2}@09/26/2016)
[I] sys-fs/lvm2 (2.02.116-r4{tbz2}@03/08/2016)
[I] sys-kernel/dracut (044-r1{tbz2}@12/20/2016)
[I] sys-fs/mdadm (3.4{tbz2}@01/03/2017)
Comment 3 David Flogeras 2017-03-31 20:20:49 UTC
Same behaviour with lvm2-2.02-145-r2

Also, it appears to be some sort of race.  After upgrading lvm2 and rebuilding dracut, I rebooted maybe a half dozen times, and 50% it works, 50% it doesn't.
Comment 4 Alexander Tsoy 2017-04-05 19:26:01 UTC
(In reply to David Flogeras from comment #0)

> ... but it does not stop to ask about the LUKS partition on RAID.  Obviously
> then the boot process complains that it cannot find all the partitions listed
> on the missing VG.

Does this happen before or after switching root?
Comment 5 David Flogeras 2017-04-05 19:36:21 UTC
I believe after, but what would your definition of switching root be?  OpenRC has taken over, and udev has run I believe if that helps.
Comment 6 David Flogeras 2019-08-14 10:42:29 UTC
After switching to sys-fs/eudev back in May, I think I have now rebooted this server enough times to say that the problem would have reared up by now.  I think it was all tied to using sys-fs/udev.  This switch fixed other "strange" issues I was having on multiple machines.

I'll close for now and re-open if I ever see it again.