Fixing “No multiboot header found” Error After Dom0 Update

Original forum link

https://forum.qubes-os.org/t/34742

Original poster

barrulus

Created at

2025-07-08 14:01:42

Posts count

1

Likes count

3

Tags

troubleshooting

Qubes OS: Fixing "No multiboot header found" Error After Dom0 Update

Problem Description

After attempting to update dom0 in Qubes OS, the system fails to boot with the error:

Loading xen 4.17.5
Error: No multiboot header found

This guide documents a successful recovery process for a system with the following configuration: - LUKS2 encryption - btrfs filesystem with subvolumes - EFI boot - Multiple NVMe drives

System Configuration

Hardware Setup: - Primary drive: nvme0n1 (465.8G) - Contains EFI and boot partitions - nvme0n1p1 (512M) - EFI System Partition - nvme0n1p2 (1G) - Boot partition - nvme0n1p3 (464.3G) - LUKS2 encrypted root filesystem - Secondary drive: nvme1n1 - Additional storage

Filesystem Layout: - Root filesystem: LUKS2 → btrfs with subvolumes - Subvolumes: - @root - Main root filesystem - @home - Home directories - @varlibqubes - Qubes-specific data - @templates - VM templates - @root:var/lib/portables - Systemd portables

Recovery Process

Step 1: Boot from Rescue Media

Boot from your Qubes installation USB/DVD and access the rescue shell.

Step 2: Identify Your Disk Layout

lsblk

Identify which partition contains your LUKS2 encrypted root filesystem. In this case, it was /dev/nvme0n1p3.

Step 3: Decrypt LUKS2 Partition

cryptsetup open /dev/nvme0n1p3 luks-root

Enter your LUKS passphrase when prompted.

Step 4: Examine btrfs Subvolume Structure

# Mount temporarily to see subvolumes
mount /dev/mapper/luks-root /mnt

# List all subvolumes
btrfs subvolume list /mnt

Note the subvolume names and their purposes.

Step 5: Mount Filesystem with Proper Subvolumes

# Unmount temporary mount
umount /mnt

# Mount root subvolume
mount -o subvol=@root /dev/mapper/luks-root /mnt

# Create mount points and mount other subvolumes
mkdir -p /mnt/home
mkdir -p /mnt/var/lib/qubes
mkdir -p /mnt/var/lib/portables

mount -o subvol=@home /dev/mapper/luks-root /mnt/home
mount -o subvol=@varlibqubes /dev/mapper/luks-root /mnt/var/lib/qubes
mount -o subvol=@root:var/lib/portables /dev/mapper/luks-root /mnt/var/lib/portables

Step 6: Mount Boot Partitions

# Mount boot partitions
mkdir -p /mnt/boot
mkdir -p /mnt/boot/efi
mount /dev/nvme0n1p2 /mnt/boot
mount /dev/nvme0n1p1 /mnt/boot/efi

Step 7: Prepare Chroot Environment

# Bind mount essential filesystems
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run

# Chroot into your system
chroot /mnt

Step 8: Verify Installed Packages

# Check installed Xen packages
rpm -qa | grep xen

# Check installed kernels
rpm -qa | grep kernel

Step 9: Regenerate GRUB Configuration

This is the key step that fixes the multiboot header issue:

# Clean package cache
dnf clean all

# Regenerate GRUB configuration
grub2-mkconfig -o /boot/grub2/grub.cfg

Important: This command should detect all installed Xen hypervisors and kernels, creating proper multiboot entries.

Step 10: Update Initramfs

# Regenerate initramfs for all kernels
dracut --force --regenerate-all

Note: This process can take 10-15 minutes as it rebuilds initramfs for multiple kernel versions.

Step 11: Exit and Reboot

# Exit chroot
exit

# Unmount all filesystems
umount -R /mnt

# Close LUKS container
cryptsetup close luks-root

# Reboot
reboot

What Fixed the Issue

The primary cause of the "No multiboot header found" error was corrupted or missing GRUB configuration entries for Xen. The fix involved:

1. Regenerating GRUB configuration - This recreated proper multiboot2 entries for Xen 4.17.5
2. Updating initramfs - Ensured all kernel modules and drivers were properly included

The successful GRUB regeneration created entries like:

multiboot2 /xen-4.17.5.gz placeholder console=none dom0_mem=min:1024M dom0_mem=max:4G
module2 /vmlinuz-6.6.77-1.qubes.fc37.x86_64

Troubleshooting Notes

• Network connectivity issues during rescue: The dnf reinstall commands may fail due to network problems as I had no network in thew rescue system, but regenerating GRUB config with existing packages is often sufficient.
• GRUB installation failures: If grub2-install fails due to missing EFI modules, focus on the GRUB configuration regeneration, which is the most critical step.
• Multiple disk confusion: Use lsblk and blkid to carefully identify which partition contains your actual root filesystem.

Prevention

• Always create backups before updating dom0
• Consider taking btrfs snapshots before major updates
• Keep rescue media readily available

Result

After following this process, the system should boot successfully to the Qubes login screen, with Xen 4.17.5 loading without multiboot header errors.

This guide was created from a real recovery session and has been tested on a Qubes OS system with LUKS2 + btrfs + EFI configuration.