actually wipefs -a is enough, it would erase crypt metadata too.
you may want to try using iter 1 first for practicing while wait for me to rewrite better guide.
correct me if i am wrong but there is still the problem with our current new disks ssd / nvme and iirc even newer hdds having the key remaining in their little extra cache after use.
Forgive me that i do not have the correct technical terms for all this but i think as long as we do not know how this caches work and how to proper clear them with each shutdown, no one should feel 100% secure, of course it all is depending on the individual thread vector.
Instead of creating luks header on disk with: [anaconda /] cryptsetup luksOpen /dev/nvme0n1 luks
And later removing it from disk as described in this guide you can just create luks with specified key file:
Also it’s better to specify drives by their ID instead of arbitrary name like /dev/nvme0n1 or /dev/sda3:
cryptsetup open /dev/disk/by-id/usbdrive-part2 cryptboot
cryptsetup --header /mnt/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=‘‘offset’’ --keyfile-size=‘‘size’’ open /dev/disk/by-id/harddrive enc
usbdrive is your USB drive by-id, and harddrive is your main hard drive by-id.
you are correct, that’s why i decided to write full guide and using tmpfs for dom0 and dispvm. that would be part 4 of Running dom0 and DispVM in tmpfs.
the problem is if we did detach header before installation, anaconda would’nt understand that. try it, it would fail.
that’s correct, in my new quick install here, I already leave 10% free space
I just practiced again and found an error I forgot to post last time. It’s the very first error I encounter in the process. Here’s the error along with the few commands just before it:
[anaconda root@localhost /]# pvcreate /dev/mapper/luks
Physical volume "/dev/mapper/luks" successfully created.
[anaconda root@localhost /]# vgcreate qubes_dom0 /dev/mapper/luks
Volume group "qubes_dom0" successfully created
[anaconda root@localhost /]# lvcreate -n swap -L 4G qubes_dom0
Logical volume "swap" created.
[anaconda root@localhost /]# lvcreate -T -L 20G qubes_dom0/root-pool
Thin pool volume with chunk size 64.00 KiB can address at most 15.81 TiB of data.
/usr/bin/dmeventd: stat failed: No such file or directory
WARNING: Failed to monitor qubes_dom0/root-pool.
Logical volume "root-pool" created.
The other error I posted before also pertains to dmeventd. Even if nobody here has a solution, it helps to document and share errors.
For a key, I recommend /dev/random instead of /dev/urandom. The former ensures high entropy. (though I don’t know the answer to the rest of your question)
If you’re talking about this: dd if=/dev/urandom of=key.img bs=32M count=1
Then I think it shouldn’t really matter because cryptsetup will use /dev/random when it’ll initialize a LUKS partition here: cryptsetup luksFormat key.img
And the key used to encrypt /dev/sda later won’t be raw key.img file created from /dev/urandom but the decrypted key.img file that was encrypted with key from /dev/random.
I will try later, I remember in my first research, it failed.
don’t bother with the error, just proceed you’ll be fine, and you may want to follow the progress above instead of #1, and look for #1 or in btrfs thread for the image.
Maybe it’ll work if you use PARTUUID /dev/disk/by-partuuid/ instead of UUID?
UUID is a filesystem-level UUID, which is retrieved from the filesystem metadata inside the partition. It can only be read if the filesystem type is known and readable.
PARTUUID is a partition-table-level UUID for the partition, a standard feature for all partitions on GPT-partitioned disks. Since it is retrieved from the partition table, it is accessible without making any assumptions at all about the actual contents of the partition. If the partition is encrypted using some unknown encryption method, this might be the only accessible unique identifier for that particular partition.