photon-os-installer: upgrade to v2.9

[dcasota]

Puts the current upstream installer on the media. This is the change that makes an "installer latest" ISO possible — today the media always carries 2.8 regardless of what the ISO builder container runs.

The constellation

A single Photon ISO already spans two installer versions, in two different roles:

builder container   git clone --depth 1 vmware/photon-os-installer (master)   -> BUILDS the ISO
media RPM           SPECS/photon-os-installer, Version: 2.8                   -> INSTALLS from it

So "2.8 vs latest" was never selectable by a build flag. Getting latest onto the media requires exactly this: a spec version bump. Upstream released v2.9 on 2026-06-09 while 5.0 stayed pinned at 2.8.

The practical cost of the drift: three downstream patches carried here had already landed upstream and were being re-applied to code that no longer needed them.

Which patches survive, and how that was decided

Not by reading PR titles — each patch was tested against the real v2.9 tree in both directions. Applying forward means still needed; reversing cleanly means already upstream.

Patch	v2.9	Action
0001-Use-mkpasswd-to-generate-password-hash	reverses cleanly	dropped
0002-fix-up-old-public_key-syntax-for-backward-compat	applies forward	kept
0006-stig-drop-redundant-packages	applies forward	kept
0007-installer-seed-locale.conf-before-package-install	applies forward	kept
0008-isoBuilder-put-installer-requestable-packages-on-media	not present in v2.9	added

0003-isoInstaller-fix-interactive-NoneType-crash, 0004-installer-add-btrfs-progs and 0005-tdnf-capture-install-output are also in v2.9 (upstream PRs #45, #42, #46), so they are not carried forward either — confirmed the same way, against v2.9's actual content.

0008 — added, because v2.9 does not carry it

v2.9's isoBuilder.py has no KS_STIG_PACKAGES import, so the poi=latest media has the same defect 2.8 had: selecting "Apply STIG hardening" asks for the STIG package set at install time, and if those RPMs are not in the ISO's own RPMS/ the install aborts with Error(1011) : No matching packages.

Carrying it here keeps the two variants equivalent on that axis — otherwise the poi=latest permutations would silently lose a fix the 2.8 ones have. Applies to v2.9 with a one-line offset. This is dcasota/photon-os-installer#11.

Source metadata — computed, not copied

Field	Value
archive_sha512sum	6fce11f895350b44…52a2c6, computed over the downloaded v2.9 archive
commit_id	59a011da9f32b4a983be0737027d951d5dfca968 (tag v2.9, dereferenced to a commit)
url	…/archive/refs/tags/v2.9.tar.gz
license-review paths	rebased photon-os-installer-2.8/ → -2.9/

Seven of the eight reviewed license files hash identically to 2.8; only photon-os-installer.spec changes, because it carries the version. Method sanity-checked by confirming the recorded 2.8 hash matches the 2.8 tarball on disk byte for byte.

Testing

All kept patches applied to the real v2.9 tarball, in rpm's order and at rpm's strictness (--fuzz=0 — plain patch defaults to fuzz 2 and is therefore a weaker check than the build performs):

0002-fix-up-old-public_key-syntax-for-backward-compatibil.patch  OK
0006-stig-drop-redundant-packages.patch                          OK
0007-installer-seed-locale.conf-before-package-install.patch     OK
0008-isoBuilder-put-installer-requestable-packages-on-media.patch OK

0002 is rebased onto the v2.9 context: v2.9 inserts a grub-password block between the anchor line and _check_install_config, so the hunk's trailing context no longer matches exactly. The change itself is still required — v2.9 has no public_key backward-compatibility handling of its own.

Resulting tree: KS_STIG_PACKAGES reduced to 5 entries, locale.conf seeded in _initialize_system(), and py_compile clean on both touched modules.

rpmspec yields photon-os-installer-2.9-3.ph5 at subrelease 91 and 92, with all three patches expanded into %prep. support/spec-checker/check_spec.py exits 0 — including its config.yaml/spec source cross-check, which is what validates the new metadata.

Relationship to #19

These two are alternatives — take one, not both. #19 keeps 2.8 and adds patches 0003-0007 to it. This PR moves to 2.9, where 0003/0004/0005 are redundant, and carries only 0002/0006/0007. Merging #19 first is fine; this PR would then need a trivial rebase to drop the files #19 added that v2.9 already has.

The patch list is also switched to unnumbered Patch:, so dropping an upstreamed patch can never leave an index gap or collision — the same failure mode fixed in #22/#23.

[legal-compliance-bot]

🛑 Legal Compliance Check Failed

Hi @dcasota, thank you for your contribution!

To merge this Pull Request, you must sign our DCO.

Note: Even if you signed off your commits locally (using git commit -s), you must post the comment below to register your signature with our automated system.
Note: This is a one-time process. Once signed, future contributions to this repository will be verified automatically.

1. Read the Document: Click here to read the DCO
2. Sign via Comment: Copy and paste the exact line below into a new comment on this Pull Request:

I have read the DCO Document and I hereby sign the DCO for this and all future contributions.

---

⏳ Processing Schedule:
Our 'Compliance Sweeper' runs automatically approximately every 15-20 minutes.
After you post the comment, your status will update automatically during the next scheduled run.
You do not need to take any further action.

[dcasota]

I have read the DCO Document and I hereby sign the DCO for this and all future contributions.