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
Since hosting is not working - maybe someone still has a video tutorial?
1 Like
The video is no more available and the “installation part” is missing is this guide…
Can someone write the missing part or reupload the video please?
Thank you!
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.
An answer would be very cool.
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
Can someone please re-upload the video somewhere ?
It is not available anymore.