Is it possible to have the system boot al the way up in Ubuntu server without any operator interaction (pub in a keyboard and punch enter) and have the initial connection be via SSH
I have ssh working and when I reboot or cycle power I have to plug the keyboard into my 805 to complete the boot
It should not need any operator intervention. By default GRUB has a 30 second timeout if boot failure is triggered. Look at the GRUB recordfail mechanism.
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.
Some devices will send a keystroke on enumeration and interrupt normal GRUB startup. The other issue is if grub recordfail mechanism is triggered by a bad boot.
This is an issue with those devices since they are not suppose to send any keys.
INCREDIBLE - Was struggling with this same issue for several hours (this is my first dip into SBCs) - saw this and removed keyboard and mouse, reboot was less than 30 seconds! THANKS
I have a similar issue. The last thing is 'Booting /eft/boot/bootaa64.efi and it just hangs for a very long time. Never says welcome to GRUB. No USB connected or ethernet. It does also say “starting USB… minimal bash-like line editing is supported…” and I have some usb mount points configured. But absence of those devices should not stop boot. It doesn’t appear to ever finish boot.
Double check your power and MicroSD card. After booting bootaa64.efi (GRUB), it should show a menu on HDMI for 1 second and then proceed to boot Linux.