I was previously on Fedora and I hadn’t paid attention until then that i booted with BIOS legacy. Without waiting i decided with the release of the Fedora 41 to be on full UEFI boot, so must to format to be with GPT partitions. Everything was OK, but now i can’t boot or reboot without my USB key which i used for the Fedora Live, it stucks on boot on the BIOS logo.
I need help to correct this.
On UEFI/BIOS option, everything is correctly detected.
Decided to share my efibootmgr and lsblk as well, if my suggestions below don’t help then you can try comparing your settings to mine to see if you happen to catch any errors in the way you set things up (edit: fixed the issue I had with one of my entries having “RC” on it. There’s three others with RC but they’re not really used so imma leave them be):
For one thing, being on BootCurrent 0000 is perfectly fine if that’s where you installed the OS on. Secondly, while BIOS Legacy can be used for Linux, I’d recommend that you boot with UFEI Mode instead of BIOS Legacy if your PC has that option since UFEI Mode has much better support for modern features. However, if you choose to, or have to boot from BIOS Legacy, the partitioning scheme needs to be on MBR instead of GPT because it’s the only partition table format that older BIOS systems (BIOS Legacy) can understand.
However, double check your BIOS settings as well, check that Secure Boot is off (if you are running an older system, as doing this can help the booting issues), the disk drive that you want to install the OS on (if your system has multiple drives, make sure you didn’t somehow try to partition on to multiple different drives. This isn’t likely at all but considering the crazy errors I’ve managed to pull off on a PC you never know LOL), and I dunno what specifics you have for your system but maybe try turning on virtualization as well if you’re attempting to dual boot or if you’re trying to run a VM.
The filename has “RC” added on the end. We have had reports of this bug before.
You may need to change the Boot0000 Entery to remove the “RC” if Boot000 is needed at all. I do not have such an entry on my system.
What happens if you set Boot0001 to boot your system using efibootmgr?
Thanks for catching that, I didn’t even realize that was an error
When I changed the boot order to start from Boot0001, the RC still exists on Boot0000:
Edit: Now that I’m more awake it occured to me that I asked a stupid question LOL
I’m gonna go through and fix the RC thingy and then update my message with the fixed version of my efi stuff
The “RC” string is not part of the file name. It is just that efibootmgr doesn’t put some kind of a separator between the file name and the “RC” string.
Not correct. The older BIOS doesn’t understand any partition scheme at all. It can only load the contents of the first sector of the selected boot disk and run this code. That is the Master Boot Record (MBR).
Currently, Fedora will create a GPT partition table even if your system is legacy BIOS only.
Also a good link to look at in relation to this topic, if you end up needing to convert your disk
Edit: I should add, even if Fedora creates the GPT partition while you’re setting up the OS, while booted into legacy BIOS, it’s not going to work properly afterwards. You can’t run GPT partition schemes on the legacy BIOS because legacy only supports MBR partition schemes.
I have been running Fedora with GPT partition table on NON-UEFI machines for more than 10 years, so this setup does work. Again, legacy BIOS does not understand any partition able at all. Only the code loaded from the Master Boot record cares about the partition table. Also, remember that classical BIOS was designed to boot from floppy disks which doesn’t have a partition table.
Bear in mind that MS-Windows may have some restrictions, but that is a Microsoft thing.
The way from MBR works is the first part of the 512 bytes block on disc is 8086 code that will load the second stage bootstrap from a location on disk.
At no time is the partition table itself (that is at the end of the 512 byte block) read during early boot. It is only later boot strap stages that begin to care about partition tables.
I was more focused along the lines of the MBR’s partitioning table functionality and not the fact that legacy BIOS doesn’t actually read it lol, oops
But my earlier statement still stands for the most part in terms of making sure you use MBR on legacy BIOS for older systems, GPT can be used on legacy BIOS but you’ll have to do like a couple of extra steps, so unless you wanna fiddle with the extra steps (which probably isn’t too hard), it’s better to either force boot into legacy mode (which might cause some issues since Fedora is typically designed for UFEI) or just use UFEI and GPT for simplicity
No you don’t. Fedora will always install using gpt on classical BIOS systems, unless the disk already contains some partitions. In the latter case, just use whatever partition table is found on the disk. Just try it, and you will see.
But all that has nothing to do with the topic of the thread, and is just confusing for the original poster who asked for help.
My problem still occurs, it’s really annoying. No way to boot on my system without the USB drive.
Secure Boot was not enabled, but i see and can access to the key management ; it was on “user” and reverted to “system”. When i rebooted, Fedora proposed me to update the UEFI Secure boot database key management like this post : Can't update 'Secure Boot dbx Configuration Update'
One laptop I have gets the dbx update seperately from the UEFI firmware update. Another gets the dbx update as part of the UEFI firmware update. In either case the update is done with fwupd and can be performed manually
fwupdmgr refresh --force
fwupdmgr get-updates
and if there are any updates available
fwupdmgr update
To see a bit more about what vendors have made availble for you via lvfs
fwupdmgr get-devices
.
.
When UEFI booting using gpt partitioned storage UEFI will read the ESP and check efivars for what to boot falling back to EFI/BOOT/BOOTX64.EFI as a default among other processes (see the spec).
.
.
Maybe starting simple will be enlightening.
From previous it looks like the install target is /dev/nvme0n1 and that is what you end up booted into though with the install image still plugged in to a usb port. What is the output of
To Be Filled By O.E.M. To Be Filled By O.E.M.
├─Force MP510:
│ Device ID: 71b677ca0f1bc2c5b804fa1d59e52064ce589293
│ Résumé: NVM Express solid state drive
│ Version actuelle: ECFM22.6
│ Fournisseur: Phison Electronics Corporation (NVME:0x1987)
│ Numéro de série: 20378239000128954015
│ GUIDs: a44eb54c-5441-56f2-8cc0-5e48964c6457 ← NVME\VEN_1987&DEV_5012
│ 94e27f4a-86e3-53a2-a728-18db5dd2be18 ← NVME\VEN_1987&DEV_5012&SUBSYS_19875012
│ f3c874f4-11f3-59ca-8b7a-60246752880f ← Force MP510
│ Drapeaux de périphérique:• Périphérique interne
│ • Mise à jour possible
│ • Le système nécessite une source d'alimentation externe
│ • Needs shutdown after installation
│ • Device is usable for the duration of the update
│
├─TPM:
│ Device ID: c6a80ac3a22083423992a3cb15018989f37834d6
│ Résumé: TPM 2.0 Device
│ Version actuelle: 3.87.0.5
│ Fournisseur: Advanced Micro Devices, Inc. (TPM:AMD)
│ GUIDs: 9305de1c-1e12-5665-81c4-37f8e51219b8 ← TPM\VEN_AMD&DEV_0001
│ 78a291ae-b499-5b0f-8f1d-74e1fefd0b1c ← TPM\VEN_AMD&MOD_AMD
│ 65a3fced-b423-563f-8098-bf5c329fc063 ← TPM\VEN_AMD&DEV_0001&VER_2.0
│ 5e704f0d-83cb-5364-8384-f46d725a23b8 ← TPM\VEN_AMD&MOD_AMD&VER_2.0
│ Drapeaux de périphérique:• Périphérique interne
│ • Le système nécessite une source d'alimentation externe
│ • Needs a reboot after installation
│ • Device can recover flash failures
│ • Full disk encryption secrets may be invalidated when updating
│ • Signed Payload
│
├─UEFI dbx:
│ Device ID: 362301da643102b9f38477387e2193e57abaa590
│ Résumé: UEFI revocation database
│ Version actuelle: 371
│ Version minimum: 371
│ Fournisseur: UEFI:Linux Foundation
│ Durée d'installation:1 seconde
│ GUID: f8ba2887-9411-5c36-9cee-88995bb39731 ← UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503&ARCH_X64
│ Drapeaux de périphérique:• Périphérique interne
│ • Mise à jour possible
│ • Supported on remote server
│ • Needs a reboot after installation
│ • Device is usable for the duration of the update
│ • Only version upgrades are allowed
│ • Signed Payload
$ sudo fdisk -x /dev/nvme0n1
Disk /dev/nvme0n1: 1,75 TiB, 1920383410176 bytes, 3750748848 sectors
Disk model: Force MP510
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: 126E68DA-078B-4A92-BDEF-B2F424CCEE9F
First usable LBA: 34
Last usable LBA: 3750748814
Alternative LBA: 3750748847
Partition entries starting LBA: 2
Allocated partition entries: 128
Partition entries ending LBA: 33
Device Start End Sectors Type-UUID UUID Name Attrs
/dev/nvme0n1p1 2048 1230847 1228800 C12A7328-F81F-11D2-BA4B-00A0C93EC93B EDF09319-4808-43A1-BB1C-390D8B7E2F76 EFI System Partition
/dev/nvme0n1p2 1230848 3327999 2097152 BC13C2FF-59E6-4262-A352-B275FD6F7172 23604327-A7F2-49A6-883C-DC10316A7688
/dev/nvme0n1p3 3328000 3750748159 3747420160 0FC63DAF-8483-4772-8E79-3D69D8477DE4 B46DCF27-A858-4483-9FDF-E1A8F48687A2