User:Jepio/EFI Shell for recovery

= EFI Shell for recovery =

UEFI firmware is great. It's easy to use and transparent - the booting happens from a FAT formatted partition called the EFI System Partition (ESP). The files that can be loaded are in the EFI executable format and have a .efi suffix. UEFI implementations are supposed to provide users with a built-in boot manager whose entries are stored in the NVRAM. This boot manager should allow the registration and selection of entries. The entries can be adjusted using Efibootmgr. The kernel can be configured with an EFI stub which allows it to be directly booted by the firmware. Therefore UEFI has effectively rendered separate boot loaders obsolete, at least for most use cases.

Bootloaders only have a couple of advantages left over the firmware bootloader:


 * consistency - UEFI implementations can vary strongly in functionality and standards compliance
 * recovery solutions

While GRUB2 provides the grub command line for recovering from a misconfigured system, with minimal effort it is possible to provide the same level of functionality using UEFI components. The goal of this guide is to provide a standardized UEFI based recovery solution.

EFI Shell
A part of the UEFI specification is a sub-specification for a shell. This shell is based on DOS and Unix shells and its purpose is to allow manual running of EFI applications and interacting with the firmware. Basic usage instructions for the UEFI shell can be found in. For more details it is best to dive directly into the specification.

There are two problems with this shell:


 * it is not provided with all distributed firmware
 * it has limited file system support

Only FAT filesystem support is mandatory for UEFI firmware. Some vendors (like Apple, for obvious reasons) implement drivers for other filesystems. If the shell is to be useful for recovery purposes both points need to be dealt with.