admin/platform-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: Voraussetzung fuer den Backend-Lebenszyklus auf Casper-Medien notieren

Browse Source 
Ergaenzt einen kurzen Hinweis, dass /opt/tuxflotte auf Mint/Casper-Medien
nicht automatisch vorhanden ist, sondern erst durch einen
casper-bottom-Initrd-Hook vor backend_init() entsteht (siehe
tuxflotte-installer, Phase 4 des Self-Service-ISO-Plans) - und Abgrenzung
zu backend_postinstall(), das ein anderes, spaeteres Dateisystem anfasst
(Ziel-Platte nach der Installation statt Live-Session davor).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Thomas Stallinger 2026-08-07 08:20:04 +02:00
parent ee4266495b
commit 9949ca860c
1 changed files with 11 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
architecture/06-backend-api.md
View File

@ -53,6 +53,17 @@ backend_launch()
backend_postinstall()
```
Voraussetzung (Mint/Casper): der gesamte obige Zyklus läuft innerhalb der
gebooteten Live-Session und setzt voraus, dass die Orchestrator-Skripte
selbst (`/opt/tuxflotte/...`) dort bereits vorhanden sind. Das ist bei
Casper-basierten Medien kein Selbstläufer — Casper merged `/updates` vom
Medium nicht automatisch auf das Live-System. Diese Voraussetzung wird
schon *vor* `backend_init()` durch einen `casper-bottom`-Initrd-Hook
geschaffen (`tuxflotte-installer/initrd-hooks/casper-bottom/99casperboot`),
nicht durch diese API. `backend_postinstall()` dagegen fasst ein anderes,
später existierendes Dateisystem an: das frische Ziel-Root-FS auf der
echten Platte, nach der Installation, vor dem ersten Reboot.
---
# Pflichtfunktionen