Hello list,
There is an issue currently impacting the start times of grub. When grub
is starting in a UEFI environment there are certain scenarios where it
could take multiple minutes for grub to show the grub menu. The reason
is that during initialization when invoking the function
"grub_efidisk_read" in disk/efi/efidisk.c, the EFI read calls take a
long time to return (sometimes multiple minutes) when trying to read
sectors from certain disks. In the scenario I've seen I was manually
triggering a Downstream Port Containment (DPC) from the UEFI shell which
was disabling one of the drives (The operating system is NOT on this
drive) and so when grub iterates through the disks during its startup,
it it would hang waiting for the EFI firmware to respond and eventually
receives an error from the firmware telling it that the read operation
failed. Grub eventually is able to get to the grub menu but with a big
delay (around 10 minutes) and is able to boot the operating system just
fine.
From my testing grub is trying to read multiple sectors from the same
disk with each read operation taking over 2 minutes to complete.
This scenario should be reproducible in any case that would lead the
firmware to hang on a read operation. In theory it can be a disk that is
dying, buggy firmware, an NVME drive hit by DPC like in this case, etc.
The question on my mind is if this is something that grub should somehow
handle (i.e having firmware calls taking a long time to return) or leave
it as is and put the responsibility on the firmware to be more timely
and respond sooner with an error code?
Thanks.
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
