Isolinux.bin missing or corrupt

After creation of f31 using fedora writer to USB and changing the BIOS boot sequence to make the removable as 1st I got the following error.
isolinux.bin missing or corrupt

Is these something related to PC settings? I have windows10 already installed because on a PC having ubuntu it worked and showed the installation window!

Test this USB with fsck, please. Probably it was corrupted when the stick was removed from the computer.

Stupid question: does your PC support 64 bit operating systems?

Edited. I added the colons in order to identify what is the stupid question.


Link. Are your BIOS has any “USB mode” settings, or such?

Please, see section BUGS in man 1 syslinux.

Why stupid question!

1 Like

Sorry @rtarik for the confusion.
Does your PC support 64 bit operating systems? ← this is the stupid question, and not your question

No problem, yes it does.

I mentioned it worked on ubuntu machine?

What about “now”: This USB works on Ubuntu machine now?

Yes, your're mentioned

But it didn’t worked on this machine. So the links. The devs of syslinux (includes isolinux) rant about hardware-related troubles, and BIOS-related troubles.

Internet didn’t bring any answers to me, but:

  1. try different USB ports

  2. remove most USB devices during boot time,

and the other magic.

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.

Yep. Sometimes the firmware setup UI calls it legacy boot. Others call it, absurdly, “UEFI disabled”

It’s virtually certain UEFI because anything that comes with Windows 10 is UEFI.

An unambiguous way to tell, is the drive GPT or MBR partitioned? Windows on UEFI uses GPT, and BIOS (or UEFI with CSM) uses MBR partitioning.

1 Like

don’t want to test it on ubuntu machine now, it has some problems.

The windows 10 machine has this:

f-31 test live:

Enter MS-7358 here (MEDION service: drivers, updates, and manuals).

Your may wish to contact them as well.  Really, all of this is a “hairy” thing.  I’m personally have no other ideas for now.

1 Like

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.


1 Like

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.
grub rescue>

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:

  1. Why doesn’t the USB stick boot with system in BIOS mode, while it boots fine win UEFI mode?
  2. 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.

I found the solution to my issue.

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.

Thanks for your help, @computersavvy!