efibootmgr label rename

geohei · 2013-01-08 09:29:22

Hi.

Dual boot test (!) for Windows 7 and Ubuntu on UEFI system with GPT HDD.
I'm planning installing Arch Linux later on same HDD. But first I need this to be working!

Using efibootmgr, I found this:

root@xxx:/home/geohei# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0006,0007
Boot0000* ubuntu
Boot0001* Windows Boot Manager
Boot0006* Hard Drive 
Boot0007* CD/DVD Drive

There are 2 entries from my installation in this list.

"ubuntu" - This one resides inside the NVRAM of UEFI. When I delete the HDD containing Windows 7 / Ubuntu completely (no partitions anymore), this entry still remains in the UEFI Boot Manager.

"Windows Boot manager" - This entry seems (?) to be read from the /boot/efi/EFI when the computer starts. When I delete the HDD, this entry is gone. Can you confirm this assumption? If yes, which file in /boot/efi/EFI is responsible for this UEFI Boot Manager entry?

Next ... I tried to change the name of "ubuntu" into "Ubuntu 12.10". This was more an exercise than anything else in order to get used to efibootmgr.

root@xxx:/home/geohei# efibootmgr -b 0000 -L "Ubuntu 12.10"
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0006,0007
Boot0000* ubuntu
Boot0001* Windows Boot Manager
Boot0006* Hard Drive 
Boot0007* CD/DVD Drive

Why is this not working?

Next ... what is the difference between efibootmgr and the EFI Shell, except that one is executed from Ubuntu and the other one on EFI level? When do I use the former one, when the latter?

Thanks,

Last edited by geohei (2013-01-08 09:39:39)

Corubba · 2013-01-08 23:14:43

Afaik the -L option only works when creating new entries (-c). The easiest way to achieve your goal is to uefi-boot the Ubuntu 12.10 and run something like

efibootmgr -b 0000 -B
efibootmgr -c -L "Ubuntu 12.10"

This deletes and recreates the entry. If nothing further given, -c results in the same parameters the system was booted with.

Last edited by Corubba (2013-01-08 23:16:41)

cfr · 2013-01-09 00:04:17

As far as I know, no files in the EFI partition produce entries in the boot menu simply by existing.

On my machine, some boot entries seem to be permanent. If I reset the BIOS to defaults, those entries remain. Indeed, they remain even though they are mostly useless because the things to which they refer were wiped from my hard drive as soon as I got the machine.

Other entries are entries I add and can delete etc. I can make the permanent entries inactive but I cannot delete them. (I haven't tried altering them but I doubt that would work.) Only the custom ones I've added do I have complete control over.

efibootmgr is a specific tool for creating and managing EFI boot entries from Linux. The EFI shell is an EFI application which runs/creates that environment. It has nothing to do with Linux. (I mean, technically it is a completely independent thing and doesn't depend on any OS.)

"ubuntu" - This one resides inside the NVRAM of UEFI. When I delete the HDD containing Windows 7 / Ubuntu completely (no partitions anymore), this entry still remains in the UEFI Boot Manager.

Yes. And if you wipe this then it will be gone no matter what partitions you have.

"Windows Boot manager" - This entry seems (?) to be read from the /boot/efi/EFI when the computer starts. When I delete the HDD, this entry is gone. Can you confirm this assumption? If yes, which file in /boot/efi/EFI is responsible for this UEFI Boot Manager entry?

I don't know how anybody can confirm that that is what happens on your machine. However, for whatever it is worth, I do not have an entry with this label in my list. Whether I had one when Windows was installed I cannot say as that only lasted for the briefest possible amount of time.

But I suspect this depends on the machine and EFI firmware. Perhaps it is possible for entries to be automatically hidden if they refer to nothing. Or auto-generated. No idea.

For comparison:

# efibootmgr 
BootCurrent: 000B
Timeout: 0 seconds
BootOrder: 000B,000A,0007,0008,0005,0006,0009
Boot0000  Setup
Boot0001  Boot Menu
Boot0002  Diagnostic Splash
Boot0003  Rescue and Recovery
Boot0004  Startup Interrupt Menu
Boot0005* USB CD:
Boot0006* USB FDD
Boot0007* ATA HDD0:
Boot0008* USB HDD
Boot0009  PCI LAN
Boot000A* Arch GRUB2
Boot000B* Arch rEFInd

Note that PCI LAN is disabled - it is a permanent entry but I've rendered it inactive. Rescue and Recovery probably refers to nothing although I've never actually tried it. But I formatted the hard drive so I imagine whatever it is is gone. (I hope...) I'm not sure what the Startup Interrupt Menu is. Setup is presumably BIOS setup. Boot Menu is the boot menu. Diagnostic Splash is the diagnostic splash which isn't very diagnostic.

Er... I think.

Last edited by cfr (2013-01-09 00:13:42)

geohei · 2013-01-09 05:22:38

Corubba wrote:

Afaik the -L option only works when creating new entries (-c). The easiest way to achieve your goal is to uefi-boot the Ubuntu 12.10 and run something like
efibootmgr -b 0000 -B
efibootmgr -c -L "Ubuntu 12.10"
This deletes and recreates the entry. If nothing further given, -c results in the same parameters the system was booted with.

Yes, almost right.

Before modification.

root@xxx:/home/geohei# efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,0003,0004
...
Boot0001* ubuntu	HD(1,800,32000,7527da8d-9644-4689-99aa-79af21bed707)File(\EFI\ubuntu\grubx64.efi)
...

Modification.

root@xxx:/home/geohei# efibootmgr -b 0001 -B
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0000,0003,0004
Boot0000* Windows Boot Manager
Boot0003* Hard Drive 
Boot0004* CD/DVD Drive
root@xxx:~# efibootmgr -c -L "Ubuntu 12.10"
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0001,0000,0003,0004
Boot0000* Windows Boot Manager
Boot0003* Hard Drive
Boot0004* CD/DVD Drive
Boot0001* Ubuntu 12.10
root@xxx:/home/geohei# efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,0003,0004
...
Boot0001* Ubuntu 12.10	HD(1,800,32000,7527da8d-9644-4689-99aa-79af21bed707)File(\elilo.efi)
...

Strange ... the system booted like that, but with elilo.efi. This file doesn't exist in /boot/efi. Very weird. Seems to be generic bypassing grub.

This created the initial entry:

root@xxx:/home/geohei# efibootmgr -c -L "Ubuntu 12.10 test" -l "\EFI\ubuntu\grubx64.efi"
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0002,0001,0000,0003,0004
Boot0000* Windows Boot Manager
Boot0001* Ubuntu 12.10
Boot0003* Hard Drive 
Boot0004* CD/DVD Drive 
Boot0002* Ubuntu 12.10 test
root@xxx:/home/geohei# efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0002,0001,0000,0003,0004
Boot0001* Ubuntu 12.10	HD(1,800,32000,7527da8d-9644-4689-99aa-79af21bed707)File(\elilo.efi)
Boot0002* Ubuntu 12.10 test	HD(1,800,32000,7527da8d-9644-4689-99aa-79af21bed707)File(\EFI\ubuntu\grubx64.efi)
...

Both entries started Ubuntu.

cfr wrote:

As far as I know, no files in the EFI partition produce entries in the boot menu simply by existing.

Test:
1. I install Windows 7 and I get an UEFI entry "Windows Boot Manager".
2. I reflash UEFI, all entries are gone.
3. I restart Windows using generic UEFI HDD entry (UEFI: WDC WD1000FYPS-02ZKB1).
4. I reboot Windows 7 and the generic UEFI HDD entry is gone, but "Windows Boot Manager" reappeared.

It looks to me that starting Windows 7 wrote stuff in UEFI (see below).

cfr wrote:

On my machine, some boot entries seem to be permanent. If I reset the BIOS to defaults, those entries remain. Indeed, they remain even though they are mostly useless because the things to which they refer were wiped from my hard drive as soon as I got the machine.

What do you mean by "reset the BIOS"? CMOS_SW button push (load optimized defaults) or BIOS reflash? The first doesn't change anything to my UEFI Boot Manager, while the second resets everything to 0 until ... the UEFI HDD entry is chosen. Then "Windows Boot Manager" appears again (but both Ubuntu entries are gone!). I guess (?) this is due to the /boot/efi/EFI/Boot directory, which seems to be the default UEFI start if UEFI HDD is chosen from the UEFI Boot Manager.

cfr wrote:

Other entries are entries I add and can delete etc. I can make the permanent entries inactive but I cannot delete them. (I haven't tried altering them but I doubt that would work.) Only the custom ones I've added do I have complete control over.

I tested this. I can delete every of my 4 entries (see above)! However I believe this is highly UEFI motherboard manufacturer related.

cfr wrote:

efibootmgr is a specific tool for creating and managing EFI boot entries from Linux. The EFI shell is an EFI application which runs/creates that environment. It has nothing to do with Linux. (I mean, technically it is a completely independent thing and doesn't depend on any OS.)

But EFI shell is able to perform more or less the same operations, right?
Is it included in UEFI or does it reside on EFI partition as file (e.g. /boot/efi/EFI/shellx64.efi)?

Many thanks for the answers!
Very useful!

Last edited by geohei (2013-01-10 12:55:06)

srs5694 · 2013-01-09 06:05:03

geohei wrote:

Strange ... the system booted like that, but with elilo.efi. This file doesn't exist in /boot/efi. Very weird. Seems to be generic bypassing grub.

If you don't specify a boot loader filename for efibootmgr, it assumes \elilo.efi. Thus, it will add such an entry if you don't override it with -l.

Note that the NVRAM entries that efibootmgr maintains are a sequence to be tried; if the first entry is invalid or terminates, the firmware tries the second. If the second fails, the firmware tries the third. Thus, creating an invalid entry -- as for elilo.efi if it doesn't exist -- has no practical effect on the boot process, since the firmware just skips it and goes on to the next entry.

cfr wrote:
As far as I know, no files in the EFI partition produce entries in the boot menu simply by existing.
Test:
1. I install Windows 7 and I get an UEFI entry "Windows Boot Manager".
2. I reflash UEFI, all entries are gone.
3. I restart Windows using generic UEFI HDD entry (UEFI: WDC WD1000FYPS-02ZKB1).
4. I reboot Windows 7 and the generic UEFI HDD entry is gone, but "Windows Boot Manager" reappeared.
It looks to me that staring Windows 7 wrote stuff in UEFI (see below).

There are two possibilities:

Windows may have noticed that its entry was missing from the firmware when it booted, and it wrote a new entry for itself.
The firmware may be hard-coded to look for the Windows boot loader and create an entry for it if it doesn't exist.

I know for a fact that some -- but not all -- EFI implementations do the latter. Specifically, I've seen my Gigabyte motherboard with a Hybrid EFI do this on a computer that's never had Windows installed on it. It's been a while since I did most of my experiments with it, but as I recall, the board would tend to either forget its NVRAM entries entirely or replace valid entries for Linux boot loaders with invalid entries for the Windows boot loader. It was absolutely maddening when I was dealing with it. In the end, I just stopped trying; I found that the computer boots most reliably with my desired boot loader installed on the ESP as EFI/BOOT/bootx64.efi. This is the fallback filename, so I just don't have any NVRAM entries.

I'm not sure if Windows does the former, or if it does, under what circumstances. Certainly I've seen complaints about Windows restoring its boot loader to be the default one in some forum posts, but I'm not 100% sure of what's causing that problem -- it's conceivable that it's actually the firmware doing the mischief, not Windows.

But EFI shell is able to perform more or less the same operations, right?

The version 2 EFI shell has a command called "bcfg" that can be used for more-or-less the same things as "efibootmgr." This command is missing from the version 1 EFI shell, though. In some cases bcfg seems to be more reliable. It works under VirtualBox, for instance, whereas efibootmgr entries are forgotten on reboot with VirtualBox.

Is it included in UEFI or does it reside on EFI partition as file (e.g. /boot/efi/EFI/shellx64.efi)?

An EFI shell is built into some EFI implementations -- at least the one included with VirtualBox, and IIRC the one in DUET. I have yet to encounter an EFI shell built into shipping hardware, though. For most actual EFI-based computers, you've got to drop the shell onto the hard disk. Some implementations give you an option to launch it if it's stored in the root directory, or perhaps in other locations, but some don't seem to give you any way to launch a shell except by treating it like an OS boot loader.

I'm starting to think that installing an EFI shell as EFI/BOOT/bootx64.efi might be a good standard procedure. This will give you a fallback method of booting if your NVRAM gets wiped. The trouble is that most boot managers that understand how to launch a shell (such as rEFIt, rEFInd, and gummiboot) don't look for a shell in that location.

Corubba · 2013-01-09 19:42:19

srs5694 wrote:

geohei wrote:
Strange ... the system booted like that, but with elilo.efi. This file doesn't exist in /boot/efi. Very weird. Seems to be generic bypassing grub.
If you don't specify a boot loader filename for efibootmgr, it assumes \elilo.efi. Thus, it will add such an entry if you don't override it with -l.

I have tested the posted commands on my arch system, and it produces the exactly same entry without specifying the loader (the label has changed though). Maybe the arch package is patched in some way.

srs5694 · 2013-01-09 22:17:48

Corubba wrote:

srs5694 wrote:
geohei wrote:
Strange ... the system booted like that, but with elilo.efi. This file doesn't exist in /boot/efi. Very weird. Seems to be generic bypassing grub.
If you don't specify a boot loader filename for efibootmgr, it assumes \elilo.efi. Thus, it will add such an entry if you don't override it with -l.
I have tested the posted commands on my arch system, and it produces the exactly same entry without specifying the loader (the label has changed though). Maybe the arch package is patched in some way.

I just checked and found that typing "efibootmgr -c" in Arch produces an entry that points to \EFI\arch_grub\grux64.efi, even though this file doesn't exist on my system and I did not boot using GRUB. Typing the same command produces an entry that points to \EFI\redhat\grub.efi in Fedora 18 or to \elilo.efi in OpenSUSE 12.2. Thus, it looks like some distributions, including Arch, are applying patches to modify the default behavior. All three distributions' man pages specify that the default if -l is omitted is \elilo.efi, though, so whoever's applying the patches isn't bothering to update the documentation.

cfr · 2013-01-10 02:02:18

Arch patches it so the default is "\\EFI\\arch_grub\\grubx64.efi" with label "Arch Linux (GRUB2)".

The Windows installer at least will obviously set up its boot loader as the installers for most (non-DIY) OSs will. Hence the Windows Boot Menu. I'm guessing Windows replaces its own entry if it doesn't exist on boot.

I didn't mean flashing the BIOS - just loading the defaults. For me, that wipes all custom EFI boot entries.

Corubba · 2013-01-10 08:54:14

srs5694 wrote:

Corubba wrote:
srs5694 wrote:
If you don't specify a boot loader filename for efibootmgr, it assumes \elilo.efi. Thus, it will add such an entry if you don't override it with -l.
I have tested the posted commands on my arch system, and it produces the exactly same entry without specifying the loader (the label has changed though). Maybe the arch package is patched in some way.
I just checked and found that typing "efibootmgr -c" in Arch produces an entry that points to \EFI\arch_grub\grux64.efi, even though this file doesn't exist on my system and I did not boot using GRUB. Typing the same command produces an entry that points to \EFI\redhat\grub.efi in Fedora 18 or to \elilo.efi in OpenSUSE 12.2. Thus, it looks like some distributions, including Arch, are applying patches to modify the default behavior. All three distributions' man pages specify that the default if -l is omitted is \elilo.efi, though, so whoever's applying the patches isn't bothering to update the documentation.

Interesting. I'm using GRUB2 and the efi file path for my system was by coindicence the same as the default. Thanks for pointing this out. Filled out a Bugreport.

geohei · 2013-01-10 14:20:08

srs5694 wrote:

geohei wrote:
Strange ... the system booted like that, but with elilo.efi. This file doesn't exist in /boot/efi. Very weird. Seems to be generic bypassing grub.
If you don't specify a boot loader filename for efibootmgr, it assumes \elilo.efi. Thus, it will add such an entry if you don't override it with -l.
Note that the NVRAM entries that efibootmgr maintains are a sequence to be tried; if the first entry is invalid or terminates, the firmware tries the second. If the second fails, the firmware tries the third. Thus, creating an invalid entry -- as for elilo.efi if it doesn't exist -- has no practical effect on the boot process, since the firmware just skips it and goes on to the next entry.

Understood! But where can I have a look at the "sequence to be tried"? It doesn't seem to be the "BootOrder:" or the "Boot0000, ..." lines as shown by efibootmgr.

root@xxx:/home/geohei# efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001,0000,0003,0004,0005
Boot0000* Windows Boot Manager	...
Boot0001* TesT	HD(1,800,32000,06ad3b4e-882e-485d-ad33-d6c140477c92)File(\elilo.efi)
Boot0002* Ubuntu 12.10	HD(1,800,32000,06ad3b4e-882e-485d-ad33-d6c140477c92)File(\EFI\ubuntu\grubx64.efi)
Boot0003* Hard Drive 	...
Boot0004* CD/DVD Drive 	...
Boot0005* lala	HD(1,800,32000,06ad3b4e-882e-485d-ad33-d6c140477c92)File(\elilo.efi)

"TesT" and "lala" started Ubuntu. lala is the last in the list and the last in "BootOrder:". Deleting Boot0002 made "TesT" and "lala" starting Windows! Reinstalling the original boot entry (using Live CD) made everything work as before ("TesT" and "lala" started Ubuntu again).

srs5694 wrote:

There are two possibilities:
Windows may have noticed that its entry was missing from the firmware when it booted, and it wrote a new entry for itself.
The firmware may be hard-coded to look for the Windows boot loader and create an entry for it if it doesn't exist.
I know for a fact that some -- but not all -- EFI implementations do the latter. Specifically, I've seen my Gigabyte motherboard with a Hybrid EFI do this on a computer that's never had Windows installed on it. It's been a while since I did most of my experiments with it, but as I recall, the board would tend to either forget its NVRAM entries entirely or replace valid entries for Linux boot loaders with invalid entries for the Windows boot loader. It was absolutely maddening when I was dealing with it. In the end, I just stopped trying; I found that the computer boots most reliably with my desired boot loader installed on the ESP as EFI/BOOT/bootx64.efi. This is the fallback filename, so I just don't have any NVRAM entries.
I'm not sure if Windows does the former, or if it does, under what circumstances. Certainly I've seen complaints about Windows restoring its boot loader to be the default one in some forum posts, but I'm not 100% sure of what's causing that problem -- it's conceivable that it's actually the firmware doing the mischief, not Windows.

This sounds very wild. I believe (?) for me, it's the former possibility. First, I don't have seen valid Linux entries being replaced by Windows entries. Then I also don't have entries disappearing. But then I have to say that I'm not that experienced in UEFI. I also use a Hybrid EFI Gigabyte motherboard - GA-Z77X-UD5H w/ F14 firmware. Probably I will end up as well using a single bootloader and forgetting about UEFI!

Also ... is it possible the somehow backup the UEFI NVRAM entries for later use? Does efibootmgr or EFI Shell off commands for this?

Please have a look at this:

root@xxx:/boot/efi/EFI# ls -l
total 3
drwxr-xr-x 2 root root 1024 Jan 10 12:21 Boot
drwxr-xr-x 3 root root 1024 Jan 10 12:15 Microsoft
drwxr-xr-x 2 root root 1024 Jan 10 12:44 ubuntu
root@xxx:/boot/efi/EFI# find /boot/efi -name "*.efi"
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
/boot/efi/EFI/Microsoft/Boot/bootmgr.efi
/boot/efi/EFI/Microsoft/Boot/memtest.efi
/boot/efi/EFI/Boot/bootx64.efi
/boot/efi/EFI/ubuntu/grubx64.efi

I believe that EFI/Microsoft directory way created during Windows 7 installation and /EFI/Boot when actually first starting Windows 7. I believe bootx64.efi is the main Windows 7 boot loader. Can you confirm that?

Thanks,

Last edited by geohei (2013-01-10 15:14:03)

srs5694 · 2013-01-10 16:22:52

geohei wrote:

srs5694 wrote:
Note that the NVRAM entries that efibootmgr maintains are a sequence to be tried; if the first entry is invalid or terminates, the firmware tries the second. If the second fails, the firmware tries the third. Thus, creating an invalid entry -- as for elilo.efi if it doesn't exist -- has no practical effect on the boot process, since the firmware just skips it and goes on to the next entry.
Understood! But where can I have a look at the "sequence to be tried"? It doesn't seem to be the "BootOrder:" or the "Boot0000, ..." lines as shown by efibootmgr.

It is the BootOrder entry.

root@xxx:/home/geohei# efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0001,0000,0003,0004,0005
Boot0000* Windows Boot Manager	...
Boot0001* TesT	HD(1,800,32000,06ad3b4e-882e-485d-ad33-d6c140477c92)File(\elilo.efi)
Boot0002* Ubuntu 12.10	HD(1,800,32000,06ad3b4e-882e-485d-ad33-d6c140477c92)File(\EFI\ubuntu\grubx64.efi)
Boot0003* Hard Drive 	...
Boot0004* CD/DVD Drive 	...
Boot0005* lala	HD(1,800,32000,06ad3b4e-882e-485d-ad33-d6c140477c92)File(\elilo.efi)

"TesT" and "lala" started Ubuntu.

If you have no elilo.efi boot loader in your ESP's root, then this makes sense; you specified an invalid boot entry, so the system dropped back to its default -- entry #2, which is for Ubuntu's GRUB.

lala is the last in the list and the last in "BootOrder:". Deleting Boot0002 made "TesT" and "lala" starting Windows!

Again, this makes perfect sense if you have no working elilo.efi boot loader; with 0002 removed from the list, the next working boot loader in the list is 0000, which is Windows.

Probably I will end up as well using a single bootloader and forgetting about UEFI!

Note that dropping to a single default boot loader at /EFI/BOOT/bootx64.efi is not the same as ditching EFI; if you boot via a file at /EFI/BOOT/bootx64.efi, you're still booting via EFI -- you're just doing so using its default/fallback filename rather than via an NVRAM entry. Ditching EFI entirely means installing a BIOS-mode boot loader (such as LILO, GRUB Legacy, or the BIOS version of GRUB 2) and ignoring or deleting the files on the ESP, or even deleting the ESP entirely.

Also ... is it possible the somehow backup the UEFI NVRAM entries for later use? Does efibootmgr or EFI Shell off commands for this?

That would certainly be a useful function, but AFAIK efibootmgr can't do it. That said, a script to do it with efibootmgr wouldn't be all that hard to write. I don't know of a way to do it with an EFI shell, either, although I might simply not know about the feature.

Please have a look at this:
root@xxx:/boot/efi/EFI# ls -l
total 3
drwxr-xr-x 2 root root 1024 Jan 10 12:21 Boot
drwxr-xr-x 3 root root 1024 Jan 10 12:15 Microsoft
drwxr-xr-x 2 root root 1024 Jan 10 12:44 ubuntu
root@xxx:/boot/efi/EFI# find /boot/efi -name "*.efi"
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
/boot/efi/EFI/Microsoft/Boot/bootmgr.efi
/boot/efi/EFI/Microsoft/Boot/memtest.efi
/boot/efi/EFI/Boot/bootx64.efi
/boot/efi/EFI/ubuntu/grubx64.efi
I believe that EFI/Microsoft directory way created during Windows 7 installation and /EFI/Boot when actually first starting Windows 7. I believe bootx64.efi is the main Windows 7 boot loader. Can you confirm that?

I don't know about when the various files are created, but Windows 7's official boot loader is EFI/Microsoft/Boot/bootmgfw.efi, and Windows stores a backup of that boot loader as EFI/BOOT/bootx64.efi.

geohei · 2013-01-11 07:07:40

srs5694 wrote:

...
Again, this makes perfect sense if you have no working elilo.efi boot loader; with 0002 removed from the list, the next working boot loader in the list is 0000, which is Windows.

Yes, got it now. If an invalid entry is selected, it takes the first one from "BootOrder:". My misunderstanding was that it continues from the selected invalid item in the "BootOrder:" to the end of the list.

srs5694 wrote:

Probably I will end up as well using a single bootloader and forgetting about UEFI!
Note that dropping to a single default boot loader at /EFI/BOOT/bootx64.efi is not the same as ditching EFI; if you boot via a file at /EFI/BOOT/bootx64.efi, you're still booting via EFI -- you're just doing so using its default/fallback filename rather than via an NVRAM entry. Ditching EFI entirely means installing a BIOS-mode boot loader (such as LILO, GRUB Legacy, or the BIOS version of GRUB 2) and ignoring or deleting the files on the ESP, or even deleting the ESP entirely.

Badly phrased from my side. I meant "dropping UEFI boot management", id est using a single boot loader like e.g. grub to manager OS selection.

srs5694 wrote:

Please have a look at this:
root@xxx:/boot/efi/EFI# ls -l
total 3
drwxr-xr-x 2 root root 1024 Jan 10 12:21 Boot
drwxr-xr-x 3 root root 1024 Jan 10 12:15 Microsoft
drwxr-xr-x 2 root root 1024 Jan 10 12:44 ubuntu
root@xxx:/boot/efi/EFI# find /boot/efi -name "*.efi"
/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
/boot/efi/EFI/Microsoft/Boot/bootmgr.efi
/boot/efi/EFI/Microsoft/Boot/memtest.efi
/boot/efi/EFI/Boot/bootx64.efi
/boot/efi/EFI/ubuntu/grubx64.efi
I believe that EFI/Microsoft directory way created during Windows 7 installation and /EFI/Boot when actually first starting Windows 7. I believe bootx64.efi is the main Windows 7 boot loader. Can you confirm that?
I don't know about when the various files are created, but Windows 7's official boot loader is EFI/Microsoft/Boot/bootmgfw.efi, and Windows stores a backup of that boot loader as EFI/BOOT/bootx64.efi.

Right, it is a copy.

I believe (also not sure) that the *.efi binary in /EFI/Boot is supposed to be the default code executed when the UEFI HDD entry from the UEFI Boot Manager is selected?

srs5694 · 2013-01-11 15:32:28

geohei wrote:

I believe (also not sure) that the *.efi binary in /EFI/Boot is supposed to be the default code executed when the UEFI HDD entry from the UEFI Boot Manager is selected?

The EFI spec says nothing (or perhaps next to nothing; I don't claim to have read it all) about user interfaces. Thus, the behavior when you select any given entry in a user interface is left entirely up to whoever designs that user interface. This is one of the great frustrations about the shift to EFI; different manufacturers have designed different user interfaces that give different options in different ways. The resulting massive differences make it very difficult to document procedures that work on many systems or to help people accomplish tasks that really are quite simple, just because the way the task is accomplished varies from one system to another. The result is a lot of "try this, and if it doesn't work, try that, and if that doesn't work, try another thing," and then the user comes back and says none of those things worked, so somebody else chimes in with another idea, and so on. What should be a simple procedure takes a dozen posts to resolve, not because it's hard, but because it varies so much between computers.

cfr · 2013-01-12 00:30:51

For whatever it is worth, that's how mine seems to work. I don't know if it is meant to but that is what it seems to do in practice!

geohei · 2013-01-31 15:53:22

Thanks a lot for the posts!
I slowly understand how my motherboard (i.e. UEFI user interface) works ...

Arch Linux

#1 2013-01-08 09:29:22

efibootmgr label rename

#2 2013-01-08 23:14:43

Re: efibootmgr label rename

#3 2013-01-09 00:04:17

Re: efibootmgr label rename

#4 2013-01-09 05:22:38

Re: efibootmgr label rename

#5 2013-01-09 06:05:03

Re: efibootmgr label rename

#6 2013-01-09 19:42:19

Re: efibootmgr label rename

#7 2013-01-09 22:17:48

Re: efibootmgr label rename

#8 2013-01-10 02:02:18

Re: efibootmgr label rename

#9 2013-01-10 08:54:14

Re: efibootmgr label rename

#10 2013-01-10 14:20:08

Re: efibootmgr label rename

#11 2013-01-10 16:22:52

Re: efibootmgr label rename

#12 2013-01-11 07:07:40

Re: efibootmgr label rename

#13 2013-01-11 15:32:28

Re: efibootmgr label rename

#14 2013-01-12 00:30:51

Re: efibootmgr label rename

#15 2013-01-31 15:53:22

Re: efibootmgr label rename

Board footer