When booting `lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img` on Debian 13 ARM `libvirt` at some point I face:
``` BdsDxe: loading Boot0001 "UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:01.2:00.0-1" from PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/USB(0x0,0x0) BdsDxe: starting Boot0001 "UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:01.2:00.0-1" from PciRoot(0x0)/Pci(0x1,0x2)/Pci(0x0,0x0)/USB(0x0,0x0) error: no such device: PERSIST. error: file `/grubenv_abootctrl' not found. ```
How to solve this issue?
Aug 13, 8:50pm
The error you're encountering:
text
error: no such device: PERSIST.
error: file `/grubenv_abootctrl' not found.
is not uncommon when booting Android-x86 or LineageOS images in a virtualized environment like libvirt on ARM64. This issue typically arises because the image expects certain UEFI/GRUB configurations or device paths that are either missing or misconfigured in your virtual machine setup.
Root Causes
Missing or Incorrect Bootloader Configuration
The image is trying to access /grubenv_abootctrl, a file used by Android-x86's GRUB-based bootloader to manage boot entries (e.g., for A/B slot switching). This file is either:
Not present in the image.
Not accessible due to incorrect UEFI boot order or device mapping in libvirt.
UEFI Firmware Compatibility
The QEMU UEFI firmware (edk2) used by libvirt may not fully support the bootloader logic expected by LineageOS for ARM64.
Storage Device Not Detected
The error no such device: PERSIST suggests the system cannot find the persistent storage partition (often used for /data or bootloader state in Android-x86).
ARM64-Specific Quirks
LineageOS for ARM64 (especially in a virtualized environment) may have unofficial or experimental support, leading to bootloader issues.
Solutions to Try
1. Check the Image's Bootloader
Verify if the image has a GRUB configuration:
Mount the image and check if /grubenv_abootctrl exists:
bash
sudo mount -o loop,offset=$((512*2048)) lineage-22.1-20250202-UNOFFICIAL-virtio_arm64only.img /mnt
ls /mnt/grubenv_abootctrl
If missing, the image may be corrupt or incomplete.
If present, the issue is likely UEFI boot order or device visibility.
2. Modify the Libvirt XML for UEFI Boot
Your libvirt domain XML should explicitly define:
UEFI firmware (OVMF for ARM64).
Correct boot order (prioritize the virtual disk over USB).