Thomas Stallinger
941a58535d
- noninteractive-Frontend endgueltig verworfen: PageNoninteractive-Stubs fuehren strukturell zur Endlosschleife im choose_partition-Zustands- automaten von ubi-partman.py, unabhaengig vom Preseed-Stand. - Umstieg auf automatic-ubiquity (echte GTK-Oberflaeche) + eigener Autoklicker (live-updates/opt/tuxflotte/scripts/autoclicker.sh + systemd-Service), ausgeloest per Boot-Keyword tuxflotte-autoclick. - Bug 1: jq fehlte beim echten Kiosk-Auslauf (kein manueller Vorab- Installationsschritt wie in Testlaeufen) - neues Modul 00_preflight.sh installiert es als allererstes. - Bug 2: echter Ubiquity-Crash in ubi-prepare.py (TypeError: Argument 1 does not allow None as a value) - gezielter Sed-Patch im bestehenden 99casperboot-Hook. - Bug 3: 'd-i partman/choose_partition select finish' zwang denselben Endlosschleifen-Zustandsautomaten wie bei noninteractive, auch im GTK-Modus - Zeile ersatzlos entfernt, partman-auto/method+recipe genuegen. - autoclicker.sh: Fenstersuche nach 'ubiquity' korrigiert (Fenstertitel ist tatsaechlich 'Installation (as superuser)', enthaelt das Wort nie). - Alle vier Fixes live per QEMU verifiziert (jeweils frische Disk, realer Kiosk-Ausloeser/kexec-Pfad, nicht nur manuelle Nachstellung). Offen: automatisierter Klick auf 'Jetzt installieren' auf der Partitionierungs-Uebersichtsseite noch nicht zuverlaessig (Enter trifft dort einen Ausklapp-Pfeil statt den Button). Siehe ADR-0023-Nachtrag. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
138 lines
7.6 KiB
Smarty
138 lines
7.6 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-partitioning/confirm_new_label boolean true
|
|
# "partman/choose_partition select finish" wurde bewusst entfernt: das ist
|
|
# die Frage des MANUELLEN/erweiterten Partitionierers ("Menu" -> "Finish
|
|
# partitioning"), keine des gefuehrten/automatischen Ablaufs. Direktes
|
|
# Preseeden ohne echten Seitenaufbau (weder im GTK- noch im
|
|
# noninteractive-Frontend) fuehrt in ubi-partman.py real reproduzierbar zu
|
|
# einer Endlosschleife im internen "building_cache"-Zustandsautomaten der
|
|
# choose_partition-Verarbeitung (ueber 100.000 Debconf-Zeilen in wenigen
|
|
# Sekunden ohne echten Fortschritt, sowohl mit automatic-ubiquity/GTK als
|
|
# auch mit dem verworfenen noninteractive-Frontend - siehe ADR-0023-Nachtrag).
|
|
# Ohne diese Zeile uebernehmen partman-auto/method + expert_recipe +
|
|
# choose_recipe (oben) die gefuehrte Partitionierung auf dem dafuer
|
|
# vorgesehenen Weg.
|
|
d-i partman/confirm boolean true
|
|
d-i partman/confirm_nochanges boolean true
|
|
d-i partman/confirm_nooverwrite boolean true
|
|
d-i partman/unmount_active boolean true
|
|
d-i partman/automount boolean true
|
|
d-i partman/filter_mounted boolean true
|
|
d-i partman-partitioning/confirm_resize boolean true
|
|
d-i partman-ext3/lazy_itable_init boolean true
|
|
d-i partman/boot_not_first_partition boolean true
|
|
d-i partman-basicfilesystems/boot_not_first_partition boolean true
|
|
d-i partman-basicfilesystems/boot_not_ext2 boolean true
|
|
d-i partman-ext3/boot_not_bootable boolean true
|
|
d-i partman-ext3/boot_not_ext2_or_ext3 boolean true
|
|
d-i partman-basicfilesystems/no_mount_point boolean true
|
|
d-i partman-basicfilesystems/no_swap boolean true
|
|
d-i partman-basicfilesystems/check_failed boolean true
|
|
d-i partman-basicfilesystems/swap_check_failed boolean true
|
|
d-i partman-ext3/bad_alignment boolean true
|
|
# Dieselbe Polaritaets-Falle wie bei no_bootable_biosgrub weiter unten (siehe
|
|
# dortiger Kommentar) - "true" hiesse "Problem besteht wirklich, abbrechen".
|
|
# Fuer UEFI-Zielgeraete legt _tuxflotte_render_partman_recipe() bereits eine
|
|
# echte ESP an, dieser Fallback sollte also nie greifen.
|
|
d-i partman-partitioning/no_bootable_efi boolean false
|
|
# Anders als die meisten uebrigen Boolean-Fragen hier bedeutet "true" bei
|
|
# no_bootable_biosgrub NICHT "trotzdem fortfahren", sondern "das Problem
|
|
# besteht wirklich" -> der pruefende Skript (check.d/08biosgrub) bricht dann
|
|
# mit exit 1 ab, was zur Endlosschleife zurueck ins choose_partition-Menue
|
|
# fuehrt (real entdeckt und via Quelltext auf dem Live-Medium verifiziert,
|
|
# siehe ADR-0023-Nachtrag). Der eigentliche Fix ist eine echte BIOS-Boot-
|
|
# Partition im Rezept (siehe _tuxflotte_render_partman_recipe() in
|
|
# backend.sh) - "false" hier bleibt nur als defensiver Fallback, falls die
|
|
# Partition aus irgendeinem Grund nicht als "biosgrub" erkannt wird.
|
|
d-i partman-partitioning/no_bootable_biosgrub boolean false
|
|
d-i partman-partitioning/bootable_logical boolean true
|
|
d-i partman-partitioning/unknown_label boolean true
|
|
d-i partman-partitioning/unsupported_label boolean true
|
|
d-i partman-basicmethods/method_only boolean true
|
|
d-i grub-installer/only_debian boolean true
|
|
d-i grub-installer/with_other_os boolean true
|
|
d-i grub-installer/make_active boolean true
|
|
d-i grub-installer/grub2_instead_of_grub_legacy boolean true
|
|
d-i grub-installer/grub_not_mature_on_this_platform boolean true
|
|
d-i grub-installer/multipath boolean true
|
|
d-i grub-installer/sataraid boolean true
|
|
# Wichtig: false, nicht true -- "skip" heisst hier woertlich "GRUB-Installation
|
|
# ueberspringen". true wuerde die Bootloader-Installation aktiv verhindern.
|
|
d-i grub-installer/skip boolean false
|
|
d-i partman-auto-lvm/no_boot boolean true
|
|
d-i partman-target/mount_failed boolean true
|
|
# partman-efi/no_efi wird ENTGEGEN der urspruenglichen Annahme sehr wohl
|
|
# gefragt, auch im reinen BIOS/SeaBIOS-Betrieb ohne NVRAM (real via
|
|
# debug-ubiquity-Log verifiziert, siehe ADR-0023-Nachtrag) -- Ubiquity prueft
|
|
# offenbar unabhaengig vom aktuellen Boot-Modus, ob eine EFI-System-Partition
|
|
# existiert. "false" heisst hier "trotzdem fortfahren" (die Alternative
|
|
# "true" wuerde zurueck ins Partitionierungsmenue springen und den Ablauf
|
|
# blockieren -- fuer ein bewusstes BIOS/MBR-Setup ohne EFI-Partition ist
|
|
# false die richtige Antwort).
|
|
d-i partman-efi/no_efi boolean false
|
|
# Bewusst weiterhin NICHT preseeded: grub-installer/force-efi-extra-removable
|
|
# (EFI-spezifisch, im BIOS-Betrieb ohne Wirkung) sowie partman-crypto/*,
|
|
# partman-lvm/*, partman-jfs/* (Recipe nutzt weder Crypto noch LVM noch JFS,
|
|
# koennen also nie auftreten; einige dieser Fragen sind bei "true" destruktiv
|
|
# (z.B. crypto_warn_erase), daher hier absichtlich nicht blind auf true
|
|
# gesetzt).
|
|
|
|
ubiquity ubiquity/summary note
|
|
ubiquity ubiquity/reboot boolean true
|
|
ubiquity ubiquity/use_nonfree boolean true
|
|
# Ohne diese Zeile stuerzt Ubiquity im automatic-ubiquity-GTK-Modus real
|
|
# reproduzierbar ab (TypeError: Argument 1 does not allow None as a value,
|
|
# in ubi-prepare.py enable_download_updates() -> label_download_updates.
|
|
# set_label(), ausgeloest durch einen globalen Online-Status-Callback, der
|
|
# unabhaengig vom Automatik-Modus feuert, obwohl die zugehoerige Seite dort
|
|
# nie aufgebaut wird - die Widget-Referenz bleibt None). Die "Waehrend der
|
|
# Installation aktualisieren"-Option wird dadurch bewusst deaktiviert;
|
|
# funktional kein Verlust, da der Provisioning Agent das System nach der
|
|
# Ersteinrichtung ohnehin selbst aktuell haelt.
|
|
ubiquity ubiquity/download_updates boolean false
|
|
|
|
# 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'
|