Fedora installation x86_64 ISOs use GRUB as the bootloader on computers with UEFI firmware, and isolinux (variant of syslinux) on computeres with BIOS firmware. My suggestion is to confirm whether the computer really is UEFI or BIOS; in particular you need to discover if you have a UEFI installation of Windows 10 or if it’s a BIOS installation of Windows 10.
Make certain Fedora is installed using the same firmware mode as the Windows 10 installation. This is committed at Fedora installation time, just like the Windows installer. That is, if you boot the installer in BIOS mode, you get a BIOS installation. If you boot the installer in UEFI mode, you get a UEFI installation.
If you determine that you should do a BIOS mode installation, I suggest trusting that the error may be correct, and just recreate the USB install media, possibly using alternate USB media.
Have not seen any updates for 3 days, but I wonder if his bios is set to compatibility mode (sometimes referred to as CSM mode).
On some systems compatibility mode will boot for a new install in BIOS mode even if the windows OS is already installed and booting in UEFI mode.
I have solved that problem by setting the bios to use only UEFI, then the install will match the current configuration.
You can try the 3 option indicated here: related with “Emulation Type” I think it can be your problem in the case you did verified the media. Check the link.
If you did solve the issue and if you after wish install fedora, look up for your windows install like @chrismurphy well pointed you. Your screen captures show that W10 is installed in Legacy/Bios mode so that you don’t should install in UEFI mode because you will can not boot in windows after.
I have a similar issue after installing F33 from a USB stick made with Fedora Media Writer (Fedora Server image downloaded on the fly). Installation was onto a server that up until now was in BIOS mode: flipped it to UEFI in HW setup, booted off USB, installed using default mount points (with /boot and /boot/efi in separate partitions), rebooted … and got:
No boot device available.
Current boot mode is set to UEFI.
Please ensure compatible bootable media is available.
Use the system setup program to change the boot mode as needed.
Strike F1 to retry boot, F2 for system setup, F11 for UEFI boot manager
Using the USB stick in rescue mode I realized the partition table remained in MBR format (not sure how that happened, since I used default partitioning as suggested by anaconda & didn’t see any warnings or errors); since the installation was quick and I didn’t have the appetite to mess with converting partition tables, I thought I’ll reinstall everything again in BIOS mode. Except after flipping the system back to BIOS, it won’t boot, whether from the disk (containing the UEFI-installed F33 and an MBR) or from the USB stick, giving in either case:
isolinux.bin missing or corrupt.
error: unknown filesystem.
and dropping to grub rescue. /boot has xfs and /boot/efi has fat32 & boot flag on its partition.
What I am grappling with, is how can what’s happening on the disk affect the USB stick? Admittedly, I never tried to boot off of that USB stick in BIOS mode, but according to the installation documentation
There are no separate media provided for BIOS and UEFI systems; all of them can boot from the same ISO image.
I assumed that if it boots fine in UEFI it should boot fine in BIOS.
Any suggestions? Did the author of the original post ever figure out what it was?
It seems you may have not selected the one important option when doing that install in auto mode while switching boot format. Did you select “use entire disk” for the install? If you did then it would have repartitioned the disk as gpt and created a protected MBR where the bios mbr resides (at least on the workstation release it does).
Indeed, I did not select “use entire disk”, because I wanted to preserve 2 partitions that came with the machine, holding diags & other goodies. This explains that.
(Before installation the system was running F20 and had /boot in partiton 3 & an LVM volume in partition 4, and anaconda had some issues with repartitioning, even using the “Advanced Custom (Blivet GUI)” method; I had to run parted from command line to remove 3 & 4, go back to the installer & use “Custom” for “Storage Configuration”, then “Click here to create them automatically link” under “New Fedora 33 Installation”; it seemed to very nicely use up the space, with a primary partition 3 containing /boot/efi and an extended partition 4 containing partition 5 for /boot and partition 6 for an LVM volume.)
Remaining questions are:
Why doesn’t the USB stick boot with system in BIOS mode, while it boots fine win UEFI mode?
What should be my next step:
a. debug the USB stick, or
b. try & convert the partition table to GPT, or
c. something entirely different?
I think the answer to 1 is that since the drive contains an esp partition the USB expects to boot in uefi mode, but having the bios set otherwise prevents that.
However, I must ask:
When trying to boot the USB, how are you accessing it? Are you using the boot menu from within bios? Are you using the bios boot menu (usually accessed by using F10 or F11 during boot)? Or do you have the bios set to boot directly from USB?
I find that on my machines, both the one that I newly built and the one that is about 4 years old, that the boot menu (either by the key during boot or within bios) will show the USB device at least twice. Once is the bare device which will boot it into bios mode, second has an indication of uefi overlaid on the device image and will boot it into uefi mode. Whichever mode I boot into is the one used for the install.
My answer to #2 would be to suggest that you backup the data on those partitions you tried to save then do a reinstall in uefi mode, partitioning it as you choose to keep that data you backed up. While doing so use the whole disk so it properly converts to gpt and the uefi boot should work for you.
It was rather simple (as it’s often the case with “weird” problems): it turns out my machine’s (Dell T110) System Setup has an option USB Flash Drive Emulation Type with possible values Auto, Floppy, and Hard Drive; the option is only available in BIOS mode, switching back from UEFI must have reset it; changed it from Auto to Hard Drive and voilà, the machine booted from the USB stick like a charm.
There is a giveaway in the BIOS Boot Menu (F11): in Hard Drive mode the USB stick is listed in a submenu, together with the other disks; in Auto it is listed below. I don’t use alternate boot sources often enough to have noticed that, but once I found the issue it was another obvious, 20/20 in hindsight, sign…
These partitions are used from within the firmware & I wasn’t sure they would have worked if I recreated them using GPT. I ended up blowing all the partitions created the first time, using Blivet GUI to repartition, and I’m back in business in BIOS mode.