Alternative zum Docker/Linux-Tool: nutzt softwareupdate --fetch-full-installer
+ createinstallmedia direkt, wenn ein Mac (10.15+) verfuegbar ist. Bewusst
unabhaengig vom ./downloads-Ordner, da createinstallmedia die volle
Install-App braucht, nicht die rohen Katalog-Images des Docker-Pfads.
Reines Terminal-Menue ohne externe Abhaengigkeiten (softwareupdate, diskutil,
PlistBuddy). Zukunftssicher analog zum Docker-Tool, da Apples eigene
Versionsliste live abgefragt wird.
- GUI: dritter Modus-Umschalter, Checkbox-Mehrfachauswahl statt Single-Select
- Backend: sgdisk partitioniert den Stick in N Apple_HFS-Partitionen (Typ AF00),
jede mit Label = macOS-Titel/Version, jede bekommt ihr eigenes Installer-Image
per dd -- Macs EFI-Bootpicker (Alt/Option) zeigt alle Partitionen zur Auswahl
- Groessen-Check VOR dem Schreiben: bricht mit klarer Fehlermeldung ab wenn der
Stick zu klein ist, statt mittendrin zu scheitern
- Dockerfile: parted (partprobe) ergaenzt
- End-to-end gegen ein echtes Loop-Device verifiziert: sgdisk legt korrekte
Partitionen mit Labels an, dd schreibt in die richtige Partition, Inhalt
stimmt exakt ueberein (nicht nur behauptet)
- README: neuer Abschnitt 4 (Funktionsweise, Ablauf, ehrliche Grenzen),
Multiboot als experimentell markiert (erbt recovery-Pfad-Unsicherheit bei
Big Sur+, kein echter Mac-Boot-Test bisher durchgefuehrt)
Neuer Modus in der GUI: Image nur herunterladen und dauerhaft unter
./downloads/library/ ablegen, ohne USB-Stick. Baut sich so vorab eine
komplette Offline-Sammlung aller macOS-Versionen auf (z.B. auf externe
Platte kopierbar). Stick-Jobs pruefen jetzt IMMER zuerst die lokale
Bibliothek und ueberspringen den Download bei Treffer -- jeder normale
Stick-Bau traegt so nebenbei zur Bibliothek bei.
Backend: installer.py bekommt job_type (stick|download), persistente
Downloads in library/<name>/ mit meta.json + atomarem .part-Rename,
neue /api/library. Frontend: Modus-Umschalter, Bibliotheks-Status,
Offline-Badges in der Versionsliste.
Live getestet auf aria-wohnung: Container neu gebaut, Katalog laedt 37
Installer, Download-Job End-to-End ueber die echte API (Cache-Miss dann
Cache-Hit verifiziert), Stick-Job-Validierung weiterhin intakt.
- Dockerfile: hfsprogs-Sources per sed auf bestehende deb822-Datei
patchen statt zweite sources.list-Datei (Signed-By-Konflikt)
- Dockerfile: xar configure.ac OpenSSL-Probe auf EVP_EncryptInit
umbiegen (OpenSSL_add_all_ciphers ist in OpenSSL 3.x nur noch Makro)
- Dockerfile: xar vor pbzx bauen (Linker-Abhaengigkeit), pbzx-Quelle auf
NiklasRosenstein/pbzx (mackyle/pbzx existiert nicht mehr)
- catalog.py: doppeltes gzip.decompress auf bereits von requests
dekomprimierten Content entfernt
- catalog.py: Big-Sur-bis-Tahoe-Installer wurden durch veralteten
OSInstall-Filter komplett verworfen, jetzt SharedSupport-Schema
ebenfalls erkannt (37 statt 13 gefundene Installer)
Alles live gegen echten docker compose build/up + echten Apple-Katalog
verifiziert, nicht nur behauptet.
hfsprogs liegt in Debians non-free-Repo (bookworm-slim aktiviert nur main),
xar existiert in bookworm ueberhaupt nicht als Paket. non-free per eigener
sources.list.d aktiviert, xar aus dem mackyle-Upstream (gleicher Maintainer
wie das bereits genutzte pbzx) selbst gebaut.
ARIA