Later, when the UEFI boot process kicks in, it will look on the ESP (the FAT partition) for a subdirectory of /EFI called ( multiboot in our case) and expect to find a suitable. This includes the word multiboot in the pathname. The generated image ( core.efi) is copied to /tmp/usb-sda/boot/efi/EFI/multiboot/grub圆4.efi. Grub2-install: info: copying `/tmp/usb-sda/boot/grub2/x86_64-efi/core.efi' -> `/tmp/usb-sda/boot/efi/EFI/multiboot/grub圆4.efi'. Grub2-install: info: writing 0x1dc00 bytes. This is the output of running grub2-install with the above arguments with notes interspersed: This appears to be a well-known fallback name that UEFI boot systems will look for. BOOT/BOOTX86.efi (or a similar name for 32bit). This may be an issue in which case you can also pass the -removable flag which will ignore your -bootloader-id flag and create. If you put it in a machine where the BIOS decides your USB stick is sdb then you cannot boot off this stick. This will create a GRUB2 boot which refers to sda. Luckily, the efibootmgr output is at the end Unfortunately, most of the verbose output is the symbol-by-symbol transcript of producing a non-relocatable binary (there is no link-loader for the boot process!). Verbose - without this we won't see the arguments being supplied to efibootmgr. Here we are choosing the string multiboot Without this you'll get a 32bit build and/or a warning about a missing /usr/lib/grub/x86_64-efi/modinfo.shīootloader-id is the clearly identifiable name we want to see in the BIOS screens, it defaults to grub. Grub2-install takes a heap of arguments many of which are important: Grub2-install no longer works as directed on Fedora 34 and CentOS Stream 8.
0 kommentar(er)
