System: Ubuntu 18.04 64-bit.

I have a raid-5 array (md0) consisting of 4 devices (sdb1,sdc1,sdd1,sde1). I encrypted /dev/md0 as a luks2 volume (crypt0), and I formatted /dev/mapper/crypt0 as an lvm physical volume, on which I put volume group vg1. All works fine.

My problem is that after reboot, although /dev/md0 does exist, and mdadm -Ds shows the appropriate information, and the crypt volume /dev/mapper/crypt0 also exists, pvs does not show /dev/mapper/crypt0 as a PV, and vg1 does not appear.

If, however, I issue the command "cryptdisks_stop crypt0" followed by "cryptdisks_start crypt0", /dev/mapper/crypt0 is suddenly recognised as a PV, the VG and my LVs show up as normal. Using hexdump on /dev/mapper/crypt0 shows that the binary data changes between the stop and the (re)start.

My first thought was that the luks mount was taking place prior to the raid device being set up. But surely the mount would fail in that case, not leave me with a device containing incorrect data?

I've been struggling with this for 2 days now, and would really appreciate any suggestions.

FWIW, the relevant line in /etc/mdadm/mdadm.conf is:

ARRAY /dev/md0 metadata=1.2 name=maggie:0UUID=c32cf5ee:3470d676:87544e31:328f5d5f

Yes, I have run update-initramfs -u -k all, and checked the initramfs version.

And the line in /etc/crypttab is: (with some details hidden here but correct)

crypt0 /dev/md0 luks2,header=


Solved. My own stupidity.

After struggling with this, I decided to do a more detailed log of the boot process by feeding the Linux command line a debug=2 parameter, and that did it.

The "luks2" parameter in the /etc/crypttab file should have been just "luks". Opening the drive with cryptdisk_start gave no error at all, but it was enough to cause systemd to choke when it encountered it during the boot. Mea culpa.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.