7.5 KiB
grub
GNU GRUB (short for GNU GRand Unified boot loader, commonly referred to as GRUB) is a boot loader package from the GNU Project. GRUB is the reference implementation of the Free Software Foundation's Multiboot Specification, which provides a user the choice to boot one of multiple operating_systems installed on a computer or select a specific kernel configuration available on a particular operating system's partitions.
GNU was developed from a package called the Grand Unified Bootloader (a play on Grand Unified Theory). It is predominantly used for Unix-like systems.
Booting
When a computer is turned on, its BIOS finds the primary bootable device (usually the computer's hard disk) and runs the initial bootstrap program from the master boot record (MBR). The MBR is the first sector of the hard disk. This bootstrap program must be small because it has to fit in a single sector. For a long time, the size of a sector has been 512 bytes. Since 2009 there are hard disks available with a sector size of 4096 bytes, called Advanced Format disks, but as of October 2013, such hard disks are still accessed in 512-byte sectors, using the 512e emulation. The legacy MBR partition table supports a maximum of four partitions and occupies 64 bytes, combined. Together with the optional disk signature (four bytes) and disk timestamp (six bytes), this leaves between 434 and 446 bytes available for the machine code of a boot loader. Although such a small space can be sufficient for very simple boot loaders, it is not big enough to contain a boot loader supporting complex and multiple file systems, menu-driven selection of boot choices, etc. Boot loaders with bigger footprints are therefore split into pieces, where the smallest piece fits in the MBR, while one or more larger pieces are stored in other locations such as empty sectors between the MBR and the first partition. The code in the MBR then does little more than starting the second part.
The purpose of the remaining part(s) of the boot loader is to actually boot an operating system by configuring it and starting the kernel. Kernels are in most cases stored as files residing on appropriate file systems, but the concept of a file system is unknown to the BIOS. Thus, in BIOS-based systems, the duty of a boot loader is to access the content of those files, so it can be loaded into the RAM and executed.
One possible approach for boot loaders is to load kernel images by directly accessing hard disk sectors without understanding the underlying file system. Usually, an additional level of indirection is required, in form of maps or map files – auxiliary files that contain a list of physical sectors occupied by kernel images. Such maps need to be updated each time a kernel image changes its physical location on disk, due to installing new kernel images, file system defragmentation, etc. Also, in case of the maps changing their physical location, their locations need to be updated within the boot loader's MBR code, so the sectors indirection mechanism continues to work. This is not only cumbersome, but it also leaves the system in need of manual repairs in case something goes wrong during system updates.
Another approach is to make a boot loader aware of the underlying file systems, so kernel images are configured and accessed using their actual file paths. That requires a boot loader to contain a driver for each of the supported file systems, so they can be understood and accessed by the boot loader itself. This approach eliminates the need for hardcoded locations of hard disk sectors and existence of map files, and does not require MBR updates after kernel images are added or moved around. The configuration of a boot loader is stored in a regular file, which is also accessed in a file system-aware way to obtain boot configurations before the actual booting of any kernel images. Thus, fewer things can go wrong during system updates. As a downside, such boot loaders are larger and more complex.
GNU GRUB uses the second approach, by understanding the underlying file systems. The boot loader itself is split into multiple stages so that it fits in the MBR boot scheme.
Two major versions of GRUB are in common use: GRUB version 1, called GRUB legacy, is only prevalent in older releases of Arco-Linux distributions. GRUB 2 was written from scratch and intended to replace its predecessor, and is now used by a majority of Linux distributions.
Startup on Systems using UEFI firmware
/efi/<distro>/grubx64.efi (for x64 UEFI systems) is installed as a file in the EFI System Partition, and booted by the firmware directly, without a boot.img in MBR sector 0. This file is like stage1 and stage1.5.
To Fix the shim lock symbol not found grub error:
Insert and Boot from a Linux stick
go to a command-line and :
To do that find the device that holds the file system information:
Type lsblk which gives you output similar to:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:32 0 28,5G 0 disk
└─sda1 8:34 0 38,5G 0 part /run/archiso/... # <- This is the usb drive
sdb 8:32 0 238,5G 0 disk
├─sdb1 8:33 0 300M 0 part # <- This is the Efi boot record
└─sdb2 8:34 0 238,2G 0 part # <- This is the root file System of the underlying pcIf the lsblk command does not list your drive, make sure it is functioning properly. If the drive works it could be that the BIOS list the drive in raid mode. Deactivate the raid mode for the drive in the BIOS and reboot the system.
Before you can use your System to fix the error you have to mount the underlying root file system.
sudo mount /dev/sdb2/ /mnt/ # <- sdb2 is your root file systemIf that does not give you an error proceed with mounting the boot partition:
sudo mount /dev/sdb1/ /mnt/boot/efi/ # <- sdb1 is your boot partition
It is important to note that the device you want to mount has to be prefixed with the path /dev/ otherwise it cannot be found by the system. If that also does not prompt you with an error you can proceed to change the root directory with arch-chroot.
sudo arch-chroot /mnt/The shim lock error is caused by an update of grub, that moves the grubx64.efi file to a new location that is not yet known by the bios. Therfore a downgrade of the grub version does not work because it does not change the file location back to its original position. So in order to fix the issue you have to notice the BIOS of the new grub boot file location. To do that use the command:
sudo efibootmgr --create --disk /dev/sdb --part 1 --label "Name of boot entry" --loader \\EFI\\<name of distro e.g. /arcolinux>\\grubx64.efi
# the disk lets the BIOS know in which part of the drive (partition) it should look
# note the double backslash (\\) "windows" notation
If that gives you no error proceed and type exit to leave the chroot. After that reboot the system and remove the usb drive.