]>
Commit | Line | Data |
---|---|---|
62f0afa2 MTL |
1 | Somebody 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 | ||
10 | And it seems like a common enough question that we need some | |
11 | documentation of how to properly use shim and fallback. Here's the | |
12 | basics of it: | |
13 | ||
14 | It doesn't always return \EFI\boot\shim.efi - in fact, not ever if | |
15 | installed correctly. The FS layouts are like this: | |
16 | ||
17 | for removable media: | |
18 | \EFI\BOOT\BOOTX64.EFI <-- shim | |
19 | \EFI\BOOT\MokManager.efi | |
20 | \EFI\BOOT\grubx64.efi | |
21 | \EFI\BOOT\grub.cfg | |
22 | ||
23 | for 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 | ||
33 | When you boot removable media, it'll be in \EFI\BOOT , but fallback.efi | |
34 | won'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, | |
36 | the boot variable is configured to start \EFI\fedora\shim.efi (or | |
37 | whatever your distro's EFI directory is.) In that case it won't try to | |
38 | invoke fallback. But if the boot variables are missing or corrupted, | |
39 | the firmware will eventually try to boot the hard disk as removable | |
40 | media. In that case, it'll invoke \EFI\BOOT\BOOTX64.EFI (or whatever | |
41 | filename 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 | |
43 | it. When it runs, fallback will look for every directory in \EFI\ with | |
44 | a BOOT${ARCH}.CSV in it, or BOOT.CSV if that's not found. It'll parse that, | |
45 | and create new boot variables from what it finds. Then it'll try to boot one | |
46 | of them. | |
47 | ||
48 | BOOT.CSV is a UCS-2 LE formatted CSV file. So it has the LE byte order | |
49 | marker, and after that it's just a series of lines, each having | |
50 | comma-separated date. It looks like this on Fedora: | |
51 | ||
52 | shim.efi,Fedora,,This is the boot entry for Fedora | |
53 | ||
54 | so basically it's: | |
55 | ||
56 | $FILENAME,$LABEL,$LOADER_DATA,$COMMENT0[,$COMMENT1[,...]] | |
57 | ||
58 | Where $FILENAME has to be the name of a file in the same directory as | |
59 | BOOT.CSV . | |
60 |