arm64 cloud-image always falls back on 30second grub boot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-images |
New
|
Undecided
|
Unassigned |
Bug Description
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:/
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-
CLOUDINIT=
wget -O "$IMG" https:/
echo -e '#cloud-
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/
-drive "index=
-device virtio-
-serial mon:stdio
This seems solved in groovy. I wouldn't mind a backport to focal's LTS though.