So while I am not wholly sure this is a qubes thing I am getting desparate trying to figure this out. I got a MSI B760M board and was able to boot up using a qubes installation usb stick and I seemed to be able to install to the hard drive fine, no errors or anything but then when i try to boot the newly installed setup it takes me directly to the bios? I thought this was a BIOS issue at first, it still may be, but I am able to boot to the USB just fine.
Before everyone says “did you check the boot order” yes, multiple times and the hard drive is set to boot first. What I can’t figure out is if its the hard drive then why can i install to it with no problem? If its the bios then… I have no idea, I have tried every setting i could find and researched this and many of the answers online involve either the boot order or the drive being bad. I have tried with Qubes 4.1 stable and the newest RC along with the newest kernel as well.
I was just hoping perhaps another MSI board owner might have some insights into this issue?
Well i have had something similar once but not in MSI, I hope it’s resolvable as easily 
.
can you please check whether there is an option to add a custom boot option , in my bios i could navigate to add one and specify a path for boot option referring to a file with a “.EFI” extension
I’m not referring to boot order but adding a custom boot
I had an issue like that when I installed Qubes R3.2 on a ThinkPad P52. The solution was to use rEFInd…
https://svensemmler.org/blog/2017/12/17/qubes-on-thinkpad-p51.html
Hi @Sven, first thanks for such a detailed blog post. So I just got around to trying this out, and I will admit I tried cheating a bit as at the moment my main thing is to ensure that Qubes will run, if yes, then I thought I’d put more time into getting it done correctly. So i trie dto just make a rEFInd usb and boot the qubes installation that I have, perhaps thats just not possible (ie need to go through all the steps and reinstall qubes as outlined in your blog?). Regardless, I thought I would ask. rEFInd saw the qubes installation but when i tried to boot it I got:
Starting xen-4.17.1.efi
using load options ' '
Error: Load Error while loading xen-4.17.1.efi
* Hit any key to continue*
If you tell me “man up and just work through every step - I’ll do it but I just wanted to ask if, in theory at least, it should have booted to Qubes?
and btw, I assume I’d skip the " Using USB-to-Ethernet adapter to run initial update” part?
So, while I had a bit of time I took a look at my install USB (made using dd) and there was actually no /EFI/BOOT/xen.cfg? I did a find . *.cfg and the only .cfg files I found were grub and when I opened them I did find a few instances of “LABEL” but can’t change them, I assume the livecd-iso-to-disk is meant to get around ISOs being read only? Am giving ISO Master a try
So i tried to use the livecd-iso-to-disk tool and got:
sudo livecd-iso-to-disk --efi --format Qubes-R4.2.0-rc4-x86_64.iso /dev/xvdi
ERROR: < Qubes-R4.2.0-rc4-x86_64.iso > is not a supported filesystem type.
Supported filesystems are fat|vfat|msdos, ext[432], btrfs, xfs, & f2fs.
Please adjust this option. Exiting...
perhaps R4.2 has quite a few differences from R3? (would make sense i guess)
Thanks for that. I took a look and there doesnt seem to be such an option (would be super happy if someone knows otherwise). will look around and see if there is some info out there about such an option on MSI boards.
You can try to add EFI boot entry from Qubes OS installer:
If it won’t work then you can also try to use EFI fallback and add it like this:
If it works then you can add postinst kernel hook so it’ll update these files automatically on dom0 updates:
Thanks @apparatus , sorry it took awhile to respond (things have been a bit crazy lately).
So I started to try the first option you mentioned. I guess my first questionare are for:
efibootmgr -v -c -u -L “Qubes OS” -l /EFI/qubes/grubx64.efi -d /dev/nvme0n1 -p 1 reboot change -d <which drive?> and -p <which efi partition?>
I am using a 2.5 disk at the moment, so /dev/sda (according to lsblk) so I (and I am asking here) would use /dev/sda instead of /dev/nvme0n1 but when you say are you refering to where I have qubes installed? (/dev/sda) and for I honestly have no idea - how would i determine which efi partition? (I think I understand disk partitions but not efi partitions I dont think?).
Here’s an example of how fdisk -l will look like:
You can see in last column that /dev/nvme0n1p1 partition has type EFI System so you need to use it in efibootmgr.
Thanks again. So I did a fdisk -l the sdb is my usb install media and the sda is the 2.5 where I installed qubes (and I dont have a nvme drive installed at the moment), sda2 is a 1G linux filesys, and sda3 is 929G (~1tb 2.5 drive) so that is where qubes is likely installed.
So sda1 is my EFI system/partition (am learning quite a bit here thanks!) so would I use:
efibootmgr -v -c -u -L “Qubes OS” -l /EFI/qubes/grubx64.efi -d /dev/sda3 -p 1 reboot change -d /dev/sda and -p /dev/sda1
btw, I started trying the second option you gave, am honestly not sure what the output meant and was a bit much to try to type correctly so I took a pic
You need to use this command:
efibootmgr -v -c -u -L “Qubes OS” -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1
It means that it added the Qubes2 EFI boot entry successfully.
Thank you again I feel its soooooo close but not quite there 
So. After using
efibootmgr -v -c -u -L “Qubes OS” -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1
I rebooted and viola! it booted into qubes, I logged in and (oooh so much faster than my previous ancient sys) but there were zero vms, only dom0 - which I guess makes sense in that when i rebooted it didnt take me to the setup (usually after install I then reboot, then on reboot it takes me to the setup where i can select VMs and templates etc to install) as i had thought it would. I didnt think too much of it as I now know how to use efibootmgr (gross overstatement but I though I could use the command you provided) so I tried to reinstall Qubes which, as before, went smoothly but when it came time to reboot the sys took me back to the BIOS screen so I rebooted using the Qubes install flash > went to rescue > shell > entered in the line you provided and this time it didnt seem to work? Now that I type this it occured to me that before I had followed your fallback option:
So i did that and it booted, i logged in, and it took me to the templates config but the whonix installation option was grayed out (unavailable), actually everything was unavailable except for selecting “do not configure anything (for advanced users)”. As i couldnt change anything I just accepted the config and it did its thing and ended with:
Qubes initial configuration failed. Login to the system and check /var/log/salt/ minion for details. You can retry configuration by calling 'sudo qubesctl--all state.highstate' in domO (you will get detailed state there).
@dom0$ sudo cat minion
2023-11-13 06:49:01, 191 [salt.pillar ](CRITICAL) Specified ext_pillar interface qm_prefs is unavailable
2023-11-13 06:49:03,032 [salt.pillar (CRITICAL) Specified ext_pillar interface qm_prefs is unavailable
Thats it, and the master and minion.install were blank/zero bytes
So tried sudo qubesctl --all state.highstate and got:
[bob@domo salt]$ sudo qubesctl - -all state.highstate
local:
ーーーーーーーー
ID: states
Function: no.None
Result: False
Comment: No Top file or master tops data matches found. Please see master log for details.
Changes:
Summary for local
ーーーーーーーー
Succeeded: 0
Failed: 1
ーーー-
Total states run: 1
Total run time: 0.000 ms
DOM0 configuration failed, not continuing
[bob@domo salt]$
So I am not sure if this is an RC bug or … I have no idea.
Try to rerun initial setup:
Thanks. I gave that a try but it just gave me the same error. I tried posting an issue, am hoping i did it correctly.
You can check the logs in /var/log/salt/ for specific errors.
Yep, that is part of what I posted in the bug issue. The thing is the master and minion.install logs are totally blank (zero bytes) and the minion log was pretty short:
@dom0$ sudo cat minion
2023-11-13 06:49:01, 191 [salt.pillar ](CRITICAL) Specified ext_pillar interface qvm_prefs is unavailable
2023-11-13 06:49:03,032 [salt.pillar (CRITICAL) Specified ext_pillar interface qvm_prefs is unavailable
Maybe you don’t have IOMMU/VT-d/VT-x enabled in BIOS?
Do you have any errors or failures in dom0 sudo journalctl?
I just double checked to make sure, it seems they are enabled?
had a hard time finding a pastebin that would accept such a large file, here is the output of the journalctl
Do you have a second unencrypted Qubes OS installed on one of your drives?
Check this issue:
I only have one physical drive attached, the one I installed Qubes onto (sda). When I’ve been reinstalling only one drive shows up, I selected, then opt to “reclaim space” (delete everything) and start over. Is there another way I could/should check to see if there are any “residual” things left?
You can check with fdisk -l that you only have a single drive and only 3 partitions on it (EFI, boot and LVM).
If it’s not the issue that I linked then it seems that Initial Setup partly worked and created the vm-pool but failed at some later step on your first boot after Qubes OS installation.
And now because vm-pool already exists running Initial Setup again don’t work:
Nov 13 07:49:16 dom0 org.fedoraproject.Anaconda.Addons.QubesInitialSetup[4406]: INFO:anaconda.modules.common.task.task:Setup up default storage pool
Nov 13 07:49:16 dom0 org.fedoraproject.Anaconda.Addons.QubesInitialSetup[4406]: INFO:program:Running... /usr/sbin/lvcreate -l 90%FREE --thinpool vm-pool qubes_dom0
Nov 13 07:49:17 dom0 org.fedoraproject.Anaconda.Addons.QubesInitialSetup[4406]: ERROR:org_qubes_os_initial_setup.service.tasks:['/usr/sbin/lvcreate', '-l', '90%FREE', '--thinpool', 'vm-pool', 'qubes_dom0'] failed:
Nov 13 07:49:17 dom0 org.fedoraproject.Anaconda.Addons.QubesInitialSetup[4406]: stdout: ""
Nov 13 07:49:17 dom0 org.fedoraproject.Anaconda.Addons.QubesInitialSetup[4406]: stderr: " Logical volume vm-pool already exists in Volume group qubes_dom0.
Nov 13 07:49:17 dom0 org.fedoraproject.Anaconda.Addons.QubesInitialSetup[4406]: "
Nov 13 07:49:17 dom0 org.fedoraproject.Anaconda.Addons.QubesInitialSetup[4406]: INFO:anaconda.threading:Thread Failed: AnaTaskThread-DefaultPoolTask-1 (124124273374912)
Maybe you can try to remove the vm-pool and rerun the Initial Setup but it’s not guaranteed to work.