I changed it, but results in the same error:
/sbin/grub2-mkconfig: line 246: /boot/efi/EFI/qubes/grub.cfg.new: No such file or directory
The path I suggested should work. Are you chrooted into the new Qubes installation when you run the command? Or are you running it in the live’s shell environment?
I am using your suggested path. I am chrooted into the new Qubes installation by chroot /mnt/sysroot/ as instructed in the guide.
Try to force create the file:
touch /boot/efi/EFI/qubes/grub.cfg.new
or if it requires some content:
cat /boot/efi/EFI/qubes/grub.cfg > /boot/efi/EFI/qubes/grub.cfg.new
touch /boot/efi/EFI/qubes/grub.cfg.new fails with:
touch: cannot touch '/boot/efi/EFI/qubes/grub.cfg.new': No such file or directory
and of course, cat fails with No such file or directory as well.
I’m not the most inclined Linux user. This guide has been a challenge.
Run the following
ls -R /boot | grep efi
Do you see any output or do you get an error?
Do you see /boot/efi/EFI/qubes ?
I suspect you might’ve launched the installer in legacy (BIOS) mode instead of UEFI.
I understand, it’s a learning curve.
My hardware doesn’t support legacy BIOS, only UEFI, afaik.
I ran ls -R /boot | grep efi, the result is:
efi
/boot/efi:
efi
/boot/efi/efi:
/boot/efi/grub2:
/boot/efi/grub/themes:
/boot/efi/grub/themes/qubes:
/boot/efi/loader:
/boot/efi/loader/entries:
/boot/efi/lost+found:
I don’t see /boot/efi/EFI/qubes in the list
Then boot wasn’t installed. Did you select the correct partition in the installer GUI, after refreshing the drives?
Oh ok you were missing some entries
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.
Our edits on edits.
Let’s try to rebuild it then.
Check if the archive still exists:
ls /tmp/boot.tar
Unfortunately, the archive was shredded, as per the instructions shred -uvz /tmp/boot.tar. I’ll reboot and rebuild everything from scratch, again.
Is there anything that can be rebuilt from the boot device at /mnt/sysimage/boot ?
When you get to the first step after the installation (cp -r /usr/lib/grub/x86_64-efi /mnt/sysroot/boot/efi/EFI/qubes/), check a few things:
Check if the destination directory exists:
ls /mnt/sysroot/boot/efi/EFI/qubes
Check if the source directory contains the necessary files:
ls /grub/x86_64-efi
Then when you get to the tar step, make sure that you include that dot at the end:
tar -C /boot --acls --xattrs --one-file-system -cf /tmp/boot.tar .
OR: you can try this other guide instead (a bit more outdated but it’s always worked for me): Qubes OS Installation - Detached encrypted boot and header
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:
echo -e “luks-$uuidR /dev/nvme0n1 /etc/keys/root.key luks,discard,key-slot=1,header=/dev/sda3\nluks-$uuidB UUID=$uuidB /etc/keys/boot.key luks,key-slot=1” > /etc/crypttab
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.
Any idea how this is possible @51lieal
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.
Why would someone detach their LUKS header? What purpose does this serve?
I think Heads is probably better than doing all this if you’re trying to make sure nobody can make changes without you knowing.
My answer? to prove there’s no encrypted device.
and both has different use.
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?
For anyone searching for this answer too, I found a solution that I’ve described here: using USB keyboard attached to the VM