]> git.proxmox.com Git - efi-boot-shim.git/blame - README.fallback
Improve how the dbx hashes are handled
[efi-boot-shim.git] / README.fallback
CommitLineData
62f0afa2
MTL
1Somebody mailed me this:
2
3> I am trying to understand how fallback.efi works. I have been reading
4> shim.c and see that fallback is called when
5> should_use_fallback(EFI_HANDLE image_handle) returns a 1. But in
6> should_use_fallback(EFI_HANDLE image_handle), there is a comparison of
7> bootpath to \\EFI\\BOOT\\BOOT. Why is it compare to \\EFI\\BOOT\\BOOT
8> since bootpath always return \EFI\Boot\shim.efi?
9
10And it seems like a common enough question that we need some
11documentation of how to properly use shim and fallback. Here's the
12basics of it:
13
14It doesn't always return \EFI\boot\shim.efi - in fact, not ever if
15installed correctly. The FS layouts are like this:
16
17for removable media:
18\EFI\BOOT\BOOTX64.EFI <-- shim
19\EFI\BOOT\MokManager.efi
20\EFI\BOOT\grubx64.efi
21\EFI\BOOT\grub.cfg
22
23for an installed system:
24\EFI\BOOT\BOOTX64.EFI <-- shim
25\EFI\BOOT\MokManager.efi
26\EFI\BOOT\fallback.efi
f4173af1 27\EFI\fedora\BOOT.CSV
62f0afa2
MTL
28\EFI\fedora\shim.efi
29\EFI\fedora\MokManager.efi
30\EFI\fedora\grubx64.efi
31\EFI\fedora\grub.cfg
32
33When you boot removable media, it'll be in \EFI\BOOT , but fallback.efi
34won't be there, so it goes ahead and boots the normal bootloader
35(grubx64.efi). When you boot a normal system through a boot variable,
36the boot variable is configured to start \EFI\fedora\shim.efi (or
37whatever your distro's EFI directory is.) In that case it won't try to
38invoke fallback. But if the boot variables are missing or corrupted,
39the firmware will eventually try to boot the hard disk as removable
40media. In that case, it'll invoke \EFI\BOOT\BOOTX64.EFI (or whatever
41filename is right for your architecture.) In that case it'll be in
42\EFI\BOOT, so it'll check for fallback.efi , and it'll find it and run
43it. When it runs, fallback will look for every directory in \EFI\ with
44a BOOT${ARCH}.CSV in it, or BOOT.CSV if that's not found. It'll parse that,
45and create new boot variables from what it finds. Then it'll try to boot one
46of them.
47
48BOOT.CSV is a UCS-2 LE formatted CSV file. So it has the LE byte order
49marker, and after that it's just a series of lines, each having
50comma-separated date. It looks like this on Fedora:
51
52shim.efi,Fedora,,This is the boot entry for Fedora
53
54so basically it's:
55
56$FILENAME,$LABEL,$LOADER_DATA,$COMMENT0[,$COMMENT1[,...]]
57
58Where $FILENAME has to be the name of a file in the same directory as
59BOOT.CSV .
60