You booted your laptop and the GRUB menu only shows Ubuntu. Fedora is gone. Or you are staring at the Anaconda installer, mouse hovering over Custom partitioning, terrified of wiping your existing Arch install.
Dual booting Linux distributions is rarely about the operating systems themselves. It is about the bootloader. The bootloader is the gatekeeper that runs before any kernel loads. If two distributions fight over who controls the gate, one gets locked out. The goal is a shared EFI System Partition and a bootloader configuration that knows about both systems.
What is actually happening
The firmware on your machine hands control to a bootloader stored on the EFI System Partition. On UEFI systems, this is a small FAT32 partition marked with the type EFI. On legacy BIOS systems, the bootloader lives in the Master Boot Record. Fedora uses GRUB2 as its bootloader. Most other distributions also use GRUB2.
When you install a second distribution, its installer usually installs its own copy of GRUB to the same location. The last installer to run wins. The winning GRUB configuration might not know the other distribution exists. If the installer does not detect the other OS, it generates a menu with only itself. The other OS is still on the disk, but the menu entry is missing.
The EFI System Partition acts like a shared mailbox. Both distributions must write their boot files to the same partition. If Fedora writes to one EFI partition and Ubuntu writes to a different one, the firmware only sees the partition you select in the BIOS boot order. The other distribution becomes invisible until you change the boot order manually.
Shared EFI partitions are the standard practice. Separate EFI partitions create maintenance headaches and require BIOS intervention to switch systems.
Verify the EFI partition layout
Before you touch any configuration, confirm how your disks are set up. You need to know which partition holds the EFI files and whether both distributions are using it.
Run this command to list block devices and filesystem labels.
lsblk -f # Show filesystem labels, UUIDs, and types for all block devices
mount | grep efi # Confirm which device is currently mounted as the EFI system partition
Look for a partition with filesystem vfat and type EFI. Note the device name, such as /dev/nvme0n1p1 or /dev/sda1. Check the mount point. Fedora mounts the EFI partition at /boot/efi. If you see another distribution mounted at /boot/efi on a different device, you have separate EFI partitions. You must consolidate to a single EFI partition for a seamless dual boot.
If the EFI partition is missing from the mount output, mount it manually to inspect the contents.
sudo mount /dev/nvme0n1p1 /mnt/efi # Mount the EFI partition to a temporary directory
ls /mnt/efi/EFI # List the EFI directories to see which distributions have installed bootloaders
You should see directories named after each distribution, such as fedora, ubuntu, or arch. If a directory is missing, that distribution did not install its bootloader to this partition.
Unmount the partition when you are done.
sudo umount /mnt/efi # Unmount the EFI partition to return the disk to a clean state
Reboot before you debug. Half the time the symptom is gone.
Install Fedora second for automatic detection
The safest path is to install Fedora after the other distribution. Fedora's Anaconda installer includes robust detection for existing operating systems. It will find the other distribution and add a menu entry automatically.
Boot the Fedora installer. Choose Custom partitioning. Do not choose Automatic partitioning. Automatic mode may create a new EFI partition or format the existing one, which wipes the other distribution's boot files.
In the custom partitioning screen, locate the existing EFI System Partition. It should be labeled EFI and formatted as vfat. Select it and set the mount point to /boot/efi. Do not check the format box. Formatting destroys the data on the partition. Fedora will add its boot files to the existing partition without touching the other distribution's files.
Proceed with the installation. The installer will detect the other operating system and generate a GRUB configuration that includes both. After the installation completes, reboot. The GRUB menu should list Fedora and the other distribution.
If the menu is missing, the installer might have failed to detect the other OS. This happens if the other distribution uses an unusual filesystem or if the EFI partition is not mounted correctly during installation. Check the installer logs or proceed to manual configuration.
Trust the package manager. Manual file edits drift, snapshots stay.
Add Fedora to an existing GRUB configuration
If Fedora is already installed and you install a second distribution afterward, the second distribution's installer will overwrite GRUB. The new GRUB configuration likely does not include Fedora. You need to run the detection tool from the second distribution to add Fedora back.
Most distributions use os-prober to scan for other operating systems. Boot into the second distribution and run the detection command.
sudo os-prober # Scan all mounted filesystems for other operating systems
sudo update-grub # Regenerate the GRUB configuration file based on current detection
The os-prober command reads boot sectors and EFI directories to find kernels or bootloaders. If it finds Fedora, update-grub adds a menu entry. Reboot to verify.
If os-prober returns nothing, it is likely disabled. Ubuntu and Debian disable os-prober by default in recent releases due to security concerns with scanning external drives. You must re-enable it.
Edit the GRUB defaults file. Never edit files in /usr/lib. Those files ship with packages and get overwritten on update. Edit files in /etc.
sudo nano /etc/default/grub # Open the GRUB configuration defaults file for editing
Find the line GRUB_DISABLE_OS_PROBER. Change the value to false. If the line does not exist, add it.
GRUB_DISABLE_OS_PROBER=false # Enable scanning for other operating systems during GRUB update
Save the file and regenerate the configuration.
sudo update-grub # Regenerate the GRUB configuration with os-prober enabled
Reboot. Fedora should appear in the menu.
Run journalctl -xe first. Read the actual error before guessing.
Use a chainloader when detection fails
If os-prober cannot detect Fedora, or if you want to isolate the boot configurations, use a chainloader entry. A chainloader tells the current GRUB to hand control over to Fedora's bootloader. This is reliable and avoids parsing Fedora's kernel paths.
Edit the custom GRUB configuration file on the second distribution.
sudo nano /etc/grub.d/40_custom # Open the custom entries file for manual menu items
Add a menu entry that points to Fedora's EFI binary. Fedora uses shimx64.efi for Secure Boot support. Chainloading to the shim ensures Secure Boot verification works correctly.
menuentry "Fedora Linux" {
insmod part_gpt
insmod fat
insmod chain
# Chainload the Fedora EFI binary from the shared EFI partition
# The path assumes the EFI partition is mounted at /boot/efi in the current OS
chainloader /EFI/fedora/shimx64.efi
}
Save the file and update GRUB.
sudo update-grub # Regenerate the GRUB configuration to include the custom chainloader entry
Reboot. Select Fedora from the menu. The chainloader hands off to Fedora's shim, which loads the kernel and initramfs. You see the Fedora GRUB menu if multiple kernels are installed, or the system boots directly.
Chainloading is the most robust method. It works even if Fedora's kernel paths change or if the other distribution's GRUB cannot parse Fedora's filesystem.
Handle Secure Boot and shim conflicts
Fedora enforces Secure Boot by default. Its bootloader chain is signed and verified. The shim binary, shimx64.efi, is the first stage. It verifies the signature of the next stage, grubx64.efi, which then loads the kernel.
If the second distribution does not support Secure Boot, or if its GRUB is not signed, booting might fail with a security violation error. The firmware blocks unsigned bootloaders.
When you chainload to Fedora's shim, Fedora handles the verification. This is safe. The second distribution's GRUB only loads the shim, which is signed. Fedora's shim then verifies the rest of the chain.
If you try to load Fedora's kernel directly from the second distribution's GRUB, Secure Boot may block it. The kernel must be signed, and the GRUB configuration must use the correct modules. Chainloading avoids this complexity.
If Secure Boot is causing issues, you can disable it in the BIOS. This allows unsigned bootloaders to run. Disabling Secure Boot reduces security. Keep it enabled if possible and use chainloading.
Check the boot logs for Secure Boot denials.
sudo journalctl -t kernel | grep -i secure # Search kernel logs for Secure Boot related messages
If you see SecureBoot violation or Invalid signature, the bootloader chain is broken. Revert to chainloading or disable Secure Boot.
Keep configurations in sync
Kernel updates change the boot process. When you run dnf upgrade on Fedora, the kernel package updates. Fedora's package manager automatically regenerates the GRUB configuration if Fedora is the primary bootloader.
If the second distribution is the primary bootloader, Fedora's update does not touch the second distribution's GRUB. The menu entry for Fedora might point to an old kernel or become stale. You must regenerate the configuration on the second distribution after every Fedora kernel update.
Run the update command on the second distribution.
sudo os-prober # Rescan for changes in Fedora's boot files
sudo update-grub # Regenerate the GRUB configuration to reflect the new kernel
This is a maintenance burden. If you update Fedora frequently, you need to remember to update the other distribution's GRUB. This is one reason to make Fedora the primary bootloader. Fedora's dnf triggers the update automatically.
Use dnf upgrade --refresh for weekly maintenance. It forces metadata refresh and ensures you get the latest packages. Do not confuse this with dnf system-upgrade, which is for crossing major releases.
Common pitfalls and error patterns
Separate EFI partitions are the most common cause of missing boot entries. If Fedora writes to /dev/nvme0n1p1 and Ubuntu writes to /dev/sda1, neither GRUB sees the other. You must consolidate to a single EFI partition. Mount the correct partition during installation and do not format it.
The os-prober disabled error is frequent on Ubuntu 22.04 and later. The command returns silence or an error about being disabled. Check /etc/default/grub for GRUB_DISABLE_OS_PROBER=true. Change it to false.
Manual edits in the wrong directory cause configuration loss. Files in /usr/lib/grub are managed by packages. Edits there disappear on update. Always edit files in /etc.
If you see error: file '/boot/vmlinuz...' not found in the GRUB rescue prompt, the menu entry points to a kernel that no longer exists. This happens after a kernel update if the GRUB configuration was not regenerated. Boot into any working system and run the GRUB update command.
If the boot menu is gone, GRUB rescue is your friend, not your enemy. Use ls to find the EFI partition, set the prefix, and load the normal module.
When to use each approach
Use Fedora as the primary bootloader when you want automatic detection of other OSes via os-prober and do not mind regenerating the config after kernel updates.
Use the other distribution as the primary bootloader when you prefer its GRUB theme or menu behavior and are comfortable manually maintaining os-prober settings.
Use a chainloader entry when the other distribution refuses to detect Fedora or you want to isolate the boot configurations completely.
Use separate EFI partitions when you are testing unstable distributions and want to guarantee Fedora remains bootable regardless of what breaks on the other drive.
Snapshot the system before the upgrade. Future-you will thank you.