Self-heal: driver fallback chain, repatch-time glibc gate, boot failsafe

[mrcgibb9876-hash]

Harden the self-heal path against an OS update staging a slot whose kernel the pinned driver cannot build against.

• --driver PREF (pinned|latest|) selects which driver a repatch reaches for, and repatch now walks pref -> latest -> last known-good instead of dying on the first failure. driver.conf is rewritten with the set that actually built, so the fallback floor tracks a proven driver. Candidate resolution requires all nvidia packages to share nvidia-utils' pkgver so a mid-bump archive is skipped.
• Run the glibc gate at repatch time, not just build time: a newer driver than the one vetted at build time can need newer glibc than the slot ships, and the kernel module never links glibc, so it would build fine and black-screen on Arch-compiled userspace. Rejection falls through to the next candidate. Adds binutils to the chroot for readelf.
• Boot failsafe unit: if a boot has no nvidia module, verify the other slot does, then mark this image invalid and reboot back to it. One-shot stamp on /home prevents a bootloop; with nowhere safe to go it starts sshd and stays up. Kept across updates via atomic-update.conf.d and reinstalled into the staged slot by repatch.
• repatch.sh force rebuilds even when a module is present.
• Preflight checks for DRIVER_PREF, failsafe.sh, and the enabled unit.
• README: document --driver and the failsafe.

[Temporalwar]

I would like to propose adding native SATA support as a default feature. Currently, the official SteamOS installer is optimized for NVMe drives (nvme0n1), requiring users to manually modify the installation scripts and partition the target drive to utilize SATA SSDs or HDDs.

To facilitate SATA installation, the process currently requires manually unmounting and formatting the drive via KDE Partition Manager and modifying the repair_device.sh script to point to the correct SATA identifier (e.g., /dev/sda). Incorporating native support for these drives would significantly streamline the installation experience for users with SATA-based hardware.

[28allday]

Thanks for this — it's thoughtful hardening, and sorry it's sat a while. Status update and a proposal:

The --driver selection half of this collided with history: the repo independently shipped --driver SPEC (latest or a version/branch prefix, pinned to archive.archlinux.org) the same week, so this PR is now conflicting with main. On the repatch philosophy the shipped design deliberately keeps repatch pinned to the build-time driver set for reproducibility — a fallback chain that silently lands a different driver than the one the user chose is a behaviour change we'd want opt-in rather than default.

The parts of this PR that are still very much wanted on top of current main:

1. The repatch-time glibc gate — the build-time gate genuinely doesn't cover a repatch pulling packages onto an older slot; running the same ELF scan in repatch (falling back to cancel the update rather than to a different driver, keeping fail-safe semantics) closes a real black-screen hole.
2. The boot failsafe unit — no-nvidia-module boot → verify other slot → mark invalid → reboot back, with the bootloop stamp and the sshd last-resort. This is a great safety net independent of driver selection.
3. repatch.sh <partset> force — cheap and useful.

If you're up for rebasing those three onto current main (leaving driver selection to the existing --driver, with the fallback chain as an opt-in flag if you want to propose it separately), I'd be glad to review promptly this time. If you'd rather not, say so and I'll cherry-pick the ideas with credit.

[mrcgibb9876-hash]

Hi we have a new born now so not much time feel free to cherry pick anything you need! Enjoy your vids! I am on Omarchy Quattro now

[28allday]

Amazing news Kids are great ..will have a look at this properly when i get time thanks