nixos-config/docs/pinix-reboot-probe.md

Reboot- und Reconnect-Probe fuer pinix (Intent Schritt 6)

Vorbereitet und Probe A gelaufen am 12.09.2026. Probe A (Reboot) ist bestanden -- Ergebnis unten. Probe B (Reconnect) steht aus und braucht eine Handlung am Nokia. Aufbau und Abnahmekriterien stehen hier, damit eine Wiederholung ohne Improvisation laeuft.

Warum das der eigentliche Torwaechter ist

Der Intent nennt Schritt 6 als letzten offenen Punkt, und die Traefik-Uebergabe begruendet, warum selbst gehosteter DNS bis dahin zurueckgestellt bleibt: ein autoritativer Nameserver braucht einen zuverlaessig erreichbaren Host, und genau diese Eigenschaft ist fuer pinix nicht nachgewiesen. Die Fehlerfolgen sind asymmetrisch -- HTTP-01 kaputt kostet ein Zertifikat, autoritativer DNS kaputt kostet die Aufloesung von 0ff.space samt Mail, XMPP-Foederation und ActivityPub. Deshalb vor jeder Delegation diese Probe.

Was konkret noch nie getestet wurde

/run/booted-system zeigt auf Generation 240 (s6fdkprawpswx27pdap5qbwqw146fkcx), /run/current-system auf 242 (2fwsvih9vkwlc7whq41dhd2lbz394gmj). Beide BIND-Generationen (241, 242) sind ausschliesslich per switch aktiviert worden. BIND hat also noch keinen Bootvorgang erlebt.

Die Hauptvermutung, die die Probe pruefen soll, ist der Resolver. hosts/pinix/localServices/bind.nix setzt networking.resolvconf.useLocalResolver = lib.mkForce false, weil das BIND-Modul sonst localhost als Resolver eintraegt. Beim laufenden switch war /etc/resolv.conf schon korrekt und blieb es. Beim Boot wird resolvconf neu erzeugt. Gewinnt dort der localhost-Eintrag, hat pinix keinen funktionierenden Resolver mehr: BIND ist autoritativ und rekursiert nicht, der Uplink ist IPv6-only ueber Mangos DNS64. Folge waeren stillschweigend kaputtes ACME, kaputte Updates und ein fehlschlagender mango-dns-Timer -- bei laufendem, scheinbar gesundem System.

Der Diff dieser Session beruehrt weder Bootloader noch Kernel, initrd oder Dateisysteme, sondern nur Dienste und zwei Firewall-Ports. Ein "bootet nicht" ist damit unwahrscheinlich; erwartbar sind Dienst- und Netzwerkfehler nach dem Boot.

Rueckweg, vor dem Start bekannt

Nach Prioritaet:

1. LAN-Zugang von tnix. ssh drone@192.168.8.244 bzw. die ULA fdee:3c40:44f0:0:dea6:32ff:fe48:c6c8. Dieser Weg haengt nicht am Mobilfunk-Uplink, nicht am Nokia und nicht an Tailscale -- Ethernet ins Mango-LAN genuegt. Er muss vor dem Start gesteckt und geprueft sein. Damit ist ein Rueckbau auf Generation 240 moeglich:

   sudo /nix/var/nix/profiles/system-240-link/bin/switch-to-configuration switch
   

2. pinix bootet, Netz kaputt. Dann bleibt nur Konsole am Geraet (HDMI und Tastatur) oder der SD-Karten-Weg.

3. pinix bootet nicht. SD-Karte in eine andere Maschine und in /boot/extlinux/extlinux.conf die erste Zeile von DEFAULT nixos-default auf DEFAULT nixos-240-default aendern. Die Generationen 233 bis 242 liegen dort als LABEL vor. Eine Auswahl beim Boot gibt es headless nicht -- U-Boot/extlinux nimmt ohne Konsole den Default. Das ist der Grund, warum Schritt 1 vorher stehen und funktionieren muss.

Mango-Firewall-Backups liegen auf dem Router unter /root/ipv6-*-firewall-backup.*/firewall bzw. /root/pinix-dns-firewall-backup.*/firewall. Beim Zuruecklegen keine spaeteren Firewall-Aenderungen ueberschreiben.

Ablauf

Zwei getrennte Proben, damit ein Fehlschlag zuordenbar bleibt. Reboot zuerst, weil er lokal vollstaendig reparierbar ist.

# 0. Rueckweg sichern: Ethernet steckt, LAN-Zugang beweisen
ssh -o HostKeyAlias=pinix drone@192.168.8.244 'echo LAN ok'

# 1. Ausgangszustand
./scripts/pinix-reachability-probe.sh vorher > /tmp/probe-vorher.txt

# 2a. Probe A -- Reboot von pinix
ssh -o HostKeyAlias=pinix drone@192.168.8.244 'sudo reboot'
#     ... warten, bis SSH wieder antwortet
./scripts/pinix-reachability-probe.sh nachher-reboot > /tmp/probe-reboot.txt
diff -u /tmp/probe-vorher.txt /tmp/probe-reboot.txt

# 2b. Probe B -- Nokia-Reconnect (Praefixwechsel), separat
#     Nokia neu verbinden, dann mindestens 60 s fuer den mango-dns-Timer
./scripts/pinix-reachability-probe.sh nachher-reconnect > /tmp/probe-reconnect.txt
diff -u /tmp/probe-vorher.txt /tmp/probe-reconnect.txt

scripts/pinix-reachability-probe.sh ist rein lesend, hat pro Schritt ein Timeout und laeuft absichtlich ohne set -e durch -- ein Fehlschlag ist das Messergebnis. Die externen Tests gehen zwingend ueber --interface wlan0, weil tnix gleichzeitig im Mango-LAN haengt und die DNAT-Regeln reflection=0 tragen; ein Test ohne Interface-Bindung nimmt den LAN-Weg und meldet einen Fehlschlag, der keiner ist.

Abnahmekriterien

Pruefung	Erwartung
booted vs current	identisch, beide Generation 242
is-system-running	running bzw. degraded nur wegen tailscaled-autoconnect (siehe unten); kein anderer Fehler
/etc/resolv.conf	Mango (192.168.8.1), nicht 127.0.0.1
stabile SLAAC-ULA	…:dea6:32ff:fe48:c6c8 vorhanden
IPv6-Default-Route	per proto ra auf end0 vorhanden
bind / traefik	active, BIND liefert SOA ueber ::1
Mango-Weiterleitungen	pinix_web_*, pinix_ssh weiter DNAT
extern	https=200, http=301, ssh2222=offen
Cloudflare-AAAA	stimmt mit der tatsaechlichen Adresse ueberein

Was im Diff legitim abweicht

Nicht jede Abweichung ist ein Fehler:

• Zeitstempel in der Kopfzeile.
• Die Quelladresse von tnix' wlan0 (Privacy Extensions).
• Bei Probe B die oeffentliche Mango-Adresse -- aber dann muss der Cloudflare-AAAA innerhalb einer Timer-Periode nachziehen. Tut er das nicht, hat mango-dns sein Ziel verfehlt und der Punkt ist ein Fehler.
• pinix_dns=FEHLT, solange scripts/configure-mango-dns.sh nicht gelaufen ist, und entsprechend der DNS-Timeout im externen Test. Seit dem 12.09.2026 ist die Regel gesetzt, das sollte also nicht mehr auftreten.
• degraded mit fehlgeschlagenem tailscaled-autoconnect.service: ein bestehender, von BIND unabhaengiger Fehler, unten erklaert. Erst wenn eine andere Unit auftaucht, ist es ein Befund.

Bekannter Nebenbefund

Die Probe liest auch Aussteller und Restlaufzeit des Zertifikats. Aktuell issuer=CN=YR1, notAfter=Dec 11 12:20:18 2026 GMT -- das ist die aus der Traefik-Uebergabe bekannte Kette ueber ISRG Root YR, die auf Clients mit aelterem CA-Bundle scheitert. Die Entscheidung ueber preferredChain steht weiterhin aus und ist nicht Teil dieser Probe.

Ergebnis Probe A (Reboot), 12.09.2026

Bestanden. systemctl reboot um 17:50:09, SSH nach etwa 25 s wieder da, neue boot_id (97119559… -> 13253402…), also ein echter Neustart. Der Diff der beiden Aufnahmen enthaelt genau zwei Abweichungen.

Die erwuenschte: booted entspricht jetzt current, beide Generation 242 (2fwsvih9…). BIND hat damit seinen ersten Bootvorgang ueberlebt.

Unveraendert und damit bestanden: bind, traefik, mango-dns.timer und tailscaled aktiv, stabile SLAAC-ULA vorhanden, RA-Default-Route auf end0 vorhanden, BIND antwortet autoritativ, alle Mango-Regeln inklusive pinix_dns und dport 53 persistent, Cloudflare-AAAA deckt sich mit der tatsaechlichen Adresse, extern https=200, http=301, Port 2222 offen, DNS-SOA von aussen beantwortet, Zertifikat unveraendert (notAfter=Dec 11) -- der ACME-Zustand in /var/lib/traefik hat den Neustart also ueberlebt.

Die Hauptvermutung hat sich nicht bestaetigt, und das ist die gute Nachricht: /etc/resolv.conf zeigt auch nach dem Boot auf Mango und nicht auf localhost. networking.resolvconf.useLocalResolver = lib.mkForce false haelt also nicht nur beim switch, sondern auch beim Neuaufbau durch resolvconf im Boot.

Der eine echte Fund: pinix ist aus dem Tailnet gefallen

Die zweite Abweichung ist running -> degraded mit fehlgeschlagenem tailscaled-autoconnect.service. Das ist nicht von BIND verursacht -- die Unit war bereits am Anfang dieser Sitzung auf der Generation vor BIND fehlgeschlagen. Der Boot hat den Fehler nur wieder sichtbar gemacht, inklusive 90 s Timeout, die multi-user.target aufhalten.

Die Ursache ist strukturell und hat mit Tailscale selbst wenig zu tun:

You are logged out. The last login error was: fetch control key:
Get "https://head.0ff.space/key?v=142": dial tcp 23.88.33.137:443:
connect: network is unreachable

pinix hat keine IPv4-Default-Route und erreicht 23.88.33.137 (blunix, der Headscale-Host) nicht. Dass blunix ausschliesslich per IPv4 erreichbar ist, ist am selben Tag unabhaengig aufgefallen: der Host hat ueberhaupt keine oeffentliche IPv6, nur die Tailnet-ULA.

Bemerkenswert ist, dass NAT64 den Fall eigentlich abdeckt -- getent hosts head.0ff.space liefert 64:ff9b::1758:2189. Tailscale loest aber selbst auf, nimmt den A-Eintrag und waehlt die IPv4-Adresse direkt, womit es an DNS64 vorbeilaeuft.

Zwei Folgerungen:

1. Das Tailnet ist kein Rueckweg zu pinix. Der Abschnitt oben nennt den LAN-Zugang als Weg 1 -- das war richtig, aber aus einem schwaecheren Grund als dem tatsaechlichen. Es bleiben LAN und die oeffentliche DNAT-Weiterleitung.
2. blunix eine oeffentliche IPv6 geben ist der saubere Fix, nicht eine Sonderbehandlung in Tailscale: dann bekommt head.0ff.space einen echten AAAA, pinix verbindet sich native, die Unit hoert auf zu scheitern und der Boot verliert 90 s Verzoegerung. Das haengt mit der Frage nach einem Sekundaeren fuer die Zone zusammen -- siehe pinix-bind.md.

Noch offen: Probe B (Reconnect)

Nicht gelaufen. Ein Praefixwechsel setzt voraus, dass sich das Nokia neu am Mobilfunknetz anmeldet; das Bouncen des Mango-Uplinks erzwingt kein neues Praefix und pruefte daher die eigentliche Frage nicht. Diese Probe braucht also eine Handlung am Nokia.