Comment 5 for bug 1875012

Ok I can reproduce

One sees just quickly the bootloader flying by:
  BdsDxe: loading Boot0001 "UEFI QEMU HARDDISK QM00005 " from
  PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0)
  BdsDxe: starting Boot0001 "UEFI QEMU HARDDISK QM00005 " from
  PciRoot(0x0)/Pci(0x4,0x0)/Sata(0x0,0xFFFF,0x0)
  error: no such device: ubuntu-boot.
... and then it crashes.

I was probing the major conditions to trigger - it seems to be only happening with the efi / ovmf boot.

Changing the machine= or cpu model= had no impact, neither had a i440fx/q35 change.
But dropping from Efi to the default loader avoided the crash. There it also only worked to some extend - I mean it starts and does not crash. But the guest seems to insist/require UEFI as it doesn't go much further. I first thought the ovmf build might have a similar problem to what we have had in seabios, but then I tested non UC20.

I also wanted to know if there is anything special in the UC20 image that is needed to trigger this and therefore booted a cloud image with OVMF.

So I took a usual cloud-image based focal guest and added:
  <loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>
  <nvram template='/usr/share/OVMF/OVMF_VARS.fd'/>

And that works like a charm. So the issues seems to be triggered by something set up int hat UC20 image that you linked. It must do/trigger something that a cloud-image would not do on the same setup.

The early boot messages differ - but that might be a red herring.
BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0)
BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x3)/Pci(0x0,0x0)
error: can't find command `hwmatch'.

I don't even see the UC20 kernel initializing.
The next step is to know/learn what this image does differently.
How is this UC20 image special, what does it do special on init that other images don't do?
@Juergh do you now or do we need to reach out to mvo and others?