docs: Voraussetzung fuer den Backend-Lebenszyklus auf Casper-Medien notieren
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:
parent
ee4266495b
commit
9949ca860c
@ -53,6 +53,17 @@ backend_launch()
|
|||||||
backend_postinstall()
|
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
|
# Pflichtfunktionen
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user