Boot Qubes Even with Corrupted GRUB, Damaged Files, or NVRAM Issues Caused by Windows 11 or Another OS
When installing Qubes, backup the FAT and EXT4 partitions containing boot files, EFI, vmlinuz, initramfs, xen.gz, etc.
Assuming the FAT partition is at /dev/sda1 and the EXT4 partition with images, xen.gz, and initramfs.img is at /dev/sda2:
Check with lsblk -f, gnome-disks, or gparted.
sudo dd if=/dev/sda1 of=fatqubes.img bs=4096 status=progress
sudo dd if=/dev/sda2 of=ext4qubes.img bs=4096 status=progress
fatqubes.img is the FAT partition 1, and ext4qubes.img is the EXT4 partition 2. Store this backup on another SSD for when you need it!
Generate checksums:
sudo sha256sum fatqubes.img ext4qubes.img >> hashs.txt
sudo sha256sum /dev/sda1 >> hashs.txt
sudo sha256sum /dev/sda2 >> hashs.txt
Compare to verify everything is correct!
Whenever you update Qubes with sudo qubes-dom0-update, if the vmlinuz and initramfs images are updated, redo this backup. When restoring, restore to the most recent image!
You can check with uname -r, ls /boot, and ls /lib/modules.
If Boot Stops Working
If Qubes stops booting or there’s an NVRAM BIOS entry problem preventing boot or impairing Qubes mounting… how to resolve?
Solution: Restore .img Backups of FAT and EXT4 Partitions
Use a bootable Ubuntu Live USB stick or Qubes USB Installer Live in pendrive or another Live OS with grub:
Locate the SSD with the broken Qubes boot
Identify the FAT and EXT4 Qubes boot partitions (assuming FAT = /dev/sda1 and EXT4 = /dev/sda2)
sudo dd if=fatqubes.img of=/dev/sda1 bs=4096 status=progress
sudo dd if=ext4qubes.img of=/dev/sda2 bs=4096 status=progress
Generate checksums again and compare to verify everything is correct!
Then boot into Qubes…
If It Still Doesn’t Work Due to NVRAM Issues
Definitive Step
Step 1 (Recommended)
Boot images for manual boot are located at /boot/grub2/grub.cfg.
Use Ubuntu Live or the Qubes installation USB that has GRUB:
Boot from the USB stick
When entering GRUB, press c
Type ls
Discover which partition has the Qubes /boot/grub2 directory
Example: ls (hd1,gpt2) → output shows grub2
Then:
configfile (hd1,gpt2)/grub2/grub.cfg
Step 2 (Alternative)
To use EFI, but if .efi files are damaged it may fail. That’s why Step 1 is preferred!
Path: /boot/efi/EFI/qubes/grub.cfg
Find the partition, assuming it’s:
ls (hd1,gpt1)
configfile (hd1,gpt1)/efi/EFI/qubes/grub.cfg
Or in my case, this path appeared despite being /boot/efi/EFI/qubes/grub.cfg in dom0:
configfile (hd1,gpt1)/efi/qubes/grub.cfg
WARNING: Difficult, Low Usability, Time-Consuming… Not Worth It!
Not tested, but based on the grub.cfg file in /boot/grub2/grub.cfg
When there’s no GRUB file, or grub.cfg is corrupted, etc., and you need to reprogram it or you only have vmlinuz and initramfs.img:
Enter Linux Live or another Linux Live with GRUB (Qubes installation USB has GRUB, or Ubuntu Live or another):
At boot, type:
c
ls
Look for the partition with the vmlinuz and initramfs images. Assuming it’s ls (hd1,gpt2) and the output shows the files vmlinuz and initramfs.
Examples:
vmlinuz-6.18.26-2.qubes.fc41.x86_64
initramfs-6.18.26-2.qubes.fc41.x86_64.img
Command to use: #just exemple → uuid and images must be updated!
insmod part_gpt
insmod ext2
set root=(hd0,gpt2)
insmod multiboot2
multiboot2 /xen-4.19.4.gz placeholder console=none dom0_mem=min:1024M dom0_mem=max:4096M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096
module2 /vmlinuz-6.18.26-2.qubes.fc41.x86_64 placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=luks-a1Z7d3d4-e1v6-7490-abcd-ej123456w890 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rhgb quiet usbcore.authorized_default=0 xen_privcmd.unrestricted
module2 --nounzip /initramfs-6.18.26-2.qubes.fc41.x86_64.img
boot
ALERT! BIOS NVRAM Is Corrupted by Other OS Entries Using the PC, Especially Windows 11
Even if you removed the Qubes SSD from the PC, used Windows 11, and then reconnected the Qubes SSD for security—Windows 11 generally still corrupts the NVRAM and prevents Qubes or Linux from booting, even with separate SSDs that were disconnected during Windows use! Thousands of people are reporting this online! In Windows 10, this didn’t occur!
The procedure above solves this problem!
Many people use other OSes on the same PC as Qubes for gaming or other tasks…
Using dual-boot on the same SSD as Qubes is insecure because Qubes FAT and EXT4 partitions will be exposed to Windows 11 when you’re using it, or even another OS like Tails or regular Linux.
Using separate SSDs or HDDs and selecting boot priority in BIOS doesn’t eliminate the risk!
If Windows 11 is on SSD1, for example, and Qubes is on SSD2, and you shut down Qubes and select boot in BIOS for Windows 11 on SSD1, when Windows starts, it will be possible to see the FAT and EXT4 partitions of Qubes OS (see ext4 in windows need some additional tools do to it), and they can be attacked or corrupted. Additionally, a hacker inside Windows or Windows itself could collect metadata that Qubes OS is used on this PC!
So a possible solution would be:
Whenever you’re going to use Windows, a different Linux, Tails, physically disconnect the SATA and power cable from SSD2 that has Qubes installed. When you boot Windows 11 or another OS, the FAT and EXT4 partitions with Qubes images won’t be accessible.
When you want to use Qubes, reconnect the cables and resume use.
The problem is usability and immense time loss doing this!
Possible Solutions:
- Reset the BIOS, but you’d have to reconfigure it completely, which could take a very long time.
- Use bootable USB sticks like Ubuntu Live, select them in BIOS to boot, start, restart multiple times to clear NVRAM, then select Qubes in * BIOS and boot! This can take time and doesn’t always work!
- Start Ubuntu Live in BIOS, when entering GRUB, press c, and reboot. Doing this multiple times usually works to clear NVRAM!
- Restoring initial partition backups with old images usually works right away but takes time.
- Restoring partitions with the latest backup image often fails because NVRAM corruption or bugs caused by Windows 11 and its Fast Startup * mode (which leaves Windows 11 hibernated) may prevent boot!
- What usually works and is faster is using Ubuntu Live or a bootable Qubes installation USB, when entering GRUB, typing: c, entering manual GRUB, and performing the Definitive Step 1 procedure. This is the fastest method.
Recover GRUB with Terminal Restoration in dom0 or Qubes Restoration Tools
Generally these procedures fail, and what usually fixes it is when there’s a new dom0 update, including a new kernel and initramfs—the update fixes the FAT and EXT4 partition files for Qubes boot! Many report frustration trying to restore Qubes GRUB boot partitions and files using these tools, besides taking a very long time!
A better cost-benefit solution is to always use Definitive Step 1 from this guide to continue booting Qubes with the latest image until the next update fixes the boot! If it doesn’t fix it, the only option is to boot this way!
Even with Secure Boot and other boot security tools, I believe this is a path for attack exploitation to steal passwords from Qubes, Linux, and other OS SSDs through NVRAM corruption… I haven’t discovered this, but I believe it’s a path for such exploitation!
What I Believe Is Safer:
Boot into Qubes and any OS, always using Definitive Step 1:
Using Ubuntu Live or a bootable Qubes installation USB:
Access manual GRUB by pressing c when it starts
Boot manually
Example:
configfile (hd1,gpt2)/grub2/grub.cfg
Daily preferably or weekly:
Check Qubes partition hashes by entering with Ubuntu Live or another Live OS:
sudo sha256sum /dev/sda1
sudo sha256sum /dev/sda2
See if the hash is the same! Then perform this manual boot!
Also keep Secure Boot always enabled!
Many think Qubes was broken because they couldn’t start it, formatted it, spent hours, and lost a lot of time! And the fault is NVRAM BIOS corruption by another OS or Windows 11 + hibernation in Fast Startup mode!
Performing the manual boot procedure serves to know if the OS is intact and bootable and diagnose that the problem is corrupted boot files or partition!
If you can’t fix it, it’s better to always do manual boot this way than to format and lose the entire day on this!
Disabling Windows 11 Fast Startup? It doesn’t work. Either it fails, or Windows 11 suddenly starts doing the same thing again! Unfortunately, users don’t have full control over this system.
Ideal Recommendation
Use a dedicated PC just for Qubes. If you’re going to use another OS on this PC, ideally remove all cables from the SSD that has Qubes installed so this new Live or persistent OS never has access to the non-encrypted Qubes FAT and EXT4 boot partitions! The problem is usability and immense time loss doing this!
Boot Tails or another Linux while the Qubes SSD is still connected
- Have the hashes of the Qubes FAT and EXT4 partitions written down on paper
- Keep Tails or another Linux offline, never connect online!
- Get the hash of the partitions and compare with the ones written on paper
- Assuming the partitions are at sda1 and sda2
sudo sha256sum /dev/sda1
sudo sha256sum /dev/sda2
- Boot Tails or another Linux online
- Do your operation, usage, browsing etc… and after finishing
- Keep Tails or Linux offline
sudo sha256sum /dev/sda1
sudo sha256sum /dev/sda2
- If the hash is the same, it was not touched and is intact…
- then you can go back to using Qubes normally because the partitions are intact!
Should I do this on Windows 11 or another dangerous OS?
Better not, on dangerous OSes that collect data like Windows, it is better to remove the SSD cables and avoid metadata collection!