Thomas Stallinger
108444ecf7
Auto-Modus (TUXFLOTTE_AUTO_MODE=true, über config/installer.conf als
exportierte Env-Var vor 05_network.sh gesetzt) überspringt alle drei
interaktiven Gates, die bei genauerem Hinsehen existierten (nicht nur
das eine ursprünglich im Plan genannte):
- 05_network.sh: nicht-interaktiver WLAN-Pfad über TUXFLOTTE_WIFI_SSID/
TUXFLOTTE_WIFI_PSK, analog zum bestehenden TUXFLOTTE_ACTIVATION_CODE-
Muster in 12_enrollment_auth.sh (unverändert, unterstützte das schon).
- 17_device_status.sh: "Provisionierung fortsetzen?"-Prompt übersprungen.
- 20_profile_selection.sh: "Vorlage auswählen?"-Prompt übersprungen,
wählt automatisch die als is_default markierte Vorlage (echter
Server-Hinweis via Enrollment Session erst mit Phase 3 möglich).
- 25_installation_confirm.sh: eigentliches Commit-Gate übersprungen.
Alle drei Auto-Modus-Zweige lokal verifiziert (Skripte direkt mit
TUXFLOTTE_AUTO_MODE=true und präparierten Eingabedateien ausgeführt,
kein Hängenbleiben an read -p, korrekte state.env/template.json-Ausgabe).
Partitionierung: installation_directives.partitioning von einfachem
String auf strukturiertes Objekt umgestellt ({"scheme": "single"|
"custom", "root_filesystem", "extra_partitions": [{"mountpoint",
"filesystem", "percent"}]}) - Vertrag, an den sich provisioning-server
in Phase 3 halten muss. backend_generate_config() baut daraus ein
partman-auto/expert_recipe (ersetzt die bisherige choose_recipe-
Fallunterscheidung mit nur "default"/"atomic"), Prozentangaben werden
anhand der realen Zieldatenträgergröße (lsblk/blockdev, erst live auf
dem Zielgerät bekannt) in feste MB-Größen umgerechnet.
Auf UEFI-Systemen wird zusätzlich eine EFI-System-Partition ins Recipe
aufgenommen (sonst verweigert/warnt der Installer, "No EFI System
Partition was found") - exakte Stanza-Syntax nicht aus der Erinnerung
geraten, sondern aus /usr/lib/partman/recipes-amd64-efi/30atomic auf
dem echten Live-Medium ausgelesen ($reusemethod{ } war der fehlende
Teil in einem ersten, geparsten aber nicht erkannten Versuch).
backend_init() installiert jetzt auch jq/envsubst(gettext-base)/cpio
bei Bedarf nach (vorbestehende Lücke neben dem schon in Phase 1
behobenen kexec-tools).
Real per QEMU verifiziert: eigene Ein-Datenträger-Erkennung musste
gehärtet werden (nbd/zram-Geräte mit Größe 0 wurden fälschlich vor dem
echten Datenträger gewählt - auf einer sauberen VM allein wäre das nicht
aufgefallen). Custom-Recipe mit ext4-Root + ext4-/home (20%) +
btrfs-/var (10%) auf 40GB-Testplatte: vollständige unbeaufsichtigte
Installation inkl. Paketinstallation durchlaufen lassen, danach von der
Festplatte (nicht der Live-CD) gebootet - Login-Bildschirm mit korrektem
Hostname erscheint, System bootet einwandfrei per UEFI/ESP.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
54 lines
2.5 KiB
Smarty
54 lines
2.5 KiB
Smarty
### Tuxflotte Auto-Install Preseed fuer Linux Mint (Ubiquity/Debian-Installer).
|
|
### Liegt direkt auf dem Medium (file=/cdrom/preseed/tuxflotte.seed), keine
|
|
### Netz-Zustellung noetig -- analog zu Fedoras inst.ks=cdrom:/ks.cfg.
|
|
###
|
|
### d-i preseed/early_command wird bewusst NICHT verwendet -- unter Ubiquity
|
|
### bestaetigt wirkungslos (Ubiquity nutzt eigene Python-Plugins statt der
|
|
### klassischen Debian-Installer-Komponenten, an die early_command haengt).
|
|
|
|
d-i debian-installer/locale string de_DE.UTF-8
|
|
d-i keyboard-configuration/xkb-keymap select de
|
|
d-i keyboard-configuration/layoutcode string de
|
|
|
|
d-i netcfg/get_hostname string ${TUXFLOTTE_HOSTNAME}
|
|
d-i netcfg/get_domain string unassigned-domain
|
|
|
|
# Lab-Bootstrap-Zugangsdaten. Ersetzt ein noch fehlendes Secret-Reference-Modell
|
|
# (siehe 09-data-model-v1.md) und darf nicht als Produktionsmechanismus gelten.
|
|
d-i passwd/user-fullname string Tuxflotte
|
|
d-i passwd/username string tuxflotte
|
|
d-i passwd/user-password password test123
|
|
d-i passwd/user-password-again password test123
|
|
d-i user-setup/allow-password-weak boolean true
|
|
|
|
d-i clock-setup/utc boolean true
|
|
d-i time/zone string Europe/Berlin
|
|
d-i clock-setup/ntp boolean true
|
|
|
|
d-i partman-auto/method string regular
|
|
d-i partman-auto/expert_recipe string ${TUXFLOTTE_PARTMAN_RECIPE}
|
|
d-i partman-auto/choose_recipe select tuxflotte
|
|
d-i partman-partitioning/confirm_write_new_label boolean true
|
|
d-i partman/choose_partition select finish
|
|
d-i partman/confirm boolean true
|
|
d-i partman/confirm_nooverwrite boolean true
|
|
|
|
ubiquity ubiquity/summary note
|
|
ubiquity ubiquity/reboot boolean true
|
|
ubiquity ubiquity/use_nonfree boolean true
|
|
|
|
# Pendant zu Fedoras kickstart.tpl %packages (ansible-core, git) - der
|
|
# Provisioning Agent braucht ansible-pull, das wiederum git zum Klonen des
|
|
# Ansible-Repos. Ohne diese Zeile fehlen beide auf einer frischen
|
|
# Mint-Installation, der Agent-Dienst laeuft dann in einer
|
|
# Restart-Fehlerschleife ("ansible-pull nicht gefunden") - real gegen eine
|
|
# frische Testinstallation gefunden und verifiziert (2026-08-04).
|
|
d-i pkgsel/include string ansible-core git
|
|
|
|
# success_command laeuft in-target (gechrootet ins Zielsystem) nach der
|
|
# Paketinstallation, vor dem Reboot - das Pendant zu Kickstarts %post. Der
|
|
# Payload ist base64-kodiert (backend_generate_config() in backend.sh baut
|
|
# ihn aus postinstall.sh): mehrzeilige/zitierte Preseed-Werte brechen unter
|
|
# Debconf lautlos, Base64 umgeht das (real erprobt, siehe wlan-test.seed).
|
|
ubiquity ubiquity/success_command string in-target bash -c 'echo ${TUXFLOTTE_POSTINSTALL_B64} | base64 -d | bash'
|