When using Shim-lock, GRUB can only be successfully booted in Secure Boot mode if its EFI binary includes all of the modules necessary to read the filesystem containing the vmlinuz and initramfs images.
Since GRUB version 2.06.r261.g2f4430cc0, loading modules in Secure Boot Mode via insmod is no longer allowed, as this would violate the expectation to not sideload arbitrary code. If the GRUB modules are not embedded in the EFI binary, and GRUB tries to sideload/insmod them, GRUB will fail to boot with the message:
You must construct your list of GRUB modules in the form of a shell variable that we denote as GRUB_MODULES. You can use the latest Ubuntu script as a starting point, and trim away modules that are not necessary on your system. Omitting modules will make the boot process relatively faster, and save some space on the ESP partition.
You also need a Secure Boot Advanced Targeting (SBAT) file/section included in the EFI binary, to improve the security; if GRUB is launched from the UEFI shim loader. This SBAT file/section contains metadata about the GRUB binary (version, maintainer, developer, upstream URL) and makes it easier for shim to block certain GRUB versions from being loaded if they have security vulnerabilities[1][2], as explained in the UEFI shim bootloader secure boot life-cycle improvements document from shim.
This partition can be in any position order but has to be on the first 2 TiB of the disk. This partition needs to be created before GRUB installation. When the partition is ready, install the boot loader as per the instructions below.
The space before the first partition can also be used as the BIOS boot partition though it will be out of GPT alignment specification. Since the partition will not be regularly accessed performance issues can be disregarded, though some disk utilities will display a warning about it. In fdisk or gdisk create a new partition starting at sector 34 and spanning to 2047 and set the type. To have the viewable partitions begin at the base consider adding this partition last.
Usually the post-MBR gap (after the 512 byte MBR region and before the start of the first partition) in many MBR partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's core.img (FS#24103). It is advisable to use a partitioning tool that supports 1 MiB partition alignment to obtain this space as well as to satisfy other non-512-byte-sector issues (which are unrelated to embedding of core.img).
After the installation, the main configuration file /boot/grub/grub.cfg needs to be generated. The generation process can be influenced by a variety of options in /etc/default/grub and scripts in /etc/grub.d/. For the list of options in /etc/default/grub and a concise description of each refer to GNU's documentation.
If you have not done additional configuration, the automatic generation will determine the root filesystem of the system to boot for the configuration file. For that to succeed it is important that the system is either booted or chrooted into.
To have grub-mkconfig search for other installed systems and automatically add them to the menu, install the os-prober package and mount the partitions from which the other systems boot. Then re-run grub-mkconfig. If you get the following output: Warning: os-prober will not be executed to detect other bootable partitions then edit /etc/default/grub and add/uncomment:
For Windows installed in BIOS mode, mount the Windows system partition (its file system label should be System Reserved or SYSTEM). Run os-prober as root to detect and generate an entry for it.
To pass custom additional arguments to the Linux image, you can set the GRUB_CMDLINE_LINUX + GRUB_CMDLINE_LINUX_DEFAULT variables in /etc/default/grub. The two are appended to each other and passed to kernel when generating regular boot entries. For the recovery boot entry, only GRUB_CMDLINE_LINUX is used in the generation.
It is not necessary to use both, but can be useful. For example, you could use GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=uuid-of-swap-partition quiet" where uuid-of-swap-partition is the UUID of your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without quiet suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options.
GRUB also has special support for booting with an encrypted /boot. This is done by unlocking a LUKS blockdevice in order to read its configuration and load any initramfs and kernel from it. This option tries to solve the issue of having an unencrypted boot partition.
Without further changes you will be prompted twice for a passphrase: the first for GRUB to unlock the /boot mount point in early boot, the second to unlock the root filesystem itself as implemented by the initramfs. You can use a keyfile to avoid this.
If you enter an invalid passphrase during boot and end up at the GRUB rescue shell, try cryptomount -a to mount all (hopefully only one) encrypted partitions or use cryptomount -u $crypto_uuid to mount a specific one. Then proceed with insmod normal and normal as usual.
If the other distribution has already a valid /boot folder with installed GRUB, grub.cfg, kernel and initramfs, GRUB can be instructed to load these other grub.cfg files on-the-fly during boot. For example, for hd0 and the fourth GPT partition:
When choosing this entry, GRUB loads the grub.cfg file from the other volume and displays that menu. Any environment variable changes made by the commands in file will not be preserved after configfile returns. Press Esc to return to the first GRUB menu.
This mode determines where the Windows boot loader resides and chain-loads it after GRUB when the menu entry is selected. The main task here is finding the EFI system partition and running the bootloader from it.
Do not use bootrec.exe /Fixmbr because it will wipe GRUB out.Or you can use Boot Repair function in the Troubleshooting menu - it will not wipe out GRUB but will fix most errors.Also you would better keep plugged in both the target hard drive and your bootable device ONLY. Windows usually fails to repair boot information if any other devices are connected.
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in /boot/grub/, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:
insmod fat is used for loading the FAT file system module for accessing the Windows bootloader on the EFI system partition.(hd0,gpt4) or /dev/sda4 is the EFI system partition in this example.The entry in the chainloader line specifies the path of the .efi file to be chain-loaded.
See #Using the command shell first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.
In case that GRUB does not support the root file system, an alternative /boot partition with a supported file system must be created. In some cases, the development version of GRUB grub-gitAUR may have native support for the file system.
This error may occur when you try installing GRUB in a VMware container. Read more about it here. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read #Master Boot Record (MBR) specific instructions
grub-install automatically tries to create a menu entry in the boot manager. If it does not, then see UEFI#efibootmgr for instructions to use efibootmgr to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in UEFI#Create UEFI bootable USB from ISO.
As another example of creating a GRUB entry in the firmware boot manager, consider efibootmgr -c. This assumes that /dev/sda1 is the EFI System Partition, and is mounted at /boot/efi. Which are the default behavior of efibootmgr. It creates a new boot option, called "Linux", and puts it at the top of the boot order list. Options may be passed to modify the default behavior. The default OS Loader is \EFI\arch\grub.efi.
If the screen only goes black for a second and the next boot option is tried afterwards, according to this post, moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, grub-install will claim efibootmgr has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to install GRUB at the default/fallback boot path:
Some have reported that other distributions may have trouble finding Arch Linux automatically with os-prober. If this problem arises, it has been reported that detection can be improved with the presence of /etc/lsb-release. This file and updating tool is available with the package lsb-release.
This is because /run is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.
GRUB may output error: unknown filesystem and refuse to boot for a few reasons. If you are certain that all UUIDs are correct and all filesystems are valid and supported, it may be because your BIOS Boot Partition is located outside the first 2 TiB of the drive [4]. Use a partitioning tool of your choice to ensure this partition is located fully within the first 2 TiB, then reinstall and reconfigure GRUB.
795a8134c1