Qubes 4.1 Not booting after bios update please help

Hi, I had installed qubesos according to this guide
Detached Header

Boot menu was missing every time i re-plug my detached usb drive. I was able to add it using efibootmgr -c -v -u -L option.
But,
I updated my motherboard bios to latest after the update i’m not able to boot qubes to add my missing uefi boot menu entry of qubes.

I’m using Nvidia 2060 Graphics card and disabled it during boot. It ends up with dracut timeout and I can’t access keyboard to save logs.

My backup restore isn’t working too says header missing.
Please help
Thank you.

Things i did after bios update:

  1. Loaded optimized default settings.
    SVM Mode: Enabled
    SMT Mode: Auto
    IOMMU: Enabled
  2. Tried to boot with uefi and also legacy
  3. Tried to boot fedora live and it successfully boots up

Keyboard doesn’t work in dracut here?
https://forum.qubes-os.org/uploads/db3820/original/2X/5/5b696fe0b5f65457fca3c5e00433f7e251a42d74.jpeg
Do you have USB keyboard? Maybe you have disabled USB devices in GRUB?

Yes. Keyboard doesn’t work there.
Yes I only have USB keyboard and didn’t disable USB devices in grub.

Will try to boot with the latest-kernel iso - Qubes-20220528-kernel-latest-x86_64.iso

Update : The latest kernel iso gives me some GUI three dots and stuck in legacy mode.
Not booting in uefi mode too.

Maybe try to disable USB 3.0 in BIOS or check other USB settings like xhci hand off.

Disabled Asmedia 3.1. I can use the keyboard now going down into rabbit hole.

The problem is qubes boots successfully if IOMMU is disabled in bios. If it’s enabled the qubes doesn’t boot.

update: I’m able to finally boot into my old qubes but as IOMMU is disabled no Appvm are started only dom0 not network nothing.

Maybe try to install kernel-latest (maybe even from current-testing repo). It may be fixed there.

How to i do that? My old qubes boots up if IOMMU is disabled, If i enable it or set it to auto it doesn’t work.

are you asking me to update my kernel on my old qubes installation?

It’s been 5 days since the bios update and this the closer i got to fixing the problem.
Any help is appreciated. Thank you.

Download kernel-latest:
https://yum.qubes-os.org/r4.1/current/dom0/fc32/rpm/kernel-latest-5.16.18-2.fc32.qubes.x86_64.rpm
or from current-testing
https://yum.qubes-os.org/r4.1/current-testing/dom0/fc32/rpm/kernel-latest-5.17.7-1.fc32.qubes.x86_64.rpm
Mount dom0 from Qubes installer rescue or Live USB or from your working OS and copy the rpm to the dom0-root.
Then boot in Qubes and install kernel-latest there:
sudo dnf install /path/to/kernel-latest.rpm

it should be to your updated bios problem i think,
and are there any grub password pop out ? and since when you try the guide ?

it’s been over a 6 months. Yeah the updated bios is acting strange i’m trying all combinations to see which one works. There are so many settings about my CPU

I have added the boot menu entry but after entering password it takes forever to decrypt or start login screen.

What i understand qubes specific settings that i need to work are

  1. virtualization enabled.
  2. IOMMU enabled.
  3. secure boot off
  4. TPM off

Due to dracut timeout errors i tried flashing several times in different os.
I can’t restore my backup too, I can boot to dom0 if IOMMU is disabled.

I guess there is a problem with USB controller driver in kernel for your updated BIOS. So dracut can’t find your USB drive with detached header.

UPD:
On second thought since you’re entering password then it did find the USB drive with detached header so it’s not a problem.

  1. did you see those grub password ? (if you did encrypted boot)
  2. did you use decrypt with key as explained in the guide ? if yes, then there’s something wrong with the initramfs.

https://forum.qubes-os.org/uploads/db3820/original/2X/2/2cece29fb9b94f3980a4c36bc3c839308727096b.png

I get the following screen but if IOMMU is enable after this no login screen

To troubleshoot the issue i accidentally boot up fedora-live and issued the following command
efibootmgr -v -c -u -l QubesOS -l /EFI/qubes/grubx64.efi -d /dev/sde -p 1

after this i got the disk password and didn’t login.

I think we need a glossary first here.
the boot process would be :

  1. grub password.
  2. grub menu.
  3. boot splash / dracut.
  4. lightdm login screen.

what happen after you enter grub password?
are there any grub menu pop out ?
explain to me what thing you do after can’t boot?
and please enable all requirement to run qubes os.

  1. grub password. YES
  2. grub menu. YES
  3. boot splash / dracut. YES
  4. lightdm login screen. NO

after entering the boot grub password it used to go directly to lightdm login screen.
But after the bios update no lightdm screen stuck at boot splash.

if IOMMU is disabled. I can boot successfully

Update : Enabled IOMMU disabled SMT.
everything is working fine now. My problem is solved but i’m still unsure why the backup didn’t restore.

disabling SMT solved my problem. Thank you everyone for guiding me i wouldn’t have made it without you guys.

I’m getting a new error

/dev/mapper/qubes_dom0/root does not exist
/dev/qubes_dom0/swap does not exist

Can anybody please help?

These errors most probably mean that your Qubes LUKS partition wasn’t decrypted for some reason.
Are you ending up with dracut-initqueue timeout here?
https://forum.qubes-os.org/uploads/db3820/original/2X/5/5b696fe0b5f65457fca3c5e00433f7e251a42d74.jpeg
Can you copy log from there and check it for errors or upload it here?

last night i was trying to install windows 10 on my 240GB ssd but it created partition on nvme0n1.
My qubes luks partition couldn’t be decrypted for this reason.
Linux and Windows don’t go well together.

I can find EFI and windows recovery partition on my nvme. so i guess nothing can be done at this stage?

You tried to install Windows on SSD that has Qubes with detached header?
Or you tried to install Windows on another SSD but Windows ended up creating partitions on your Qubes SSD?
Since all your Qubes SSD was encrypted and you had detached header then WIndows just treated all your disk as free space.
You can try to manually decrypt your nvme0n1 but I’m not sure if it’s possible to recover LVM when it was partially overwritten, assuming /dev/nvme0n1 - your Qubes disk and /dev/sde1 - detached header:

sudo cryptsetup luksOpen /dev/nvme0n1 qubes_dom0 --header=/dev/sde1
sudo vgchange -ay

Or you tried to install Windows on another SSD but Windows ended up creating partitions on your Qubes SSD? YES fuck windows!