I’m getting similar, if I press any key or wait 10+ minutes, it continues to boot.
It gets to “Booting /efi\boot\bootaa64.efi” and hangs for 1-3 minutes before going to a blank screen. If I press any key after it’s sat on “Booting /efi\boot\bootaa64.efi” for 10-15, it will continue to the blank screen sooner, sometimes briefly flashing the grub menu first.
It’ll sit on blank for 5-10 minutes before continuing to boot. Pressing any key will make it move on sooner.
I have tried all 3 22.04 image types across 3 different microSD cards. The strange part is that first boot of the image will boot normally, but every boot after that will exhibit this behavior.
In /etc/default/grub.d/, there’s two cfs that somewhat conflict, 50-cloudimg-settings.cfg and 60-libre-computer-settings.cfg. The first sets GRUB_RECORDFAIL_TIMEOUT and GRUB_TIMEOUT to 0, the other sets them to 2 and GRUB_TIMEOUT_STYLE=menu.
Setting both to 3 and menu, updating grub, had no effect. Deleting second cfg and letting both use the default of 0 and hidden so far as brought the delay down to around 1-2 minutes.
Edit: For anyone new to grub, you need to run sudo update-grub after altering those configs for them to take affect.
For clarity and SEO, this is all on the AML-S905X-CC Le Potato board.
Got the same with the Raspbian lite image. It hangs on Welcome to GRUB for several minutes, Then the same again on the debian11 boot screen at Loading Linux [kernal version] for even longer. After 5+ minutes it will get to loading initial ramdisk then after another minute continue to boot.
Pressing a key during these long pauses will make it continue sooner.
But unlike with those images, removing a duplicate grub config, but not conflicting on the debian image due to both cfgs being identical, there was no change in the long boot delays. Setting GRUB_RECORDFAIL_TIMEOUT=0 also had no affect.
What I did find that resolved this was unplugging the old Belkin Enterprise USB KVM I was using to control it on the work bench and attaching a keyboard directly instead. Its weird that KVM’s USB mouse/keyboard interface causes this behavior. I wonder if others seeing these delays are also getting causes by the HID devices.
Thankfully the boot issues are also resolved by not having any HID device attached as I will be running these without such. Just wish I had figured this out days ago.