Why isn't your Fedora GRUB menu detecting Xen?

When a Fedora update causes your GRUB menu to stop detecting Xen, the issue usually lies in how the kernel and initramfs are built and how GRUB scans for Xen hypervisor files. This explainer covers how GRUB discovers kernels and Xen, why updates can remove or obscure Xen entries, and how to safely restore boot options on both UEFI and BIOS systems. You will understand what GRUB probes, where files must reside, and how to validate configurations so Xen-based guests continue to boot after routine updates.

How GRUB discovers Xen and kernels on UEFI and BIOS systems

GRUB discovers Xen and Linux entries through a combination of file presence, partition scanning, and explicit configuration directives. On UEFI systems, GRUB reads the grub.cfg generated by grub2-mkconfig, which relies on scripts under /etc/grub.d/ and configuration in /etc/default/grub. On BIOS systems, GRUB also scans the boot sector of disks for chain-loading entries. Xen detection depends on:

Xen hypervisor files (e.g., /boot/xen.gz-4.x or /boot/xen.gz) being present in /boot.
An initramfs and kernel for the corresponding Xen kernel variant (e.g., /boot/vmlinuz-... and /boot/initramfs-...) if you are booting a Xen guest kernel directly.
Correct menu entries in /etc/grub.d/ scripts that report valid Xen images to grub2-mkconfig.

When you run a standard dnf upgrade, dnf may install a new kernel that does not include a matching Xen hypervisor or initramfs, or the /boot partition may run low on space, causing older Xen files to be pruned. GRUB then omits the Xen entry because its required files are missing or because the detection scripts no longer report a valid Xen image.

Common causes of missing Xen entries after a Fedora update

Fedora updates can alter the boot environment in ways that remove or obscure Xen entries. Key causes include missing hypervisor files, initramfs build failures, configuration drift, and space pressure on /boot. Understanding each cause helps you choose the correct remediation path.

Missing or pruned Xen hypervisor files

Xen requires a dedicated hypervisor file such as /boot/xen.gz or a versioned variant like /boot/xen.gz-4.18.0-xxx. If an update cleans old kernels but retains a generic kernel only, the corresponding Xen hypervisor files may be removed, or they may never be installed for a newer kernel. Without these files, GRUB cannot create a valid Xen menu entry, even if a Xen-compatible kernel and initramfs exist.

Initramfs not built for Xen kernels

Some Xen workflows use a dom0 kernel that is distinct from the standard Fedora kernel. If the Xen kernel package updates but the initramfs is not rebuilt for that kernel, GRUB may detect a kernel but reject it because the initramfs is missing or mismatched. This often occurs when kernel modules required for Dom0 are not installed or when the initramfs build is skipped due to errors.

GRUB configuration scripts not reporting Xen

The scripts in /etc/grub.d/ drive grub2-mkconfig output. If these scripts are missing, damaged, or incorrectly configured, they may fail to detect valid Xen images. Custom configurations in /etc/default/grub, such as GRUB_DISABLE_RECOVERY or GRUB_DISABLE_SUBMENU, can also hide entries.

/boot space pressures

When /boot runs low on inodes or free space, older kernels and hypervisor files are automatically removed to make room. Xen files are often among the first candidates for cleanup, especially if the package manager considers them optional or associated with an older kernel. A full /boot partition can cause GRUB to skip otherwise valid entries.

Checklist: Quickly verify Xen and GRUB health

Use this concise checklist to determine whether the problem is missing files, configuration issues, or space constraints. Each item is actionable and safe to run on a live system.

Check	Command	What it tells you
Xen hypervisor file present	`ls -la /boot/xen*`	Confirms whether hypervisor images exist for the running kernel.
Initramfs for Xen kernel exists	`ls -la /boot/initramfs-$(uname -r)*`	Shows if an initramfs matches your current kernel.
GRUB can detect Xen entries	`grep -r xen /boot/grub2/grub.cfg` (or `/boot/efi/EFI/*/grub.cfg` on UEFI)	Reveals whether any Xen menuentry blocks are present in the generated config.
/boot has free space and inodes	`df -h /boot` and `df -i /boot`	Identifies space or inode exhaustion that can prune files.
GRUB scripts are present	`ls -la /etc/grub.d/`	Ensures detection scripts exist and are executable.

Step-by-step recovery: Restore a missing Xen entry in Fedora

Follow these steps in order. They are safe for both UEFI and BIOS, but take care to match the firmware mode of the installed system. Always back up custom configs before editing or overwriting grub.cfg.

Step 1: Confirm Xen files exist

Run the following to verify the presence of hypervisor and kernel files:

ls -la /boot/xen*
ls -la /boot/vmlinuz-$(uname -r)* /boot/initramfs-$(uname -r)*

If Xen files are missing but a Xen kernel is installed, you may need to reinstall or install the Xen-specific packages (e.g., xen, kernel-xen, or distro-specific variants).

Step 2: Ensure initramfs is present and valid

Rebuild the initramfs for the running kernel if it is missing or suspect:

For UEFI and BIOS: sudo dnf reinstall kernel$(uname -r) -y
Or explicitly regenerate: sudo dracut --force /boot/initramfs-$(uname -r).img $(uname -r)

This ensures an initramfs is available for Xen-based kernels if one was omitted during the update.

Step 3: Reinstall Xen packages if needed

If the hypervisor package is absent, reinstall it:

sudo dnf install xen xen-libs xen-runtime -y

This places the required xen.gz image back into /boot.

Step 4: Regenerate grub.cfg safely

Back up your current grub.cfg, then regenerate it so detection scripts run anew:

Backup: sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.bak (adjust path for UEFI if needed)
Regenerate: sudo grub2-mkconfig -o /boot/grub2/grub.cfg

After regeneration, inspect the generated file for Xen menuentry lines.

Step 5: Verify and update GRUB default

Ensure /etc/default/grub does not disable recovery or hide entries:

GRUB_DISABLE_RECOVERY=false
GRUB_DISABLE_SUBMENU=false (if you use submenu layouts)

Then update GRUB if changes were made:

UEFI: sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
BIOS: sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Troubleshooting when Xen still does not appear

If regeneration does not produce a Xen entry, consider manual intervention and deeper checks. A missing menuentry usually means the detection script did not recognize a valid Xen image, often due to path mismatch or signature issues.

Manually verify detection conditions

Detection scripts look for a triad:

Valid /boot/xen.gz (or versioned equivalent).
Matching kernel and initramfs in /boot.
No filters in /etc/default/grub or custom scripts suppressing the entry.

You can simulate what grub2-mkconfig does by checking exit codes of the detection scripts in /etc/grub.d/, typically 10_linux and any Xen-specific scripts.

Create a manual menuentry (advanced)

As a last resort, you can add a manual menuentry to /etc/grub.d/40_custom or a dedicated config drop-in in /etc/grub.d/. A minimal example looks like:

menuentry 'Fedora Xen' --class fedora --class gnu-linux --class gnu --class os {
    insmod gzio
    insmod part_gpt
    search --no-floppy --fs-uuid --set=root <boot-uuid>
    echo    'Loading Xen...'
    multiboot /xen.gz dummy-loglvl= guest_loglvl=console
    echo    'Loading kernel...'
    module /vmlinuz-$(uname -r) root=UUID=<root-uuid> ro rhgb quiet
    echo    'Loading initial ramdisk...'
    module /initramfs-$(uname -r).img
}

Replace <boot-uuid> and <root-uuid> with the correct UUIDs from blkid. This bypasses automatic detection and directly defines how GRUB should chainload Xen.

Prevent future missing Xen entries

Use a combination of holds, strict package management, and monitoring to reduce the likelihood that future updates remove Xen files.

Exclude Xen kernel packages from automatic updates if they are intentionally kept: sudo dnf config-manager --set-excluded kernel-xen true.
Keep at least one known-good kernel and its Xen variant in /boot to ensure GRUB always has valid files to detect.
Schedule periodic checks of /boot usage and GRUB config validity, especially before and after major updates.

Conclusion

A Fedora update that removes or obscures Xen entries in GRUB is typically due to missing hypervisor files, absent initramfs for Xen kernels, or configuration issues—not a broken GRUB itself. By verifying file presence, ensuring /boot has space and inodes, and regenerating grub.cfg with the detection scripts in place, you can reliably restore Xen menu entries. Use the checklist and manual steps above for quick diagnosis, and apply the prevention tips to reduce future disruptions.