1

Summary of the problem. I want to use a detached luks header for a luks-encrypted block device, /dev/nvme0n1p1, by making it into a USB flash drive partition, and afterwards erasing the keys that are on the header of the block device. I have limited details on how to do it, but my plan is to (1) set the size of the flash drive partition, /dev/sda3, to exactly the size of the header. Then (2) use dd if=/dev/nvme0n1p1 of=/dev/sda3 bs=4096 count=4096 to overwrite the space on the new partition with the header information. (3) Enter the header into the options of /etc/crypttab and generate new initramfs. I hoped this would work. But after I ran the dd-command (without yet editing crypttab) I tried to rebuild initramfs, but received the following error:

$ update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-5.10.0-18-amd64
cryptsetup: ERROR: nvme0n1p1_crypt: Source mismatch
update-initramfs: Generating /boot/initrd.img-5.10.0-9-amd64
cryptsetup: ERROR: nvme0n1p1_crypt: Source mismatc

My questions are: (1) Why am I getting these errors? I don't understand why copying data should cause an error on the file system from which I am reading. (2) What's the right way to write the header to flash drive, if it is not with dd.

Details and any research. I have searched google and stack exchange, and the seemingly most relevant thing was this. When I ran the command, I received the following information.

$ dmsetup info -c --noheadings -o devnos_used -- "nvme0n1p1_crypt"
259:1

Also this guide that I linked to above (in my opinion) seems to suggest that I should do it in this way.

1
  • 1
    it shouldn't matter, but you are using dd to transfer 4096*4096 bytes. I'm also concerned that something is scanning the usb drive and seeing the luks header and getting confused with duplicate luks uuids. why not just make the detached header a file on a filesystem inside the flash drive?
    – toppk
    Oct 3, 2022 at 3:33

1 Answer 1

1

When you bring up having to update the initramfs and crypttab, I presume this encrypted block device is part of your system's boot process? In which case, if you're going to be copying the header from the partition directly, the drive should be unmounted which would be ideal that you're performing all this from a USB Live-boot environment so that the drives aren't mounted, especially if the partition you're wanting to copy the header from is your primary system.

Assuming that is what you're doing, and you're currently attempting this from a USB Live boot environment (which would explain the error), make sure you've bind mounted the boot partition of the system you're trying to update the initramfs for as part of chrooting into the system to update it.

Buuuuuut....it should be noted that you wouldn't have any need to update your initramfs if you didn't make changes to crypttab yet, so I'm not sure I want to overload you with solutions that might not apply. So to back up a bit...

If you weren't trying this from a USB Live Boot environment, no worries, just follow option 2 of the guide you linked last where instead of using dd to copy the raw header directly, you can use cryptsetup to generate the backup header as a file, then write the file using dd to your USB flash drive partition as explained.

Whereas I've adopted their instructions to match your needs and added some notes in case anything was unclear (and identified each newline starting with a "$" to indicate it's the start of a new command:

 $ sudo -i
\\ just to ensure running everything below as root without a need to add sudo

$ mkdir /tmp/header_backup
$ mount -t tmpfs -o size=512m tmpfs /tmp/header_backup
\\ this user just took extra precaution by writing the backup header file to ramdisk
\\ which is unnecessary so u could just skip straight to the next step and designate
\\ somewhere normal like /home/USER/Documents if you wanted

$ cryptsetup luksHeaderBackup /dev/nvme0n1p1 --header-backup-file /tmp/header_backup/header.luks
$ dd if=/tmp/header_backup/header.luks of=/dev/sda3
$ umount /tmp/header_backup

\\ Then update crypttab, using your preferred text editor, here i use nano
\\ Here you're just appending the header option so if nvme0n1p1 is listed
\\ and shows as nvme0n1p1_crypt, then simply add it after the last option

$ nano /etc/crypttab

nvme0n1p1_crypt {UUID of /dev/nvme0n1p1} none luks,discard,header=/dev/sda3

\\ for nano, ctrl+x then Y then Enter & Enter again to exit and confirm saving
\\ At this point you're going to have 2 devices sharing the same UUID so
\\ you can address this by changing the one for the USB drive since it got
\\ changed when you copied the header to it, and saves you from updating fstab

$ cryptsetup luksUUID /dev/sda3 --uuid $(uuidgen)
\\ THEN you can run...

$ update-initramfs -u -k all

To be sure, /dev/nvme0n1p1 is the original LUKS drive and /dev/sda3 is the USB drive partition you want to store the header on.


Now, just to review your questions:

My questions are: (1) Why am I getting these errors? I don't understand why copying data should cause an error on the file system from which I am reading.

There's two possibilities I can think of that depend on specifically where you're running these commands from, as in, are you currently booted from a system that is located on nvme0n1p1? Or from a USB-Live Boot system where you are making the changes from a system totally separate from the one stored on nvme0n1p1? In the former, it's possible that /dev/sda3 was not unmounted before you wrote the header to that partition which would've changed the meta data of the USB partition while it's still mounted and confusing the system when running update-initramfs without any changes to the actual boot file settings or in the latter you didn't chroot into the system within nvme0n1p1 properly before running update-initramfs so it's reading the boot drive mounted in the Live-Boot and not the system you're updating. In either case, remember that crypttab refers to the mapped name of the partition, so whatever is in crypttab should match what is shown in your fstab as fstab is what mounts the drive by UUID and not by the device mappying name shown or used in crypttab

But, again, just remember that

(2) What's the right way to write the header to flash drive, if it is not with dd.

Though there are other ways to write it, the way you're doing it is correct, it may just be a matter of what you're either not doing with that command (such as unmounting the partition before writing to it or if writing directly from another device that both devices are umounted)

If it helps, in following the last guide you linked that I modified the commands for above, bear in mind that your /dev/nvme0n1p1 is their /dev/sda4 and your /dev/sda3 is their /dev/sdb in the answer. Not to be confused with how in their question, it originally mentioned /dev/sda3 as their USB partition for the header as it was later changed when added an answer to their own question.

You must log in to answer this question.

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