Avoid setting non-standard GRUB_DISTRIBUTOR in /etc/default/grub if you
use Debian 12 bookworm with enabled Secure Boot and signed grub image
from Debian. Alternatively install grub-2.12 from backports.
On 23/08/2024 11:39, Felix Miata wrote:
I don't know what vexing secure boot might introduce, but without it,
GRUB_DISTRIBUTOR= was used by grub-install in Trixie here to produce
results I expected:
There is significant difference in patches for grub-2.12 in trixie and
for 2.06 in bookworm. In the case of Secure Boot, grub-install copies
signed grubx64.efi instead of generation of an image specific to the
machine.
On 30/08/2024 23:09, Max Nikulin wrote:
I have tried some variants of full shim+grub signed configurations on
[...]
grubx64.efi (v2.06) from Debian bookworm has no problem with reading
grub.cfg placed in the same directory and directory name does not matter.
grubx64.efi (v2.06) from Ubuntu 20.04 focal reads config file strictly
from EFI/ubuntu/grub.cfg.
If there is EFI/debian/grub.cfg then it has higher priority than the
file from the directory from where grubx64.efi is loaded. Loading config
file from a custom directory looks like an unintentional behavior.
I have not figured out what specific patch causes the difference. A lot
of lines are changed. I do not think it is a security measure.
The difference of grub-2.06 behavior between Ubuntu and Debian are
caused by build script, not by patches. It is a result of an attempt to
fix issues with Unicode characters. Relevant changes:
grub2 (2.06-14) experimental; urgency=medium
* Bundle unicode.pf2 in a squashfs memdisk attached to the signed EFI binary
-- Julian Andres Klode <j...@debian.org> Mon, 19 Jun 2023 17:26:49 +0200
grub2 (2.06-6) unstable; urgency=medium
* Include fonts in the memdisk build for EFI images.
Closes: #1024395, #1025352, #1024447
-- Steve McIntyre <93...@debian.org> Sun, 04 Dec 2022 20:42:23 +0000
Bookworm currently have 2.06-13 and in 2.06-14 config should be loaded
strictly from EFI/debian/grub.cfg.
The script written for booting from CD or a similar media
<https://sources.debian.org/src/grub2/2.06-13%2Bdeb12u1/debian/build-efi-images/#L64>
accidentally got bundled into regular images
<https://sources.debian.org/src/grub2/2.06-13%2Bdeb12u1/debian/build-efi-images/#L240>
Since 2.06-14 a dedicated squashfs image has been provided for fonts, so
the config search script is not a part of prebuilt images.
Perhaps something is broken in attempts to improve booting from network.
I wrote "broken" describing Ubuntu-20.4 behavior where custom
GRUB_DISTRIBUTOR may cause failure to boot. I consider 2.06 broken in
Debian now. However patches making it possible in 2.12 are really
related to network
<https://lists.nongnu.org/archive/html/grub-devel/2023-01/msg00012.html>
A one setting fw_path and
<https://sources.debian.org/patches/grub2/2.12-5/network/try-prefixes-for-tftp-config-file.patch/>
They have not been included into the upstream repository. Debian
changelog entry is
* Port UEFI based network stack to 2.12 (LP: #2039081)
A couple of problems that I have noticed in bookworm:
1. When /usr/lib/shim/BOOTX64.CSV is installed, bootloader id in it is
not adjusted. As a result if additional removable path EFI/BOOT is used
then there is a chance that fbx64.efi will create "debian" boot entry,
not the name specified in GRUB_DISTRIBUTOR
2. It is not apparent that after modifying GRUB_DISTRIBUTOR it is
necessary to create the directory with matched name in /boot/efi/EFI.
Otherwise "dpkg-reconfigure grub-efi-amd64" does not run grub-install. I
would prefer to have an explicit setting instead of relying on presence
of a directory.
3. EFI/debian/grub.cfg has highest priority, so if bookworm is installed
in parallel with another Debian then neither must have
GRUB_DISTRIBUTOR=debian. Moreover grub.cfg likely may be found on some
other disk (e.g. a USB pendrive) having .disk/info. The version from
backports should help.
I believed fixed .cfg path is a UEFI
limitation or at best an inherent grub limitation.
I have realized that shim can not work if it can not load grub from the
same directory. Perhaps it really happens in some cases.
<https://www.gnu.org/software/grub/manual/grub/html_node/cmdpath.html>
in Special environment variables
15.1.4 cmdpath
The location from which core.img was loaded as an absolute directory
name (see File name syntax). This is set by GRUB at startup based on
information returned by platform firmware. Not every platform provides
this information and some may return only device without path name.
For EFI platform the required function is implemented (for many other
platforms it is not), however there are enough code paths when it may
return without providing a usable value.
At first glance shim really loads files using relative paths while grub
tries to obtain absolute path. Perhaps some EFI-specific trick may be
added to grub code to make it more reliable.
Curiously a patch intended to improve config loading breaks cmdpath.
Instead it sets the fw_path variable.
So multiple loaders from the same vendor is tricky in the case of UEFI
SecureBoot. Behavior of grub may vary across Linux distributions.
