Verified test-perl-testsuite passing on AlmaLinux 9 x86_64:
- qemu.pm: fall back to /usr/libexec/qemu-kvm when QEMU is set (RHEL ships
no /usr/bin/qemu-system-<arch>), and use /usr/share/qemu-kvm as the qemu
datadir (RHEL path) for KERNEL/INITRD/ipxe lookups.
- sshVirtsh.pm: pass '' instead of undef to setAttribute (EL9 XML::LibXML
warns on undef), preserving the previous empty-attribute output.
- BuildRequires glibc-langpack-en so the full-stack/isotovideo tests have
the en_US.UTF-8 locale.
- Rebase ppc64le QEMU backend support onto upstream v5: keep boot-order
generation off on pseries (avoids the SLOF once=d trap), add BOOTFROM=d
one-shot CD boot opt-in, and skip audio on ppc64le (EL9 QEMU has no
audio device model). Verified against EL9 qemu-kvm 10.1.
- Drop obsolete multifd patch (implemented upstream, auto-enabled for
QEMU >= 9.1) and the old combined AArch64/ppc64le patch.
- Carry Fedora backports: script_run serial marker (PR #2952) and
qemu 11 linuxboot.bin test fix (PR #2953).
QEMU spapr (SLOF) does NOT honor -boot once=d as a true one-shot: SLOF
caches the chosen boot device in spapr-NVRAM, so the post-install
reboot loops back into the installer (E3405: No such device at scsi@8:1
once anaconda has finished using the CD). The previous patch (commit
58f6db9) dropped the arch_supports_boot_order=0 line from this patch
to fix install tests that supply both an ISO and a populated HDD_1
(install_resize_lvm), but it broke the default install_default
post-install reboot.
Switch to a model that handles both cases:
- Default ppc64le: arch_supports_boot_order = 0. No -boot args at all.
Empty HDD falls through to the installer CD on first boot; populated
HDD boots its own bootloader on subsequent boots. Matches AL9 behavior.
- ISO + populated HDD_1 needing CD-first (install_resize_lvm): test
sets BOOTFROM=d. The patch translates this into -boot once=d *and*
clears $bootfrom so Proc::configure_blockdevs() does NOT assign a
persistent bootindex(0) to the CD. once=d is the only boot flag
whose effect doesn't outlive the first guest boot in this setup,
giving us 'CD wins first boot, default order on second boot'.
The companion fix for the AL10 anaconda-40.22 NVRAM-write regression
lives in os-autoinst-distri-almalinux's _boot_to_anaconda.pm
(inst.leavebootorder).
Replace 0001-Add-AArch64-and-ppc64le-support-to-QEMU-backend.patch with
0001-Add-AArch64-ppc64le-s390x-support.patch. Keeps the existing AArch64
and ppc64le tweaks (including the ppc64le arch_supports_boot_order fix
from -4) and adds s390x:
- virtio-keyboard for s390x and ppc64le (via $use_virtio_kbd)
- virtio-rng (CCW) instead of virtio-rng-pci on s390x
- virtio-tablet + no usb-tablet on s390x and ppc64le
- Gate audio and floppy devices out on s390x as well
- PXE bootindex=$i on NIC devices when PXEBOOT is set
- BOOTFROM=n/net parsing for network boot
- virtio-gpu added to EDID-capable device list
- Drop unused save_storage_drives sub
- Default _serialdev=ttysclp0 when ARCH=s390x + BACKEND=qemu
Verified against upstream tarball 6c17e24 (the commit our Version pins):
$ patch -p1 --dry-run
patching file 'backend/qemu.pm'
patching file testapi.pm
No fuzz, no offsets.
QEMU spapr/pseries honors -boot once=d / order=, so leaving
$arch_supports_boot_order disabled on ppc64le made install tests
that supply both an ISO and an HDD_1 boot the HDD instead of the
installer CD (same symptom as running x86_64 without -boot). Drop
that line from the patch so ppc64le behaves like x86_64.
Patch description updated to record the history; hunk shrinks by
one line and the patch diffstat updates accordingly.
Patch by Elkhan Mammadli <elkhan.mammadli@protonmail.com>. Adjusts the
QEMU backend for the QEMU build shipped in Enterprise Linux on AArch64
and ppc64le: use qemu-xhci on AArch64, wire virtio keyboard/tablet on
ppc64le, disable audio, and skip unsupported boot-order and floppy
handling.
