arm64 cloud-image always falls back on 30second grub boot

[Anisse Astier]

It seems that the grub.cfg generated in the cloud images always falls back to the mode where it waits 30 seconds to boot when passing the root as a virtio block device.

If I'm reading the grub.cfg correctly, it might be because it first boots without an initird, then the kernel panics because it can't mount the root device, then on the next boot recordfail = 1 so the timeout is set at 30.

The possible solutions I see:
 - wait for the first boot with an initird before setting the timeout at 30s (more complex state machine if first boot should absolutely be without initird)
 - put virtio-blk as builtin, although it was requested to be configured as module 3 years ago in this bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1637303

This can be reproduced with the script below:

#!/bin/bash
# supposes you have installed qemu-efi-aarch64, qemu-system-arm and genisoimage
set -euo pipefail

IMG=eoan-server-cloudimg-arm64.img
CLOUDINIT=./cloudinit.iso

wget -O "$IMG" https://cloud-images.ubuntu.com/eoan/current/eoan-server-cloudimg-arm64.img
echo -e '#cloud-config\nsystem_info:\n default_user:\n name: qemu\npassword: qemu\nchpasswd: { expire: False }\nssh_pwauth: True\n' > user-data
echo "local-hostname: qemu-machine" > meta-data
genisoimage -quiet -input-charset utf-8 -output "$CLOUDINIT" -volid cidata -joliet -rock user-data meta-data
rm -f user-data meta-data

qemu-system-aarch64 -machine virt -m 768 -cpu cortex-a72 -smp 2 -accel tcg,thread=multi -nographic -nodefaults \
 -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd \
 -drive "index=0,media=disk,id=disk0,if=none,file=$IMG" -device virtio-blk,drive=disk0 \
 -device virtio-scsi-pci,id=scsi0 -drive "file=$CLOUDINIT,if=none,driver=raw,readonly=on,id=cdrom1" -device scsi-cd,bus=scsi0.0,drive=cdrom1 \
 -serial mon:stdio

[Anisse Astier (anisse)]

This seems solved in groovy. I wouldn't mind a backport to focal's LTS though.