HOWTO - Add UEFI Shell boot optionPost Date: 2020-12-15 |
Post Reply
|
Author | |
ErikW
Newbie Joined: 26 Aug 2020 Online Status: Offline Posts: 22 |
Quote Reply
Topic: HOWTO - Add UEFI Shell boot option Posted: 15 Dec 2020 at 9:09pm |
One of the more frustrating things about UEFI is that every implementation has different support for creating and managing the firmware boot entries. Windows will add its own and make it the default, sometimes even if you don't want that. Ubuntu and other Linux distros will usually add their boot entries.
But, what do you do if you want to add your own, and your motherboard provides no way to easily add boot entries? The MSI Creator X288 that I have is like that. One answer to the problem is to boot into a UEFI Shell (UEFI text command console) so that you can enter commands to manage boot entries. A UEFI Shell has a standard set of commands defined by the UEFI specification. Most of the commands use required UEFI system functions, so they generally all work. The only concern is to make sure that your UEFI Shell is the same version, or close to the UEFI firmware. So, how do you boot into a UEFI Shell? Some UEFI firmware comes with a UEFI Shell and has a boot entry or hot key to boot into the shell. On other systems you have to copy the UEFI shell executable file to your EFI System Partition and then boot it. Obviously, if you're installing the shell, it isn't in your boot menu. So, first you have to create a thumb drive, CD or DVD that can boot into the UEFI Shell as a default boot option. You can experiment with the UEFI Shell using the VirtualBox virtual machine software. Select the option to "Enable EFI" for a virtual machine. Press the ESC key immediately when the virtual machine starts to get into the UEFI Shell. Or, only connect disks that have no EFI System Partitions that can be booted. The UEFI Shell is part of the virtual firmware. You can get the UEFI Shell from a few different places, but I recommend downloading the shell along with the rEFInd boot menu software. It has an ISO image and a USB Flash image that you can write directly to the medium that you will boot. Don't download the ZIP archive because it doesn't have the UEFI Shell. Along with rEFInd there are UEFI drivers for filesystems like ISO and ext4 that may or may not be included in your system's UEFI firmware. If you want to create a boot CD/DVD or USB thumb drive with the UEFI Shell, follow the instructions on the rEFInd web site, or read my post explaining how to create a thumb drive with the UEFI Shell. To boot from the CD/DVD or thumb drive, you will usually need to press a hot key as your UEFI firmware is starting up the system. You may have to change the UEFI settings to enable booting from the dvice, or change the priority of boot devices. Your boot media should have an EFI System Partition containing at least the file "\EFI\BOOT\BOOTX64.EFI". With rEFInd you will see a graphical menu, and one choice is to start the UEFI Shell. Other boot media may immediately start the UEFI SHell, or display some other kind of boot menu. After you boot the UEFI Shell, you will see information about the shell, and the "Shell>" prompt. UEFI Interactive Shell v2.2 EDK II UEFI v2.70 (EDK II, 0x00010080) ... Shell> You will also see a list of the filesystem and block devices and the mapped (associated) ACPI (Advanced Configuration and Power Management Interface) device names. You can get the list again at any time using the "map" command in the shell. The UEFI Shell will run a "startup.nsh" script file if there is one. You can press the ESC key to prevent the execution of the script, or wait for the "Shell>" prompt. There is usually no script file, so it is usually not necessary to press ESC. I am going to show the "Shell>" prompt before any shell commands. You should not type the "Shell>" before entering each command. The UEFI Shell has a current working directory just like the Windows Command pronpt. If you set the current device and directory, then that will replace the "Shell>" prompt. For example, you might see "FS0:\>" or "FS1:\EFI\MICROSOFT>" depending on your current device and current directory (path) on that device. If you type a filename with no path, or a relative path (not beginning with "\") then the current directory path will be used as a prefix. To change the current device, you enter the desired filesystem device name instead of a shell command. Shell> FS0: FS0:\> To change the default path for a device, you use the "cd" command. FS0:\> cd \EFI FS0:\EFI> Each device remembers its current directory, so when you change devices, you will also change to the current directory for that device. You can display the current directory device and path by entering "cd" with no other parameters. The prompt displays the same information as "cd". I am going to show only full, absolute paths in the command examples. If you have set a current directory then you can omit the part of the paths that will be provided by your current directory. Like the Windows Command prompt, you can recall and edit previous commands to enter new commands. Press the up arrow key to recall previous commands, or the down arrow key to see the next commands. You can use the left and right arrow keys to move the cursor in the command line being displayed. You can use the other keys to edit the command being displayed. To get a list of the available shell commands, you can use the "help" command. If you add the "-b" option to any command that displays text, it displays one screenfull (block) of text at a time and waits for you to press the Enter key to continue. Here are a couple of examples of using help. The second one shows help for the "dir" command. Shell> help -b Shell> help dir -b In order to install the UEFI Shell, you have to identify which filesystem device "FS0:", "FS1:", etc. contains the shell executable file. You will also need to find your existing EFI System Partition on your hard disk. After that, you need to create the directory to contain the shell executable and copy the executable file to the correct directory on your hard disk. To find the device containing your copy of the shell executable file, use the "map" command. Shell> map -b Mapping table FS1: Alias(s):HD1b0b:;BLK5: PciRoot(0x0)/Pci(0xC,0x0)/USB(0x1,0x0)/HD(1,GPT,78D43E39-1764-49DD-A714-08B4245ADBF7,0x800,0x32000) FS0: Alias(s):HD0a65535a1:;BLK1: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,2E6FFC3F-AD61-497D-9546-C6A331DB1F4C,0x800,0x112801) BLK4: Alias(s): PciRoot(0x0)/Pci(0xC,0x0)/USB(0x1,0x0) BLK0: Alias(s): PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0) BLK3: Alias(s): PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0xFFFF,0x0) BLK2: Alias(s): PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/HD(2,GPT,13B6C680-9AD4-4A4C-8C1F-805B2530F146,0x113800,0x40000) If you look at the example output from the MAP command, you can see that the FS1: filesystem device is mapped to a USB device containing a GPT partition table. In this example, that is the thumb drive that was booted and contains the UEFI Shell executable file. The FS0: filesystem device is mapped to a SATA device containing a GPT partition table. That is the EFI System Partition on the boot hard disk drive. The BLK devices can be used to access partitions as raw binary data, but it isn't usually necessary to do that. After finding the filesystem devices it is a good idea to use the "dir" or "ls" command to verify that they contain the expected files. Shell> dir fs1:\ -r -b Directory of: fs1:\ 12/13/2020 23:59 <DIR> 1,024 EFI 0 File(s) 0 bytes 1 Dir(s) Directory of: FS1:\EFI\ 12/13/2020 23:59 <DIR> 1,024 . 12/13/2020 23:59 <DIR> 0 .. 12/13/2020 23:59 <DIR> 1,024 BOOT 12/14/2020 00:14 <DIR> 1,024 SHELL 0 File(s) 0 bytes 4 Dir(s) Directory of: FS1:\EFI\BOOT\ 12/13/2020 23:59 <DIR> 1,024 . 12/13/2020 23:59 <DIR> 1,024 .. 03/13/2020 08:34 922,272 BOOTX64.EFI 1 File(s) 922,272 bytes 2 Dir(s) Directory of: FS1:\EFI\SHELL\ 12/14/2020 00:14 <DIR> 1,024 . 12/14/2020 00:14 <DIR> 1,024 .. 03/13/2020 08:34 922,272 SHELLX64.EFI 1 File(s) 922,272 bytes 2 Dir(s) Shell> dir fs0:\efi -b Directory of: fs0:\efi\ 10/18/2020 23:19 <DIR> 4,096 . 10/18/2020 23:19 <DIR> 0 .. 10/17/2020 22:33 <DIR> 4,096 MICROSOFT 10/30/2020 21:41 <DIR> 4,096 BOOT 0 File(s) 0 bytes 4 Dir(s) What you see using directory commands will be different than this example. What you need to know is the file path (location) of the UEFI Shell executable file on your removable media (CD/DVD or USB thumb drive). In the example, the executable file is in two places on "FS1:", "FS1:\EFI\BOOT\BOOTX64.EFI" and "FS1:\EFI\SHELL\SHELLX64.EFI". You can tell that because of the names, and the fact that they are exactly the same size and probably the same file. If you booted the rEFInd flash image or ISO CD/DVD, the UEFI Shell executable file is "\EFI\tools\shellx64.efi". You also need to know the filesystem device for your boot hard disk's EFI System Partition. That filesystem usually has a "\EFI\MICROSOFT" directory. In the rest of this example, I am going to assume that you want to copy your UEFI shell to "FS0:\EFI\SHELL\SHELLX64.EFI" and your boot hard disk EFI System Partition is device "FS0:". Replace "FS0:" in the examples with the correct device if that is not "FS0:" The next command creates the new folder on the boot hard disk where the UEFI Shell executable file will be copied. Shell> mkdir FS0:\EFI\SHELL Use the next command to copy the UEFI Shell executable file to the new folder. Shell> cp FS1:\EFI\SHELL\SHELLX64.EFI FS0:\EFI\SHELL\SHELLX64.EFI Copying FS1:\EFI\SHELL\SHELLX64.EFI -> FS0:\EFI\SHELL\SHELLX64.EFI - [ok] The final step to adding the UEFI Command shell is to create the boot entry for the shell. The following command will display the existing boot entries. Shell> bcfg boot dump Option: 00. Variable: Boot0001 Desc - Windows 10 DevPath - HD(1,GPT,2E6FFC3F-AD61-497D-9546-C6A331DB1F4C,0x800,0x112801)/\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI Optional- N Option: 01. Variable: Boot0003 Desc - UEFI VBOX HARDDISK VBc7b17c48-fd121c29 DevPath - PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0) Optional- Y Option: 02. Variable: Boot0000 Desc - UEFI VBOX CD-ROM VB1-1a2b3c4d DevPath - PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0xFFFF,0x0) Optional- Y Option: 03. Variable: Boot0002 Desc - UEFI SanDisk Cruzer Blade 4C530001140513113472 DevPath - PciRoot(0x0)/Pci(0xC,0x0)/USB(0x1,0x0) Optional- Y There are a few important things to say about the above boot entries. The number following "Option:" is how you refer to the menu position and the boot entry that is currently in that position. Those numbers start at 00 for the first menu entry and go up as menu entries are added. Those numbers are in hexadecimal. The "Option:" number for a particular boot choice will change depending on where it appears in the menu. Some of the entries are added by the UEFI firmware on startup because it finds EFI System partitions on the devices, or finds the devices that could contain an EFI System Partition. Others are permanently added. The "Optional:" designation is "N" for the permanent entries. Notice that the first entry is for Windows 10 and refers to "BOOTMGFW.EFI". That entry is usually added by Windows when you install Windows. The "Variable:" name defines the NVRAM variable corresponding to the boot information. That NVRAM variable name/number will never change unless the boot information is deleted. There are different ways to use the "DevPath:" with different path formats. Fortunately the UEFI Shell will convert a normal file path like "FS0:\EFI\SHELL\SHELLX64.EFI" to the correct format. If the file path contains spaces, put it in double quotes. The path format stored in the boot entry depends on the add operation specified with the "bcfg" command. The "addp" operation in this example uses the partition Universally Unique ID (PARTUUID) as the root of the path. The other possible operations are "add" to use the hardware device path, or "addh" to use the device driver handle. Most tutorials tell you to use "add", which is fine, so long as you don't plan to move the target partition to a new SATA port, disk controller, or bus. Using "addp" will always boot the same exact partition no matter where it is connected to the hardware. If you always want the same partition number on the same SATA port to boot no matter what set of files happen to be there, use "add". You would generally use "addp" for disks that are removable or movable when you only want to boot that exact set of files. I am going to focus on using a path based on the UUID for a partition (PARTUUID) that will continue to work even if the hard disk is later moved somewhere else in the hardware. A unique PARTUUID is stored in each GPT entry when it is created. That is NOT the same thing as a filesystem/volume UUID. Unless you clone an exact copy of a hard disk, the PARTUUID for each partition on each GPT formatted disk will be unique. If you change the contents of the partition or reformat the filesystem, that will not change the PARTUUID. Along with the operation and the file path, you also have to specify where to add the new boot menu entry. Position 00 is the first menu position and position 02 is the third menu position. Any exiting entries from that point forward are moved down (assigned higher numbers) to make room. The "Option:" numbers of those entries will change to reflect their new menu positions. Following the file path is a required description to be displayed in the menu. If the description contains spaces, put it in double quotes. Here is the command to add the UEFI Shell as the second menu entry using the Unique ID of the partition to determine the path Shell> bcfg boot addp 1 FS0:\EFI\SHELL\SHELLX64.EFI "UEFI Shell" Target = 0004.bcfg: Add Boot0004 as 1 If you list the boot menu entries again using "bcfg boot dump" you will see a new entry that looks similar to this. Option: 01. Variable: Boot0004 Desc - UEFI Shell DevPath - HD(1,GPT,2E6FFC3F-AD61-497D-9546-C6A331DB1F4C,0x800,0x112801)/\EFI\SHELL\SHELLX64.EFI Optional- N You can add other boot menu entries in the same way. There are additional operations for the "bcfg" command to move or delete menu entries. Use "help bcfg -b" to display all the possible operations. When you restart your system and press the hotkey to display the UEFI firmware boot menu, you should see the UEFI Shell in the menu. If the UEFI firmware cannot find the file associated with a boot entry, then the entry will not appear in the menu. If you don't see the entry, make sure that you didn't create a boot entry that refers to your thumb drive and disappears when you unplug the thumb drive. Windows may change the order of your boot entries or add its boot entry back if you delete that. I'm not going to mention all the possible ways to work around that problem. Having the UEFI Shell may make it easier to deal with those problems. |
|
Post Reply |
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |