### 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'