Anyone has any other idea?
Hi.
What about trying with double quote for the name (or remove the space).
efibootmgr -v -c -u -L "Qubes OS" -l /EFI/qubes/grubx64.efi -d /dev/nvme0n1 -p 1
1 Like
I don’t see if you have a NVMe drive or normal HDD/SSD drive, so my suggestion would be to first locate the EFI boot partition like in:
In that post, it is a NVMe drive (/dev/nvme0n1) and the EFI partition is the first partition (-p 1)
efibootmgr -c -d /dev/nvme0n1 -p 1 -L "QUBES" -l '\EFI\qubes\grubx64.efi'
Had it been a SSD (eg. /dev/sdb) and partition 2 (-p 2), then I guess command should be something like:
efibootmgr -c -d /dev/sdb -p 2 -L "QUBES" -l '\EFI\qubes\grubx64.efi'
Disclamer: I’ve not tested that, since I don’t have Qubes on a SSD
As @szz9pza wrote: I you want a title with one/more space in, put "s around the title.
1 Like
Thanks for the replies, later I’ll try and I will let you know how it goes. Also whoever has the right solution gets 50$ in xmr for the help 
2 Likes
Very noble of you, sure.
Maybe tell us which version of Qubes you are using?
Some kernels work with some processors, and then there is that graphics problem. This is a thing, I feel it is reasonable to ask, rather than trying every possible option.
What, more precisely is your hardware? Processor. Graphics. How much RAM? Have you ever installed any Linux on the target computer?
Have you ever installed Qubes on this computer before?
If it was me. I would discover that I had failed to set the BIOS to use Virtualization. Or that I had somehow messed up putting a clean install of Qubes on the USB key.
There is an option in starting the Qubes ISO, for it to verify the Qubes ISO (which is not for security verification, as someone might try to slip you a false version of Qubes (which I have never read of anyone saying happened to them) test to verify the download is complete.
Might mention. Install is a two boots to finish. First boot, it asks question about which drive, instructions, and usually you set a Disc Password. Then you answer points about account name, account password, and have the option for advanced specifications of which Qubes to not install. Then you trigger it to write to disc. When it finishes, it will want to boot again. I am guessing this is the point where you are getting messages. I have a computer which has two drives, plus I added the USB Key with Qubes install on it. In some cases I need to removed the USB key so it will not start the beginning of the process again. but, for some reasons, while I thought I had the boot pointed to the correct drive. It tries the other drive.
If the problem with the Install is that it will not find a new drive that you want to install to, at the very beginning of the install. Sometimes my computers will not find a brand new drive. Format the new drive with something. In some way. Whether you use the disc formatter from Ubuntu (Gparted), or even a Windows Install. Every manufacturers drives will be seen by the Windows Installer. The manufacturers will make sure the most used OS can install to their drives.
I talk to much.
and in my case. When the install finishes, sometimes it asks for the account password first. While I enter that. I use the OS to shut it down, and do a restart.
so three boots to install.
1 Like
I use 4.1.2, the version that its mentioned in the hardware compatibility list for my components. It’s a high end cpu and mobo with 64gb of ram and no GPU.
On this machine I never installed anything but I made the qubes installer disk multiple times checking the ISO too.
Yes the issue is that after the first boot the system doesn’t detect a bootable device and it opens the bios settings instead of Qubes, but the install always finishes correctly and the live usb has no issue detecting and writing to the ssd (I checked that it was actually writing stuff).
I will try this cmd suggested above but I doubt that its an issue of the “” since I got no error message when running the command, and I probably tried without the quotes anyways, but in a few hours I will make sure its not that regardless.
You can check your EFI entries with:
efibootmgr -v
1 Like
I will relate an experience I had, and perhaps you can glean some common issue with what you are doing.
Since I have used Linux for some years (and am still not nearly as Linux knowledgeable as some others posting here) I use Legacy Mode. I have trying to use a Alienware 15 R2, (Skylake processor) which has an 256 gb M2 drive, and a one terabyte spinning drive. This is a old laptop, and I have installed a lot of different things to it. It was being odd, Which might be something with a Qubes install, or a hardware problem, and I wanted to isolate the possible reasons. Find what works, what is left must be the problem. I formatted the M2 to be blank with Gparted.
I installed the latest Windows 10 to the spinning hard drive, and updated Windows 10 to run the Dell Online Diagnostics. Which I spent a bunch more time installing the latest Firmware.
I tried to install the latest Qubes 4.2, where from a USB key, and it did the Qubes verification. And then. seemed to stop.
So I installed Qubes 4.1.2. Seemed to go all right.
I did the power down through Qubes, and it started Window s 10. Seemed like it was only going to see the Windows 10 drive to start on. Problem was, that I had, in the BIOS/EFI had left the setting to EFI. I changed that over. Had Secure Boot off. and it was in Legacy mode. then it would start Qubes 4.1.2
I have several security violations in this. One I should not have Windows 10 on the second drive while thinking this might be Secure. Whether the Qubes Install was made in EFI mode or not? Obviously not. I am not sure of all the implications of whether I should be using EFI, or maybe it really still is in EFI mode. But unless I put BIOS/EFI into Legacy mode, it would rather start Windows 10. If I did not have Windows 10 on the second drive, I guess it would hang.
I am lazy. If I were you. I would consider trying to install Ubuntu. And perhaps try to install version of Linux that needs Virtualization, and gives a good error message as to that - Virtualization is or is not working. That would test whether the Virtualization is working, not sure what Virtualization not working would look like to you? Where it would stop?
But you have more Linux experienced folks than myself helping you.
Cheers.
1 Like
I reinstalled everything from scratch, but unfortunately this did nothing, with:
I saw that the efi entry got created, but after I shut down the system, once again no bootable device was found.
Also I noticed that there was no /EFI/ directory, but this might be expected.
I guess the fact that Im using a very fast 2tb nvme ssd (samsung) could be an issue? Maybe that’s somehow not supported?
Boot into Qubes OS installer, switch to terminal with Ctrl+Alt+F2 and check if the EFI entry was removed:
efibootmgr -v
And check that you actually have EFI partition on your drive (is it /dev/nvme0n1 ?) on which you installed Qubes OS:
fdisk -l /dev/nvme0n1
Check if the first partition /dev/nvme0n1p1 has EFI System type.
Also did you disconnect your SSD from PC after installation? That would remove the EFI entry.
It should be on your EFI partition. Check if it’s there from Qubes OS installer terminal:
mkdir /mnt/efi
mount /dev/nvme0n1p1 /mnt/efi
ls /mnt/efi
ls /mnt/efi/EFI/qubes
The entry wasn’t there anymore. I tried to add it back but after the reboot it got removed again.
Yes it does have that.
No I didn’t disconnect it. But why would this remove the entry?
Yes you are right it’s there.
The EFI entries are stored in UEFI NVRAM on your motherboard and when you boot your PC without the drive that contains your EFI partition and the UEFI can’t locate the EFI entry then it’ll just remove this entry. So you can’t boot from removable media using the standard way and for this case you’ll have to use default/fallback boot path:
Tip: If you use the option --removable then GRUB will be installed to esp/EFI/BOOT/BOOTX64.EFI (or esp/EFI/BOOT/BOOTIA32.EFI for the i386-efi target) and you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer. Usually you can do this by selecting the drive itself similar to how you would using BIOS. If dual booting with Windows, be aware Windows usually places an EFI executable there, but its only purpose is to recreate the UEFI boot entry for Windows. If you are installing GRUB on a Mac, you will have to use this option.
Default/fallback boot path
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, grub-install will claim efibootmgr has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to install GRUB at the default/fallback boot path:
# grub-install --target=x86_64-efi --efi-directory=esp --removableAlternatively you can move an already installed GRUB EFI executable to the default/fallback path:
# mv esp/EFI/grub esp/EFI/BOOT
# mv esp/EFI/BOOT/grubx64.efi esp/EFI/BOOT/BOOTX64.EFI
I don’t know why your EFI entry is getting removed but you can use this method to boot your Qubes OS.
Sorry for the delay but I was abroad, that being said I think you found the solution but I messed it up.
First I tired running
grub2-install --target=x86_64-efi --efi-directory=esp --removable
But it didn’t find the esp directory, so I tried a few others directory but I couldn’t get it to work.
Then I tried:
But since there was no /esp/EFI directory I used:
To mount it and copy the files from qubes/ to BOOT/ and at reboot I finally got to boot into something, but instead of Qubes I got:
“Minimal BASH like line editing is supported GRUB”
(this)
So almost there I think?
You need to copy grub config as well:
mv esp/EFI/BOOT/grubx64.cfg esp/EFI/BOOT/BOOTX64.CFG
I didn’t test it but this should work:
sudo qubes-dom0-update grub2-efi-x64-modules
sudo grub2-install --target=x86_64-efi --efi-directory=/boot/efi --removable
This didn’t seem to help.
Here I get qubes-dom0-update command not found
I’m using the live usb recovery shell (rescue > option 3) am I using the wrong one?
My bad, it should be grub.cfg instead of grubx64.cfg.
Full steps from the beginning:
Copy files from /boot/efi/EFI/qubes/ to /boot/efi/EFI/BOOT/:
sudo cp -r /boot/efi/EFI/qubes/* /boot/efi/EFI/BOOT/.
Change filenames grubx64.efi → BOOTX64.efi and grub.cfg → BOOTX64.cfg:
sudo mv /boot/efi/EFI/BOOT/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.efi
sudo mv /boot/efi/EFI/BOOT/grub.cfg /boot/efi/EFI/BOOT/BOOTX64.cfg
This should be run from dom0 in Qubes OS.
1 Like
Thanks, it worked, dm me your xmr address. (I know its been a while, such is life)