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.
