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).
Andrew Lukoshko
c8c5692035