3

I am trying to ascertain where the EFI boot records are located on my Lenovo U41o by using the command sudo efibootmgr -v.

Can someone explain it to me?

$ sudo efibootmgr -v
BootCurrent: 0008
Timeout: 0 seconds
BootOrder: 0010,0003,0004,0005,0006,0008,0007,0009,000A,000B,001D
Boot0000  Setup 
Boot0001  Boot Menu 
Boot0002  Diagnostic Splash 
Boot0003* ATA HDD2: WDC WD5000LPVT-08G33T1                      ACPI(a0341d0,0)PCI(1f,2)03120a00010000000000..bYVD.A...O.*..
Boot0004* ATA SSD1: SanDisk SSD U100 24GB                       ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000..bYVD.A...O.*..
Boot0005* RAID DEVICE2: 030a2500d23878bc820f604d8316c068ee79d25ba5388f9ca46ace40bf2f0ade9bc05d6d01
Boot0006* RAID DEVICE1: 030a2500d23878bc820f604d8316c068ee79d25ba5388f9ca46ace40bf2f0ade9bc05d6d00
Boot0007* ATAPI CD: 030a2400d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a354
Boot0008* USB HDD: SanDisk Cruzer Edge  ACPI(a0341d0,0)PCI(1a,0)USB(0,0)USB(0,0)3.!..3.G..A.....
Boot0009* USB FDD:  030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot000A* USB CD:   030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot000B* PCI LAN: EFI Network (IPv4)   ACPI(a0341d0,0)PCI(1c,1)PCI(0,0)MAC(089e01381698,0)IPv4(0.0.0.0:0<->0.0.0.0:0,0, 0x.J.+*.N.....=8.
Boot000C* Lenovo Recovery System    ACPI(a0341d0,0)PCI(1f,2)03120a00010000000000HD(3,276800,1f4000,26c6992a-07b8-43bc-98b8-d8c83e64db3b)File(\EFI\Microsoft\Boot\lrsBootMgr.efi)
Boot0010* Windows Boot Manager  HD(2,1f4800,82000,72931328-061b-42e0-8fd8-8a5ac7775074)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...e................
Boot0014  Setup 
Boot0015  Boot Menu 
Boot0016  Diagnostic Splash 
Boot001C* Lenovo Recovery System    ACPI(a0341d0,0)PCI(1f,2)03120a00010000000000HD(3,276800,1f4000,26c6992a-07b8-43bc-98b8-d8c83e64db3b)File(\EFI\Microsoft\Boot\lrsBootMgr.efi)
Boot001D* PCI LAN: EFI Network (IPv6)   ACPI(a0341d0,0)PCI(1c,1)PCI(0,0)MAC(089e01381698,0)030d3c000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000x.J.+*.N.....=8.
5

I'm going to take these out of order, since some of the early lines refer to later ones. The bulk of the output is the Boot#### lines, which describe boot options.

Boot0000  Setup 
Boot0001  Boot Menu 
Boot0002  Diagnostic Splash 

Your example output includes a large number of options like these, which have names but no further elaboration. These are likely built-in options on your specific firmware. In your case, these first three seem to be options to enter the firmware setup menu, to launch the built-in boot manager, and to display a diagnostic splash screen -- but really, there's no way to know for sure what they are, at least not from the efibootmgr output alone.

The numbers following the Boot string are in hexadecimal, and there's nothing special about any given number -- that is, Boot0000 is not reserved for any particular function, nor is Boot0001 or anything else. The numbers are assigned when a program creates a new boot entry, and the assignments are essentially meaningless. (At least, unless there's a bug; I know of some bugs that can make a firmware favor lower-numbered boot entries.)

Boot0003* ATA HDD2: WDC WD5000LPVT-08G33T1                      ACPI(a0341d0,0)PCI(1f,2)03120a00010000000000..bYVD.A...O.*..
Boot0004* ATA SSD1: SanDisk SSD U100 24GB                       ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000..bYVD.A...O.*..

These two options describe specific devices. After the Boot#### string comes a description that is human-interpretable, at least to a point -- you can see that these are two disk devices. The ACPI(...) and PCI(...) strings identify the hardware, and this information isn't readily interpreted by humans, except by cross-checking with other hardware information. Then there's some gibberish, which is encoded data for the entry that might or might not be easily read by humans. In this case, it's clearly not easily interpreted by people.

In most cases, when you see an entry like this that refers to a disk device, the reference is really to the fallback boot loader file (EFI/BOOT/bootx64.efi, at least on x86-64 systems) on the disk's EFI System Partition (ESP). EFI does not use boot loaders embedded in a disk's MBR, the way BIOS does.

Boot0005* RAID DEVICE2: 030a2500d23878bc820f604d8316c068ee79d25ba5388f9ca46ace40bf2f0ade9bc05d6d01
Boot0006* RAID DEVICE1: 030a2500d23878bc820f604d8316c068ee79d25ba5388f9ca46ace40bf2f0ade9bc05d6d00
Boot0007* ATAPI CD: 030a2400d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a354

These are clearly more hardware entries. I don't recognize the format for these entries. You can ignore the long strings; just know that they refer to hardware devices.

I'm omitting a few entries here, since they're more of the same....

Boot000B* PCI LAN: EFI Network (IPv4)   ACPI(a0341d0,0)PCI(1c,1)PCI(0,0)MAC(089e01381698,0)IPv4(0.0.0.0:0<->0.0.0.0:0,0, 0x.J.+*.N.....=8.

This is a variant on the disk entries, but this one identifies a network device. Note that it includes a MAC address (MAC(...)) and specifies use of IPv4 (IPv4(...)). If this entry were to be booted, the computer would try to PXE-boot from a network server.

Boot000C* Lenovo Recovery System    ACPI(a0341d0,0)PCI(1f,2)03120a00010000000000HD(3,276800,1f4000,26c6992a-07b8-43bc-98b8-d8c83e64db3b)File(\EFI\Microsoft\Boot\lrsBootMgr.efi)
Boot0010* Windows Boot Manager  HD(2,1f4800,82000,72931328-061b-42e0-8fd8-8a5ac7775074)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...e................

These entries both identify EFI boot loaders stored on the hard disk. They do so with slightly different syntaxes -- note that the first begins with ACPI(...) and PCI(...) entries, as earlier ones did, whereas the second uses an HD(...) identifier. The latter includes a GUID for the partition, along with some other idenfications. Both entries include a filename (File(...)). The Windows entry includes more gibberish-like data at the end, but in this case it's a UTF-16 string that's passed to the boot loader as an option.

Your example includes a lot of entries. Many EFIs produce much shorter lists -- for instance, they may be missing the built-in options or the options for PXE-booting from the network. OTOH, sometimes you'll see other options, like entries that refer to BIOS-mode boots. Notably absent from your list was an entry for booting Ubuntu. Here's such an entry from one of my computers:

Boot000D* ubuntu    HD(1,800,112800,a8d39218-44ce-455b-8735-919754df131d)File(\EFI\UBUNTU\GRUBX64.EFI)..BO

As you can see, that's pretty similar in basic form to the entry for the Windows boot loader, although of course the details differ. Your example may have been missing an Ubuntu entry because you haven't yet installed Ubuntu, because you installed Ubuntu in BIOS/CSM/legacy mode (a mistake), because your EFI is buggy and so efibootmgr was unable to add an entry, or because you explicitly deleted the entry once it was created. If you're having a boot problem, I recommend you ask another question and provide details.

The remaining entries follow these patterns. Now, backing up to the start....

ubuntu@ubuntu:~$ sudo efibootmgr -v
BootCurrent: 0008

The BootCurrent line identifies the entry that was used to boot the computer. In this case, it's Boot0008, which I snipped but which identifies a USB flash drive -- you booted using the fallback boot loader stored on that drive.

Timeout: 0 seconds

This line identifies the timeout on the EFI's built-in boot manager. In practice, it might or might not mean anything.

BootOrder: 0010,0003,0004,0005,0006,0008,0007,0009,000A,000B,001D

This line identifies the order in which boot entries are tried. In this case, the EFI will try booting with Boot0010 (the Windows boot manager). If that entry identifies a non-existent device or file, or if the boot program returns, then the firmware will try Boot0003 (your Western Digital hard disk). If that entry fails, it will try Boot0004 (your SanDisk SSD), and so on.

  • So when there's no File() string, that means (or probably means) the firmware uses the fallback boot loader? Why doesn't all distros simply store their bootloader as a the fallback bootloader? – CMCDragonkai Dec 4 '15 at 7:38
  • Found a good explanation here: blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition – CMCDragonkai Dec 4 '15 at 7:44
  • 1
    Entries without a File() specification could also refer to BIOS/CSM/legacy-boot options, to specialty options (like the network-boot entries), etc. The original EFI 1.0 spec said that the fallback filename was to be used only on removable media. In practice, manufacturers began deviating from this and supporting it on hard disks, and eventually that worked its way into the spec. One of the benefits of EFI over BIOS is that it makes it easier for multiple OSes to coexist -- at least in theory. If every OS used the fallback boot loader location, that benefit would be nullified. – Rod Smith Dec 4 '15 at 14:22
  • Ok, so the advantage of having a fallback bootloader for removable media would be during first-time installations, where you plug in a USB bootable media for the first time on a computer with no OS, the firmware can find the bootloader? – CMCDragonkai Dec 4 '15 at 15:02
  • 1
    Correct; that's the original intent. The benefit of using it on a hard disk is that if your NVRAM entries are lost or corrupted, the computer will have something to boot. IMHO, it's reasonable to put the most flexible boot manager available there to handle such problems. – Rod Smith Dec 4 '15 at 15:16
1

You can get a detailed explanation of the efibootmgr package with the command:

    man efibootmgr

It explains the output you get from efibootmgr in great detail.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.