Een opstartfout van een headless Pi onderscheiden van een netwerkfout

De kaart komt uit de behuizing voordat iemand heeft gevraagd welke van de vier dingen nu werkelijk faalde. De Pi stopte met antwoorden na een VPN- of netwerkwijziging, en opnieuw flashen voelt als de enige overgebleven stap. Dat is het zelden: de lease kan verschuiven, sshd kan stoppen, of het antwoord kan vertrekken via een route die je niet kunt volgen, en elk daarvan heeft zijn eigen oplossing. Het nuttige werk is scheiden wat je hebt waargenomen van wat je hebt aangenomen.

Vier uitkomsten, niet één

Gestart, geadresseerd, luisterend en bereikbaar zijn vier afzonderlijke uitkomsten, en elk daarvan kan falen terwijl de andere nog standhouden. Een bord kan perfect opstarten en nooit op het netwerk verschijnen. Het kan verschijnen met een adres dat niemand verwachtte, of het juiste adres houden met SSH uitgeschakeld. Het kan alle drie goed doen en toch onbereikbaar zijn omdat antwoorden via de verkeerde gateway naar buiten gaan.

De reflex om opnieuw te flashen vat die vier samen in één vraag, en daarom levert hij zo vaak een werkende Pi op zonder enige verklaring van wat er werkelijk stukging.

Waar het bewijs werkelijk eindigt

Schrijf drie dingen op voordat je iets aanraakt: het adres en de uplink die het laatst werkten, wat er is gewijzigd, en de eerste handeling die ophield met werken. Een hostnaam die niet meer oplost, een SSH-verbinding die time-out gaat, en een TCP-verbinding die wordt geweigerd zijn drie verschillende waarnemingen die op drie verschillende lagen wijzen. Een mislukte ping test de bereikbaarheid van één adres en faalt om al de bovenstaande redenen, inclusief een bord dat nooit is opgestart. Daarom kan hij een opstarttest niet vervangen.

Als er een lokaal scherm of een herstelconsole beschikbaar is, gebruik die, want de vraag die hij beantwoordt is of de machine haar besturingssysteem bereikt. Dat is de enige vraag die opnieuw flashen zou oplossen. Als het bord vóór die fase faalt, volg dan de hersteldocumentatie van het platform in plaats van een hardwarefout af te leiden uit een ontbrekende schermafbeelding, en stop met het loskoppelen van de voeding als diagnose.

Bouw het toegangspad opnieuw op een draaiend systeem

Vind de huidige uplink en het adres via wat de netwerkconfiguratie bezit, en vergelijk dat met de huidige clientlijst van de router en met het adres dat de SSH-client gebruikte. Een opgeslagen hostnaam of een oude DHCP-lease kan wekenlang naar de bestemming van gisteren wijzen. Bevestig daarna dat sshd is ingeschakeld, luistert op een adres dat bestaat, en is toegestaan vanuit het beheernetwerk. De SSH-richtlijnen van Raspberry Pi behandelen het inschakelen van de server en het verbinden met het huidige adres als twee afzonderlijke stappen, en een verse Raspberry Pi OS-installatie laat SSH standaard uitgeschakeld.

Een hostnaam kan naar een andere machine worden verwezen, en een vervangende image komt met zijn eigen sleutel, dus controleer de vingerafdruk via een pad dat je al vertrouwt in plaats van de waarschuwing weg te klikken. Het verwijderen van de waarschuwing is hoe een tijdelijke adreswijziging een permanent vertrouwensprobleem wordt. Als de sleutelvraag het enige symptoom is, kijk je naar een identiteitsvraag en niet naar een bereikbaarheidsvraag.

Volg de route van het antwoord voordat je het bord de schuld geeft

Een VPN kan de routekeuze wijzigen terwijl de fysieke link verbonden blijft, en dat is precies het geval waarin de Pi aan staat, luistert en toch onbereikbaar is. Het verzoek komt aan en het antwoord gaat naar buiten via een tunnel die de client van de beheerder niet kan passeren. Een lokale console en een luisterende socket bewijzen niets over de retourroute, dus bevestig welke interface het antwoord draagt en welke gateway die kiest. Vergelijk dat met het netwerk waarop de beheerder werkelijk zit, want deze fout wordt vaker dan welke andere ook verkeerd gediagnosticeerd als een dood bord.

De goedkoopste controle is het antwoord zien vertrekken: vraag op de Pi welke route het adres van de beheerder zou dragen en vergelijk die met de interface waarop het verzoek binnenkwam. Een verschil daar verklaart het hele symptoom en kost één commando.

Eén grens per keer, en wanneer opnieuw flashen juist is

Corrigeer de configuratie via de eigenaar ervan nadat je de huidige toestand hebt bewaard. De netwerkbeheerder vervangen, de firewall leegmaken en een statisch adres raden zijn drie wijzigingen die de volgende waarneming waardeloos maken. Als het bewijs wijst op de route of filtering van de VPN, val dan terug op de eigen stop- of reparatieroutine van die client, werkend binnen het afgesproken herstelplan; een gecontroleerde vergelijking is iets anders dan de bescherming uitschakelen op een host die je niet hebt uitgelegd.

Opnieuw flashen is een bewuste herstelkeuze, genomen zodra je de gegevens, de identiteit en de fase die faalde begrijpt. Het is niet wat een ontbrekende login standaard zou moeten uitlokken.

Bewaar het configuratierecord op een plek die zonder de Pi leesbaar is, en een weg terug die niet door de tunnel loopt die je gaat wijzigen. Werk daarna in volgorde: bevestig de fase vanaf een lokale console, vind het huidige adres, controleer de listener en het beleid ervan, volg de route van het antwoord, en wijzig één ding. Als het bord het besturingssysteem nooit heeft bereikt, is de hersteldocumentatie de volgende stap en niet het netwerk.