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?
Ok I can reproduce
One sees just quickly the bootloader flying by: 0x0)/Pci( 0x4,0x0) /Sata(0x0, 0xFFFF, 0x0) 0x0)/Pci( 0x4,0x0) /Sata(0x0, 0xFFFF, 0x0)
BdsDxe: loading Boot0001 "UEFI QEMU HARDDISK QM00005 " from
PciRoot(
BdsDxe: starting Boot0001 "UEFI QEMU HARDDISK QM00005 " from
PciRoot(
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: >/usr/share/ OVMF/OVMF_ CODE.fd< /loader> '/usr/share/ OVMF/OVMF_ VARS.fd' />
<loader readonly='yes' type='pflash'
<nvram template=
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. 0x0)/Pci( 0x2,0x3) /Pci(0x0, 0x0) 0x0)/Pci( 0x2,0x3) /Pci(0x0, 0x0)
BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(
BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(
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?