Better support when target arch is non-native

[hadess]

When forcing the aarch64 architecture (for example) on a non-aarch64, lorax could do a number of things better:

• disable KVM
• pass a valid -machine qemu argument (-machine virt-3.1 for example)
• Disable virtio usage for the serial port, or use something equivalent
• Disable virtio usage for the RNG (--with-rng none)

Edit: virtio works fine, it didn't with another -machine I had originally selected

[hadess]

• Enable UEFI automatically
• Don't force a machine type incompatible with the target arch (maybe virt rather than q35)
• Fix default ovmf-path in src/pylorax/cmdline.py (should be /usr/share/edk2/aarch64/ but as the filenames are also different, maybe it should be a new command-line option?)

[bcl]

I can't enable UEFI automatically, you may want to build a bios image from a uefi system or visa versa.
On x86 I'm pretty sure the machine type for UEFI needs to be q35.
The ovmf path will probably need to be pulled from an arch:path mapping since it's different, and you can install flash for multiple arches so it can't just be auto-detected.

Thanks for looking at this, it certainly needs a bunch of work.

[hadess]

It's probably more complicated than the different steps I listed, and not being a maintainer of that code, it's pretty hard to know how the changes should be made, but at the very minimum, there needs to be a piece of code that handles the target arch not being the same as the native one.

One which native platforms has the livemedia-creator already been successfully tested, and for which non-native targets does it already work?

Adding "armhfp" support might be a good first pass, as it doesn't require UEFI, and would require disabling virt on x86_64 but not on aarch64. When that works, and if we figure out how qemu aarch64 is supposed to start, then add support for that.

[Be-ing]

I'm trying to use livemedia-creator to create an aarch64 UEFI raw image for my Pinephone Pro from my x86-64 laptop. It seems I am running into this issue:

root@localhost-live /h/b/ppp-images# livemedia-creator --make-disk --arch=aarch64 --ks=fedora-disk-base.ks --iso boot.iso --image-type=raw
2022-01-29 19:11:49,026: livemedia-creator v35.9-1
2022-01-29 19:11:49,026: selinux is enabled and in Enforcing mode
2022-01-29 19:11:49,085: disk_img = /var/tmp/lmc-disk-eez9lzxm.img
2022-01-29 19:11:49,085: Using disk size of 2MiB
2022-01-29 19:11:49,085: install_log = /home/be/ppp-images/virt-install.log
2022-01-29 19:11:49,176: qemu vnc=127.0.0.1:0
2022-01-29 19:11:49,176: Running qemu
2022-01-29 19:11:49,202: Running qemu failed:
2022-01-29 19:11:49,202: cmd: qemu-system-aarch64 -no-user-config -m 2048 -machine accel=kvm -kernel /var/tmp/lorax.imgutils.w9764e8k/images/pxeboot/vmlinuz -initrd /var/tmp/lmc-initrd-w3jehtqg.img -drive file=/var/tmp/lmc-disk-eez9lzxm.img,cache=unsafe,discard=unmap,format=raw -drive file=/home/be/ppp-images/boot.iso,media=cdrom,readonly=on -append inst.ks=file:/fedora-disk-base.ks inst.stage2=hd:LABEL=Fedora-E-dvd-aarch64-35 inst.text inst.cmdline -nographic -monitor none -serial null -display vnc=127.0.0.1:0 -device virtio-serial-pci,id=virtio-serial0 -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.fedoraproject.anaconda.log.0 -chardev socket,id=charchannel0,host=127.0.0.1,port=59459 -object rng-random,id=virtio-rng0,filename=/dev/random -device virtio-rng-pci,rng=virtio-rng0,id=rng0,bus=pci.0,addr=0x9
2022-01-29 19:11:49,202: output: qemu-system-aarch64: No machine specified, and there is no default
Use -machine help to list supported machines

2022-01-29 19:11:49,214: VirtualInstall failed: QEMUInstall failed
2022-01-29 19:11:49,214: unmounting the iso
2022-01-29 19:11:49,231: Install failed: QEMUInstall failed
2022-01-29 19:11:49,231: Removing bad disk image
2022-01-29 19:11:49,231: ERROR: Image creation failed: QEMUInstall failed
2022-01-29 19:11:49,233: Image creation failed: QEMUInstall failed

Can you suggest any workaround? Do I need to dig into the code to fix this myself?

[bcl]

Can you suggest any workaround? Do I need to dig into the code to fix this myself?

Take a look at PR #1108 which may help. I just haven't had any time to work on cross-arch support, sorry.