Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

grub/EFI questions

Linux Kernel, Network, and Services configuration.
Post Reply
Message
Author
te36
Posts: 12
Joined: 2018-01-29 17:36

grub/EFI questions

#1 Post by te36 »

Setting up booting for multiple disks / partitions or OS is surprisingly obfuscated with grub. EFI seems to put some icing on the cake. Couple of quesionts:

A) I can not remember that there was any choice in debian (stretch) installation to choose EFI explicitly. In any case, i ended up with an EFI system, but with grub instead of grub-efi installed. IT would really be great if update-grub / grub-install had some check and warning if your OS is running EFI but the tools themselves are not. And vice versa.

B) With grub-efi reinstalled, it is somewhat annoying that it seems to delete any existing debian entries in efivars. Means i have to reinstall via efibootmgr entries for each disk again.

C) I could not find authoritative information how grubx64.efi finds the partition to read grub.cfg from. Some URLs seem to indicate that that is actually patched/compiled into the grubx64.efi binary. And they seem to be different across the multiple disks i have. Is this really a good idea ? Wouldn't a small text config file in the EFI partition (grubx64.cfg) be the better solution. Compiling into binary is somewhat grizzly. Sounds like its just the same code used to create the content of the bios_grub partition for BIOS boot ?

D) efibootmgr -c -d /dev/sda -p 1 -L "Debian SDA" -l \\EFI\\debian\\grubx64.efi
efibootmgr -c -d /dev/sdb -p 1 -L "Debian SSD" -l \\EFI\\debian\\grubx64.efi

Boot0000* Debian SSD HD(1,GPT,7d27364d-2b3b-48a0-a4b8-589763354fd9,0x800,0x32000)/File(\EFI\debian\grubx64.efi)
Boot0001* Debian SDA HD(1,GPT,ac760166-dafb-472f-9eb6-fde2b30c3786,0x800,0x32000)/File(\EFI\debian\grubx64.efi)

What are those 0x800 and 0x32000 variables ? Could not find any documentation. Other entries like Windows Boot Manager also have more binary data... any pointers to any documentation for that stuff ?

Thanks!

User avatar
Head_on_a_Stick
Posts: 14114
Joined: 2014-06-01 17:46
Location: London, England
Has thanked: 81 times
Been thanked: 132 times

Re: grub/EFI questions

#2 Post by Head_on_a_Stick »

te36 wrote:i ended up with an EFI system, but with grub instead of grub-efi installed
That doesn't make much sense — did you check if efivarfs was mounted? If grub-efi was not installed then you must have a non-UEFI bootloader, surely.
I could not find authoritative information how grubx64.efi finds the partition to read grub.cfg from
That is such a good question that I did a search for it on your behalf:

https://unix.stackexchange.com/question ... -directory

See also http://forums.debian.net/viewtopic.php?f=30&t=47078

Copy grubx64.efi to $ESP/EFI/BOOT/BOOTX64.EFI, that should be booted automatically even in the absence of any NVRAM entries.

More here: https://www.rodsbooks.com/efi-bootloade ... ive-naming
deadbang

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: grub/EFI questions

#3 Post by p.H »

te36 wrote:A) I can not remember that there was any choice in debian (stretch) installation to choose EFI explicitly.
Of course not. It depends on the boot mode selected by the platform firmware to boot the Debian installer.
- Boot in EFI mode -> installation for EFI boot with GRUB EFI
- Boot in BIOS/legacy mode -> installation for BIOS boot with GRUB BIOS or LILO
te36 wrote:In any case, i ended up with an EFI system, but with grub instead of grub-efi installed.
I agree with Head_on_a_Stick : that does not make any sense.
te36 wrote:IT would really be great if update-grub / grub-install had some check and warning if your OS is running EFI but the tools themselves are not.
Actually update-grub and grub-install themselves are rather independent from the boot mode. For instance, grub-install calls a different subprograms for each "target" (e.g. "x86_64-efi" for EFI 64 bit PC or "i386-pc" for BIOS PC), and the default target is based on the current boot mode (can be overridden with --target=). Of course there is an error if the subprogram for the selected target is not installed.
te36 wrote:B) With grub-efi reinstalled, it is somewhat annoying that it seems to delete any existing debian entries in efivars.
Indeed. I don't know if grub-install still does this in the current version, but in some previous version it deleted every EFI boot entry whose label contained the string "debian", case independent. So my advice is to not use "debian" in the label of any EFI boot entry you create with efibootmgr if you are going to run grub-install afterwards. Remember that grub-install is run in case of a grub-* package update.
te36 wrote:C) I could not find authoritative information how grubx64.efi finds the partition to read grub.cfg from. Some URLs seem to indicate that that is actually patched/compiled into the grubx64.efi binary.
Indeed. AFAIK, there are two cases :
- If /boot/grub is on a partition on the same disk as the core image, then grub-install hardcodes the partition number into the image. So beware if you renumber partitions.
- If /boot/grub is on a different disk, then grub-install embeds a small config file into the core image, containing commands to search the filesystem by UUID. I guess this is because disk numbers set by the platform firmware are unreliable. So beware if you change filesystem UUIDs.
I don't remember whether /boot/grub on a LVM logical volume, an encrypted volume or a software RAID array falls in the former or the latter.
te36 wrote:Wouldn't a small text config file in the EFI partition (grubx64.cfg) be the better solution.
It seems that GRUB EFI in Ubuntu does something like this. Indeed it sounds convenient.
te36 wrote:What are those 0x800 and 0x32000 variables ?
IIUC from my "reverse engineering", they are the hexadecimal offset and size in sectors of the partition containing the EFI file.
0x800 = 2048 sectors = 1 MiB (common offset for the first partition)
0x32000 = 204800 sectors = 100 MiB (common size for an EFI partition even though Debian needs much less)

Post Reply