Hi. Actually no. I do not need this much security measures at this moment. But if I ever do implement a similar feature, for sure I will write a guide on this.
I used the setup from this guide several times with no problems in the past, but in 4.3 RC2 it somehow didn’t work this time. Somehow after finishing the setup and rebooting the system, I got a boot failure.
Not sure if something changed in the new release or if I did something wrong this time, but essentially I had to put these lines in /etc/dracut.conf.d/crypt.conf:
Additionally, because of the new policy system in 4.3, I wasn’t able to attach my USB to dom0 anymore. I tried to add a policy in the Qubes Policy Editor:
Same here, the guide is still golden for 4.2, but not for 4.3
I had all the issues that @merowing mentioned. I think there’s something wrong with “getting password for disk encryption”, and my keyboard didn’t work (it works in grub and dracut emergency shell).
Luckily the update tool automatically created a LVM snapshot, and I was able to revert to it.
I read that when systemd modules is enabled in dracut, it uses systemd-cryptsetup, which is an independent implementation from cryptsetup, so it is natural that /usr/sbin/cryptsetup is not enabled. (I observed that systemd has been running in the dracut emergency shell)
Supposedly dracut should pick up entries from /etc/crypttab.initramfs and generate /etc/crypttab for initramfs. Maybe adding an entriy in /etc/crypttab.initramfs might help.
So this and the entry x-initrd.attach in /etc/crypttab are the only things I changed from the original guide, but I don’t know which additional entry actually caused it to work for me.
If I had to guess, I would say it’s the entry /etc/crypttab. I’ve read that dracut doesn’t always reliably include crypttab automatically in all setups. Therefore it’s probably more reliable to include it explicitly. /usr/sbin/cryptsetup is not necessary I guess, but it doesn’t hurt either.
But using systemd-cryptsetup-generator parameters is probably also a good alternative.
Basically it’s what I suspected, that there’s a bug where crypt module doesn’t work if systemd is enabled.
I’ve been also wondering why we have to manually add crypt or systemd-cryptsetup. After studying the code, my theory is the detached header prevents dracut from automatically detecting the filesystem type.
@merowing I’m not sure why your config works for you but not for me. I’d guess either you don’t have systemd module enabled, or you have some other LUKS encrypted devices (without detached header), which makes dracut to include systemd-cryptsetup. Perhaps you can verify using lsinitrd /boot/initramfs-...
Well I don’t have any other LUKS devices.
If I understand correctly, you upgraded from 4.2 to 4.3 right? Because I did a clean install of 4.3. Maybe that changed something? I don’t know. But it’s good that it worked out for you now too.
This is what lsinitrd -m /boot/initramfs-$(uname -r).img | egrep -i 'crypt|systemd' is showing:
I see, so systemd-cryptsetup is also enabled in your setup. I don’t know what triggered it, but it confirms my theory (that crypt itself doesn’t work when systemd is enabled).
Can this be combined with Heads? Is there any documentation or gotchas other than changing the boot device to the usb (/dev/sda or sdb, etc. depending on your disk setup)? I searched this topic for ‘heads’, as well as a search engine, and didn’t find anything relevant, and I skimmed the thread, but it’s a long one so pardon me if this is elsewhere. @Insurgo ?
Also, would it be theoretically possible to have multiple machines use the same USB for the detached /boot and header?
I also want to know this. It seems our first question is answered here:
But I also want to know, and I’m sorry if this is covered and I just didn’t understand it, can you have a boot partition/detached LUKS header and HEADS on the same USB, such as Nitrokey Storage? @apparatus or anyone who knows, I’d love to know, this is extremely useful for my needs and just what I needed but I am also poor.
Hello. I very appriciate your fix. It already helped me install Qubes 4.3 once. But you really have to edit this comment and add the hostonly=no line. Because this may confuse people who use your method. Like this already confused me today. I re-installed Qubes 4.3 again, watched your fixes in this comment but forgot that you added hostonly=no line later and installed Qubes without it, so have broken installation again. If this missing line were present in this comment this wouldn’t happen.
Thank you for producing this guide. I took the liberty of organising the instructions and included relevant fixes and adjustments, added some additional notes, and formatted the instructions for smoother execution and clarity. The instructions are to be found both here and in the following git repository:
Assumptions
For this guide, the devices are assumed to be:
Purpose
Device
Qubes OS installer USB drive
/dev/sda
USB bootloader and detached LUKS header drive
/dev/sdb
Internal disk
/dev/nvme0n1
Qubes OS installation partition
/dev/nvme0n1p1
EFI System Partition on USB bootloader drive
/dev/sdb1
/boot partition on USB bootloader drive
/dev/sdb2
Detached LUKS header partition on USB bootloader drive
/dev/sdb3
Opened LUKS mapper name
luks
Btrfs filesystem label
qubes_dom0
Warning: Device names such as /dev/sda and /dev/sdb can change between boots. Verify every device before running destructive commands.
1. Connect the USB Drives
Before proceeding, ensure that:
the Qubes OS installer USB drive is connected to one USB port;
the USB bootloader drive is connected to another USB port.
2. Configure BIOS / UEFI Settings
Ensure that virtualisation tools are enabled in BIOS / UEFI.
Ensure that Secure Boot is disabled.
3. Boot the Qubes OS Installer
Boot from the Qubes OS installer USB drive and select:
Install Qubes OS R4.3
4. Choose Language and Keyboard
Choose your language and keyboard layout.
5. Configure Time & Date
In the Time & Date menu:
Set your region and city.
Ensure the clock is set to the current UTC time.
Click Done.
6. Configure Software Selection
Enter Software Selection.
Ensure all items are selected, then click Done.
7. Create the User
Enter User Creation.
Set the username to your desired name and configure a unique password.
Click Done.
Note: Leave the root user disabled by default.
8. Open the tty2 Shell
Drop into the tty2 shell:
Ctrl+Alt+F2
9. Verify Free Space on the Internal Disk
Verify the location and size of the unallocated free space on /dev/nvme0n1.
Note the start sector, end sector, and total number of sectors.
sfdisk --list-free /dev/nvme0n1
10. Create the Qubes OS Installation Partition
Create the Qubes OS installation partition on the internal disk:
gdisk /dev/nvme0n1
For this guide, the resulting partition is assumed to be:
/dev/nvme0n1p1
11. Overwrite the Target Devices with Random Data
Prepare the devices and partitions used in this installation by overwriting them with random data.
Would any of you consider doing this guide solely on detached /boot and header? Currently, it looks like two different guides: this, along with BTRFS. I’d like to have a detached /boot and header without BTRFS, but I don’t know enough to remove BTRFS from the guide, and I don’t have the time to brute-force it.
If you don’t want to do this, could you point me in the right direction or maybe give some pointers on how to figure it out myself from the guide?
I could be wrong but the post linked below seems to explain how to construct the LVM structure instead of BTRFS. Also note that the last comment has updated instructions for 4.3 (just the edits)
I would assume just use this in place of the BTRFS part of the guide, but I haven’t tested or even read the post myself.
Thanks! I’m working on it now. It’s going well, but there are a few changes I’d heavily suggest from this: argon2(i/d/id) should be preferred over sha512, since it was designed for this function whereas SHA was not. Second, the EFI partition should be vFAT (vfat in the GUI), as ‘EFI Partition’ is nowhere to be found on 4.3 installer. Third, it should be noted that some installations require a 1MiB BIOSboot partition at the beginning in order to boot correctly.
I had a problem, but a reinstall fixed it.
That being said, I got all the way to the end and when I rebooted, it just looped at dracut expecting the qubes_dom0/root to be available before it prompted me for the password. Specifically, it hangs on
[ OK ] Finished systemd-vconsole-setup.service - Virtual Console Setup.
then loops something about dracut-initqueue, and then
Starting dracut-emergency.service - Dracut Emergency Shell…
Warning: /dev/mapper/qubes_dom0/root does not exist
Warning: /dev/qubes_dom0/root does not exist
Warning: /dev/qubes_dom0/swap does not exist
and then gives an emergency shell.
Do you know what may have happened?