Yes, I followed the guide to the letter, several times over, as well as the video. I made sure to mount my boot device in the GUI and format the EFI partition and mount it to /boot/efi as well as the boot partition and mount it to /boot/.
I appended the rest of the ls -R /boot | grep efi results for further clarity.
I have seen this guide, and it’s surely the next attempt that I’ll make if this doesn’t work. I’m using this guide because it’s supposed to be ‘THE’ guide.
BEFORE running cp -r /usr/lib/grub/x86_64-efi /mnt/sysroot/boot/efi/EFI/qubes/, I checked that the destination directory exists. It exists.
I checked that the source directory contains the necessary files. They exist.
I made sure to always put the dot at the end of the tar command.
I am trying to run grub2-mkconfig again and it’s resulting in the same error as before, with no change. I have not shredded my backed up boot.tar this time.
Interestingly, while chrooted into the Qubes installation, when I go to check the contents of /boot/efi/ on my chosen boot drive, I see all the normal boot related files, but I don’t see any qubes directory.
When I exit chroot root and run lsblk, I see that my boot device isn’t mounted at /sysroot/ but rather at /sysimage/. Maybe this has something to do with this command (cp -r /usr/lib/grub/x86_64-efi /mnt/sysroot/boot/efi/EFI/qubes/) not copying anything?
I found this guide here also, but the author hasn’t been able to answer questions relating to issues while following his guide.
I found my own solution. For anyone who has followed these instructions and came to a similar issue as I have, please carefully analyze which boot partition you are wiping to setup the encrypted /boot partition on. In my case, I was wiping the /boot/efi partition when I should have been wiping the /boot partition. This resulted in erasure of my work up to the point of execution.
How is it possible to configure crypttab and dracut to find the detached LUKS header (which would normally be at /dev/sda3) by using UUID instead of by drive location, as instructed in the guide:
This snippet here: header=/dev/sda3\nluks-$uuidB means what exactly? My understanding is that the header at /dev/sda3 will be used to decrypt the drive, but if the USB happens to be moved and it can’t be found at /dev/sda3, does this mean that it will instead search for luks-$uuidB? Please clarify. Thank you.
How can we install Qubes like this without creating an nvram UEFI boot entry and making the USB drive bootable on its own without the said entry?
The UEFI entry calls to \EFI\qubes\grubx64.efi , so even if we have a detached bootloader and detached LUKS, an attacker still can know that there is a trace of Qubes OS on the system.
Not only this, if somebody finds a drive with random bytes plugged into a system they’ll know it’s encrypted. Every cipher has a fingerprint so it would be obvious what’s going on.
I noticed that you’ve installed Qubes OS inside a StandaloneVM, an efficient testing environment. I’m currently trying to install Qubes OS inside a StandaloneVM as well, for the same reasons.
How did you enter TTY2 on the VM, without entering TTY2 on dom0?
Hello
I wanted to give this a try, but now I’ve run into a problem where I don’t know what to do.
I have done the first part, then switch back to the menu and select my ssd and usbstick.
But then I can only format qubes_dom0-swap
I can’t do anything with Qubes_dom0-root
When creating the partitions I got this error code :
Thin pool volume with chunk size 64.88 KiB can address at most 15.81 TIB of data.
Volume group “qubes_dom0” has insufficient free space (5139 extents): 7680 required.
I’m bookmarking this for next time I have time to horse around with my Qubes system. Having a separate boot drive is a 9001 IQ idea, specially for Qubes
Sorry for the ignorance, but how come a user can’t just simply select separate drives for boot/swap/root in the automated installer and be done with it?