1

I recently created a LUKS2 device with a native --offset of 4MiB. The file command correctly identifies the device and lists its UUID, but it is neither auto-opened at boot nor visible in /dev/disk/by-uuid/... (even after update-initramfs).

Manually running cryptsetup open works as expected but cryptdisks_start fails to open it. It is specified with UUID= in /etc/crypttab like my other devices. Using the "parent" block device path instead of its UUID works.

Inspection with xxd shows the correct magic number ("LUKS" at offset 0) and the header starting at the same offset as my other LUKS2 devices (which are correctly detected). Why is this device failing to be detected? What can I do to allow me to open it via its UUID?

11
  • What does blkid /dev/the-block-device return? Oct 15, 2021 at 13:00
  • udevadm info /dev/the-block-device might also give some clues. Oct 15, 2021 at 13:04
  • Is the encrypted partition formatted (with a filesystem e.g. ext4)? Perhaps some mechanism tests for that.
    – Ned64
    Oct 15, 2021 at 13:08
  • @StéphaneChazelas blkid /dev/... returns /dev/...: TYPE="jmicron_raid_member". Some of my drives are connected via a PCIe SATA card, but so are other LUKS2 devices that work correctly.
    – ATLief
    Oct 15, 2021 at 13:09
  • 2
    If it's meant to be jmicron raid member, it shouldn't be accessed directly. If it's not, you should probably try and remove the signature that makes it being detected as such. Oct 15, 2021 at 13:12

1 Answer 1

3

Technically, the kernel here is not at fault. The only kernel's involvement here is with the dmcrypt device mapper device configured by cryptsetup.

cryptsetup is able to configure the device mapper device based on the metadata as stored on the block device so is not at fault either.

The fact that there's no /dev/disk/by-uuid entry for the LUKS device stored there points at udev or whatever is responsible to discovering LUKS devices (see also the output of udevadm info /dev/the-block-device).

udev uses blkid (well, the builtin version see rules in /lib/udev/rules.d/60-persistent-storage.rules on Debian for instance) to find out about those.

In your case, blkid reports TYPE="jmicron_raid_member". If it's a RAID array member, it shouldn't be accessed directly, so blkid is right not to try and report what may be stored inside.

If it's not meant to be a jmicron_raid_member, then maybe it just happens to still contain the signature for some RAID configuration, for instance because the SSD used to be connected to a PC with ATA Mode set to RAID instead of AHCI in the BIOS (and you forgot to run blkdiscard before reusing it). Or maybe the 512th last byte happens to be J and 511th M by accident.

For blkid to stop detecting it as a jmicron_raid_member if you're sure it's not meant to be and the last 512-byte unit is otherwise not in use by anything, you'd need to wipe the RAID signature, which for jmraid is apparently found in the last 512 byte unit of the block device, either by hand with something like:

size=$(blockdev --getsize -- "$dev") &&
  dd if=/dev/zero of="$dev" seek="$((size - 1))" count=1

Or using util-linux' wipefs:

wipefs -t jmicron_raid_member -- "$dev"

to list the signature.

wipefs -a -t jmicron_raid_member -n -- "$dev"

To show what it would erase.

wipefs -a -t jmicron_raid_member -- "$dev"

To erase.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .