Chris Guiver wrote:
> Delay occurs regardless of ISO being written using mkusb, dd, or gnome-
> disks..
Hmm. IIRC mkusb offers to unpack the ISO into a filesystem of the USB stick.
If the problem survives that conversion, then it is far inside the GRUB
equipment.
It should be possible to make experimental changes with the .cfg files of
such an USB stick.
(I can propose xorriso runs which repack an ISO to bear new .cfg content
and the same boot entry points as the original ISO. But directly editing
in a FAT filesystem would be much more straightforward.)
Being curious i looked into ubuntu-20.10-desktop-amd64.iso for occurences
of grub_platform and found in /boot/grub/grub.cfg
grub_platform
if [ "$grub_platform" = "efi" ]; then
menuentry 'Boot from next volume' {
exit
}
It could be that the complaint of GRUB is about the command grub_platform,
not about the use of $grub_platform.
I fail to find the implementation of the command in a freshly pulled GRUB git.
(Other known commands have a call to grub_register_command() with their
name as argument. grub_platform has not.)
A first experiment would be to remove above snippet from grub.cfg and
to check whether its presence caused the long delay.
--------------------------------------------------------------------------
Red herring warning:
The documentation about "normal" mode and grub_platform might be not helpful
for understanding our special problem. Possibly its text describes not the
work of the command but only the situation when it is _not_ needed.
Maybe GRUB is not running in "normal" mode, or maybe grub_platform updates the
variable, which is set at initialization time in grub-core/normal/main.c
from macro GRUB_PLATFORM:
The variable platform is set in the same file, either from option
--with-platform or from automatic detection
# Guess the platform if not specified.
if test "x$with_platform" = x; then
case "$target_cpu"-"$target_vendor" in
... x86_64-apple) platform=efi ;;
x86_64-*) platform=pc ;;
...
So i'd assume that if /boot/grub/grub.cfg expects the possibility to see
"efi", then GRUB would have to be compiled with --with-platform=efi .
Meanwhile the GRUB in Ubuntu ISOs serves both, EFI and legacy BIOS.
I wonder how this is supposed to play with the compile time setting.
There is a compile time variable GRUB_PLATFORMS: https://wiki.gentoo.org/wiki/GRUB2_Quick_Start#Installing_GRUB2_software
"To install GRUB2, first set the GRUB_PLATFORMS variable with one or more
appropriate values in the system's make.conf. If unset, GRUB2 will guess
which platform to use on the system. It guesses pc (which is the MBR
style of installation) for x86/amd64 architectures."
But the relation of the single value GRUB_PLATFORM and the value list in
GRUB_PLATFORMS is not clear to me.
So this could want to say that each GRUB can serve in normal mode only one
platform. But the ISO wants to serve two of them. That would be a reason
not to run GRUB in normal mode.
In 2012 Vladimir Serbinko, then maintainer of GRUB, surely expected that
the ISO produced by grub-mkrescue can boot on "efi" and "pc" alike.
We discussed how xorriso should combine MBR boot code and GPT in one ISO.
:End of red herring warning.
--------------------------------------------------------------------------
Hi,
Chris Guiver wrote:
> Delay occurs regardless of ISO being written using mkusb, dd, or gnome-
> disks..
Hmm. IIRC mkusb offers to unpack the ISO into a filesystem of the USB stick.
If the problem survives that conversion, then it is far inside the GRUB
equipment.
It should be possible to make experimental changes with the .cfg files of
such an USB stick.
(I can propose xorriso runs which repack an ISO to bear new .cfg content
and the same boot entry points as the original ISO. But directly editing
in a FAT filesystem would be much more straightforward.)
Being curious i looked into ubuntu- 20.10-desktop- amd64.iso for occurences
of grub_platform and found in /boot/grub/grub.cfg
grub_platform
if [ "$grub_platform" = "efi" ]; then
menuentry 'Boot from next volume' {
exit
}
It could be that the complaint of GRUB is about the command grub_platform,
not about the use of $grub_platform.
I fail to find the implementation of the command in a freshly pulled GRUB git. command( ) with their
(Other known commands have a call to grub_register_
name as argument. grub_platform has not.)
A first experiment would be to remove above snippet from grub.cfg and
to check whether its presence caused the long delay.
------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ----
Red herring warning:
The documentation about "normal" mode and grub_platform might be not helpful
for understanding our special problem. Possibly its text describes not the
work of the command but only the situation when it is _not_ needed.
Maybe GRUB is not running in "normal" mode, or maybe grub_platform updates the normal/ main.c
variable, which is set at initialization time in grub-core/
from macro GRUB_PLATFORM:
GRUB_ MOD_INIT( normal)
{
...
grub_env_set ("grub_platform", GRUB_PLATFORM);
...
That macro seems to be set by the compile time configuration of GRUB in
./configure which is supposed to stem from configure.ac
GRUB_ PLATFORM= "${platform} " SUBST(GRUB_ PLATFORM)
...
AC_
The variable platform is set in the same file, either from option
--with-platform or from automatic detection
# Guess the platform if not specified. cpu"-"$ target_ vendor" in
x86_64- apple) platform=efi ;;
if test "x$with_platform" = x; then
case "$target_
...
x86_64-*) platform=pc ;;
...
So i'd assume that if /boot/grub/grub.cfg expects the possibility to see
"efi", then GRUB would have to be compiled with --with-platform=efi .
Meanwhile the GRUB in Ubuntu ISOs serves both, EFI and legacy BIOS.
I wonder how this is supposed to play with the compile time setting.
There is a compile time variable GRUB_PLATFORMS: /wiki.gentoo. org/wiki/ GRUB2_Quick_ Start#Installin g_GRUB2_ software
https:/
"To install GRUB2, first set the GRUB_PLATFORMS variable with one or more
appropriate values in the system's make.conf. If unset, GRUB2 will guess
which platform to use on the system. It guesses pc (which is the MBR
style of installation) for x86/amd64 architectures."
But the relation of the single value GRUB_PLATFORM and the value list in
GRUB_PLATFORMS is not clear to me.
The GRUB manual talks in singular, not in plural: /www.gnu. org/software/ grub/manual/ grub/grub. html#grub_ 005fplatform
https:/
"In normal mode (see normal), GRUB sets the ‘grub_platform’ variable to
the platform for which GRUB was built (e.g. ‘pc’ or ‘efi’).
So this could want to say that each GRUB can serve in normal mode only one
platform. But the ISO wants to serve two of them. That would be a reason
not to run GRUB in normal mode.
In 2012 Vladimir Serbinko, then maintainer of GRUB, surely expected that
the ISO produced by grub-mkrescue can boot on "efi" and "pc" alike.
We discussed how xorriso should combine MBR boot code and GPT in one ISO.
:End of red herring warning. ------- ------- ------- ------- ------- ------- ------- ------- ------- ----
-------
Have a nice day :)
Thomas