What boot mode are you using?
If windows is MBR boot and fedora is UEFI boot they cannot both be managed from grub.
Similarly if the roles are switched.
Both OSes must be installed in the same mode for grub to function for both.
You can see if you installed fedora in uefi mode by running cat /sys/firmware/efi/efivars. If it tells you that is a directory then you installed in uefi mode.
Fedora Silverblue does not provide a fully functional experience for dual booting or manual partitioning.
It is possible to make Fedora Silverblue work for both dual boot and manual partitioning, and some guidance is provided on manual partitioning below. However, there are hazards involved in both cases, and you should only attempt to use these features if you have done the necessary research, and are confident that you can overcome any issues that you might encounter.
If your uefi implementation have a decent boot menu, you could use that to select the os you want to boot. That would be easier than trying to configure grub to do dual boot, as this won’t happen automatically in Silverblue.
I played around with the BIOS UEFI settings but only the fedora one works.
Not sure how or if I can get the Windows 10 working again. That would be a bummer as I have a lot of Windows only radio scanning and ham radio programs on that drive.
You may need to do a windows repair.
There may be possibility of additional suggestions of we were to see the full output of lsblk -f
Those 2 lines out of context are mostly meaningless (other than to confirm fedora is booting uefi mode).
Update: tried lots of different things and it looks like I broke it real good.
I have a Windows recovery USB and a full backup but so far no luck. All the advanced cmd I have tried just end in path not found. I took pictures and can provide them if it might help. I also did a re-install of Debian 12 to see if the read only files system of Silverblue was causing the issue.
Here is the full output of the lsblk -f command on the working Debian system:
I believe this indicates that you may have been booting windows in MBR mode. There is no efi partition on sda with a vfat format as is normal for most (or all) uefi boot partitions.
In fact the sda drive is dos formatted which windows requires for legacy boot systems.
As I understand it windows 7 and earlier only booted in legacy mode using a dos formatted drive.
Windows 8 & 10 could boot either legacy or uefi but required the drive be dos formatted for legacy boot and gpt formatted for uefi boot.
Windows 11 requires gpt formatted drives and can only boot in uefi mode.
In order to boot linux you probably need to use the bios setup to select fedora for booting.
You also probably need to reinstall windows in uefi mode if you intend to dual boot using grub.
The partition type of sdb2 is “Linux Extended Boot” which indicates a Fedora system being booted in classic BIOS mode.
The Silverblue version creates a grub.cfg totally different from the one created by the Workstation edition, and there is no automatic mechanism to set up for grub dualbooting at all. Somehow a file snippet needs to be created in the right place for this. Someone else my be able to figure out the details about that.
As WIndows and Fedora are installed on separate disks, it should be possible to use the BIOS boot menu to select which disk unit to boot from.
I am not familiar with the differences in grub for booting SB vs the non-atomic versions, but that fdisk output clearly shows an ESP partition on the drive. The partition sizes seem exactly as I would expect for a clean fedora installation in uefi mode.
This is what I see on a newly installed drive with f41 workstation in uefi boot mode. Partitions sda2 is ext4 mounted at /boot
# fdisk -l
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WDC WDS500G2B0A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CD8FF451-FF61-415F-A701-DFC55A21E92C
Device Start End Sectors Size Type
/dev/sda1 2048 1230847 1228800 600M EFI System
/dev/sda2 1230848 3327999 2097152 1G Linux extended boot
/dev/sda3 3328000 976773119 973445120 464.2G Linux filesystem
Thanks for the replies, my best guess at this point is the Win10 system was using a MBR legacy booting from sda1. When I installed Silverblue using the default automatic disk configuration on sdb I believe it installed the UEFI booting. Best I can tell is it boots into fedora using UEFI. I can enter the BIOS setup using the ESC key and fedora is listed under UEFI. It’s the only entry under UEFI unless I boot with the install USB. In that case I can select it and boot from the USB so I’m thinking if I can get Windows 10 re-installed using UEFI I should be able to select it too. I want to redo drive sda anyway but I hope I can run the backup over the fresh install and save the programs I had installed.
My error. I should have looked at “EFI SYstem”.
Anyway. Running efibootmgr will tell you without a doubt if you are booting in UEFI mode or not.
Here are a grub.cfg from a fresh Silverblue installation
# This file is copied from https://github.com/coreos/coreos-assembler/blob/main/src/grub.cfg
# Changes:
# - Dropped Ignition glue, that can be injected into platform.cfg
# petitboot doesn't support -e and doesn't support an empty path part
if [ -d (md/md-boot)/grub2 ]; then
# fcct currently creates /boot RAID with superblock 1.0, which allows
# component partitions to be read directly as filesystems. This is
# necessary because transposefs doesn't yet rerun grub2-install on BIOS,
# so GRUB still expects /boot to be a partition on the first disk.
#
# There are two consequences:
# 1. On BIOS and UEFI, the search command might pick an individual RAID
# component, but we want it to use the full RAID in case there are bad
# sectors etc. The undocumented --hint option is supposed to support
# this sort of override, but it doesn't seem to work, so we set $boot
# directly.
# 2. On BIOS, the "normal" module has already been loaded from an
# individual RAID component, and $prefix still points there. We want
# future module loads to come from the RAID, so we reset $prefix.
# (On UEFI, the stub grub.cfg has already set $prefix properly.)
set boot=md/md-boot
set prefix=($boot)/grub2
else
if [ -f ${config_directory}/bootuuid.cfg ]; then
source ${config_directory}/bootuuid.cfg
fi
if [ -n "${BOOT_UUID}" ]; then
search --fs-uuid "${BOOT_UUID}" --set boot --no-floppy
else
search --label boot --set boot --no-floppy
fi
fi
set root=$boot
if [ -f ${config_directory}/grubenv ]; then
load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
load_env
fi
if [ -f $prefix/console.cfg ]; then
# Source in any GRUB console settings if provided by the user/platform
source $prefix/console.cfg
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
# Other package code will be injected from here
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=1
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=1
fi
# Import user defined configuration
# tracker: https://github.com/coreos/fedora-coreos-tracker/issues/805
if [ -f $prefix/user.cfg ]; then
source $prefix/user.cfg
fi
blscfg
The user can create a file $prefix/user.cfg where $prefix is /boot/grub and in that file put whatever is required to boot the other system.
Thanks, I will run the efibootmgr command later if I can get the current issue sorted out. The computer is refusing to boot from the Win10 install USB I made last night. Might just be an incompatible USB device. I’m trying to make another on a PNY USB that I know works as I had tested it with a different .iso
All my efforts at making a bootable Win10 USB install failed. Looks like a Windows computer is required to make the bootable .iso install USB. So I’m stuck and can not fix the Windows not booting issues.
fedora is booting fine however: here is the output of the efibootmgr command.
Name : WoeUSB
Epoch : 0
Version : 5.2.4
Release : 8.fc41
Architecture : x86_64
Download size : 35.6 KiB
Installed size : 109.8 KiB
Source : WoeUSB-5.2.4-8.fc41.src.rpm
Repository : fedora
Summary : Windows USB installation media creator
URL : https://github.com/WoeUSB/WoeUSB
License : GPLv3+
Description : A utility that enables you to create your own bootable Windows installation
: USB storage device from an existing Windows Installation disc or disk image.
Vendor : Fedora Project
That was an awesome link! I tried making the USB using dd and the windows .iso and now know why it did not work.
Only problem now is I have two Linux computers available: Debian and fedora silverblue. Don’t think there are packages available for either. There is a long dependency list to try and run it direct so I need to see if any other options are available.