How can I relabel Fedora storage on BIOS?

Hi everybody,

On my BIOS storage configuration, the SSD where F35 is installed appears as ‘Fedora’. I installed a second SDD where I already had a F35 installation, and now I have two ‘Fedora’ entries on the BIOS.

Anyone knows where the BIOS is getting this from? I would like to relabel them to properly refer to each SSD.

1 Like

The name that is assigned when creating the partition of the storage, in this case the BTRFS subvolume name.

Thanks @jakfrost , I thought so, but the subvolume is labeled ‘fedora’ (lower case initial), that’s why I thought there could be something else going on.

… unless the BIOS is capitalizing the first letter of all volumes :thinking:

If you means name on boot list, you could create a new one with efibootmgr here. Please read carefully.

Then if the new created label are successfully booting, you could delete the old one. For example if by running efibootmgr the boot number is Boot0001 then delete it with sudo efibootmgr -B -b 1.

Thks @oprizal , that seems to be pretty much what I need! Indeed, efibootmgr shows not only 2, but actually 3 ‘Fedora’ entries:

[root@fedora ~]# efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0001,0000,2001,2002,2003
Boot0000* Fedora	HD(1,GPT,d6dd2795-a43f-458d-bfce-1a36db2e7f8d,0x800,0x12c000)/File(\EFI\fedora\shimx64.efi)
Boot0001* Fedora	HD(1,GPT,77b905d0-b528-4176-b27b-1c5a1bdbd08a,0x800,0x12c000)/File(\EFI\fedora\shim.efi)RC
Boot0003* Fedora	HD(1,GPT,d6dd2795-a43f-458d-bfce-1a36db2e7f8d,0x800,0x12c000)/File(\EFI\fedora\shim.efi)RC
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

And here’s the output of lsblk -f:

[root@fedora ~]# lsblk -f
NAME        FSTYPE FSVER LABEL         UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                        
├─sda1      vfat   FAT32               1455-734B                                           
├─sda2      xfs                        3e898c18-8afb-4c0d-9a50-889b56cb19d2                
└─sda3      btrfs        fedora_fedora e775123e-e2d9-4e17-a78a-e59c7c527949  167.9G    27% /mnt/ssd
zram0                                                                                      [SWAP]
nvme0n1                                                                                    
├─nvme0n1p1 vfat   FAT32 boot_efi      1280-CAEA                               585M     2% /boot/efi
├─nvme0n1p2 ext4   1.0   boot          9927be2a-07be-4c95-86b5-8819ae4751f5    617M    30% /boot
└─nvme0n1p3 btrfs        fedora        40d2311c-5ca9-4a6e-a0ad-86f341521078    449G     5% /home
                                                                                           /

I will study a little further before actually playing with efibootmgr so that I don’t mess things up :sweat_smile:

Is it possible to just rename one of the entries, or do I need to create a new entry and then remove the original entry once I am sure system is booting just fine?

sda3 is my old F35 installation on the ssd, I don’t need to boot from it any more.

In the past I also want it too, but from efibootmgr -h look like there is no way to do so. As far as I know, only create and delete. There also activate and deactivate but it only to show or hide the list from bios boot list (active have sign * when we run efibootmgr).

Thanks, create and delete will do, no big deal. Actually, I guess I’ll first just deactivate the unused device and see if it is an acceptable solution.

Just one last question: why are there 2 different entries (Boot0000 and Boot0003) referring to the same device but with different efi files ( shimx64.efi and shim.efi)? Shouldn’t the shimx64.efi be the first one?

I did some testing:

  • If I change boot order to 0000,0003,0001,2001,2002,2003 system boots just fine, but the order is reverted back to 0003,0001,0000,2001,2002,2003 on the next boot. Is there any additional step that I should do?
  • Deactivating Boot0001 doesn’t remove it from BIOS boot options (maybe I misunderstood this)

:thinking:

The BIOS boot options are mainly read from the EFI partition.

1 Like

I’m not sure about shimXXX.efi, but it related with secure boot for certain system. But ussually for modern PC usually it should be shimx64.efi.

I’m not sure what was happen. But from:

you could see that Boot0000 and Boot0003 are located on same device base on ID d6dd2795-a43f-458d-bfce-1a36db2e7f8d and Boot0001 from the other one 77b905d0-b528-4176-b27b-1c5a1bdbd08a.

Usually to find which one which, I comparing the order from the bios and from efibootmgr. For example to make it easy: 0000,2003,0001,2002,0003, ..... With this sequences it should be more easy to recognize.

Btw it also possible that we have/create two boot list Label on bios but it pointing to the same installed system. In the past, I have label with name Fedora and Workstation that pointing to the same installed Fedora linux.

You could also run efibootmgr from live usb in case something wrong happen.

@oprizal you are right, now both entries on BIOS point to the same device – one to the shimx64.efi and the other to shim.efi.

I managed to create a new entry ‘Fedora35’ pointing to the same device+partition+efi file as Boot0001, running:

efibootmgr -c -d /dev/nvme0n1 -L Fedora35 -l \\EFI\\fedora\\shimx64.efi -p 1

but here is the tricky part: I can select it if I press F12 during boot when Acer logo appears. However, I cannot enter BIOS setup anymore (pressing F2 during boot), it freezes on the Acer logo. This seems to be an issue with Acer BIOS, and the solution apparently involves deleting shimx64.efi file, but AFAICS it would render the system unbootable, wouldn’t it? BTW I have SecureBoot and FastBoot disabled, as this other post suggests. Removing the newly created Fedora35 entry allows me to access BIOS setup again.

Any idea about what’s going on (besides some Acer weirdness)?

Most likely your bios only able to run with shim.efi (or maybe also shimia32.efi) and that is ok. As far as I know, some devices even it 64bit, the bios still use 32bit secure boot encryption.

You could check available efi files under /boot/efi/EFI/fedora/ directory.

1 Like

Nice, I knew there had to be a simple, logical explanation :wink: shim.efi it is, then

However, there is still something weird going on:

  1. If I remove the entry related to the SSD (sda), it is automatically recreated on the next boot, and always as one of the bootable options :thinking: I can, however, set is as inactive
  2. I can create new entries with arbitrary labels, but on the next reboot they are always relabeled to Fedora, so there is something else going on that I am not covering here :thinking: :thinking:

Right now my configuration is:

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0003,2001,2002,2003
Boot0000* Fedora	HD(1,GPT,d6dd2795-a43f-458d-bfce-1a36db2e7f8d,0x800,0x12c000)/File(\EFI\fedora\shim.efi)
Boot0003  Fedora	HD(1,GPT,77b905d0-b528-4176-b27b-1c5a1bdbd08a,0x800,0x12c000)/File(\EFI\fedora\shim.efi)
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

I’m not sure about that. But with my laptop if something going wrong, I can reset the boot list then the bios automatically read all efi partition and create new boot list.

Not only that, if I connect my external drive via USB, where it have efi partition (I have Fedora installed in my external drive), my bios automatically create the boot list for it. The only one case the boot list not recreated (at least for me) is when the system only have one efi partition.

Thanks @oprizal , I guess I’ll look for more specific answers on Acer forums. I really appreciate your help, and it was great to learn about efibootmgr, another tool for the tool set :wink:

BTW when I plug a bootable USB it also appears on the BIOS boot options.

Likely the immutable file system. I think the boot entries are created at the time you create the local commit image (the remote commit image + your layering config). And they are likely symlinked to shim.efi from /usr/lib/shim.efi or something similar during the post processing before reboot is requested. Just an off the top of my head thought on it.