Andrew Lukoshko c8c5692035 Re-disable ppc64le arch_supports_boot_order; add BOOTFROM=d -> -boot once=d opt-in ... 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).		2026-04-29 18:05:55 +02:00
SOURCES	Re-disable ppc64le arch_supports_boot_order; add BOOTFROM=d -> -boot once=d opt-in	2026-04-29 18:05:55 +02:00
SPECS	Re-disable ppc64le arch_supports_boot_order; add BOOTFROM=d -> -boot once=d opt-in	2026-04-29 18:05:55 +02:00
.gitignore	Update to 6c17e240815aea1d0b417bf0f334c7ad4c0c9e00	2023-07-31 13:54:42 +03:00
.os-autoinst.metadata	Update to 6c17e240815aea1d0b417bf0f334c7ad4c0c9e00	2023-07-31 13:54:42 +03:00