Comment 61 for bug 1797581

Ran with:
- the cloud-image of Xenial of 20190419 [1]
- XML with a memory definition of:
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
- kernel&initrd are from the host
   <kernel>/var/lib/libvirt/images/bug-1797581-bionic-base</kernel>
   <initrd>/var/lib/libvirt/images/bug-1797581-bad-initrd</initrd>
- The attached broken initrd of comment #56
- Otherwise it is a uvtool kvm guest as it is created on Bionic
- Host is Bionic
- different kernels:
  - xenial
  - xenial hwe
  - bionic
  - bionic-hwe

Actually after above yielded no useful results I decided to even exclude libvirt from the equation for now (we don't even need a disk, just need to know if the kernel can extract the initrd):

$ sudo qemu-system-x86_64 -enable-kvm -m 2048M -nographic -serial mon:stdio -append 'console=ttyS0' -kernel bug-1797581-bionic-hwe -initrd bug-1797581-bad-initrd

All kernels loaded the attached broken initrd just fine.
:-/ no repro yet

@Dmitrii:
- in the past we were unsure if this padding would be mangled by bootloaders, tfp or anything like it. Do you reproduce that locally or through maas still?
- The ramdisk that you attached is bionic it seems - is that correct?
- Please test the same without a disk, it should not matter and saves a lot of space when attaching files here.
- Would you mind attaching the full set of a broken case (kernel+initrd+xml)
- report the full commandline that the broken boot called qemu with?
- If you run this in maas or libvirt still, would you mind to step by step check if the same occurs
  a) without maas (only in libvirt)
  b) without libvirt (probably check which args e.g. -m it exactly passes to qemu)

[1]: https://cloud-images.ubuntu.com/xenial/20190419/xenial-server-cloudimg-amd64-disk1.img