At skelne en opstartsfejl på en hovedløs Pi fra en netværksfejl

Kortet kommer ud af kabinettet, før nogen har spurgt, hvilken af de fire ting der faktisk svigtede. Pi'en holdt op med at svare efter en VPN- eller netværksændring, og en genflashning føles som det eneste træk tilbage. Det er den sjældent: leasen kan flytte sig, sshd kan stoppe, eller svaret kan forlade systemet ad en rute, du ikke kan følge, og hver af disse har sin egen løsning. Det nyttige arbejde er at skelne mellem det, du observerede, og det, du antog.

Fire resultater, ikke ét

Startet, adresseret, lyttende og tilgængelig er fire separate udfald, og ethvert af dem kan svigte, mens de andre stadig holder. Et board kan starte perfekt og aldrig dukke op på netværket. Det kan dukke op med en adresse, ingen forventede, eller holde den rigtige adresse med SSH slået fra. Det kan få alle tre rigtigt og stadig være utilgængeligt, fordi svar forlader systemet gennem den forkerte gateway.

Genflashningsinstinktet samler de fire til ét spørgsmål, og derfor giver det så ofte en fungerende Pi uden nogen forklaring på, hvad der faktisk gik i stykker.

Hvor beviserne faktisk slutter

Skriv tre ting ned, før du rører noget: den adresse og uplink, der sidst virkede, hvad der blev ændret, og den første handling, der holdt op med at virke. Et værtsnavn, der ikke længere slår op, en SSH-forbindelse, der timer ud, og en TCP-forbindelse, der afvises, er tre forskellige observationer, der peger på tre forskellige lag. En mislykket ping tester tilgængeligheden af én adresse og fejler af alle ovenstående grunde, inklusive et board, der aldrig startede. Derfor kan den ikke erstatte en opstartstest.

Hvis en lokal skærm eller en gendannelseskonsol er tilgængelig, så brug den, for det spørgsmål, den besvarer, er, om maskinen når sit styresystem. Det er det eneste spørgsmål, en genflashning ville løse. Hvis boardet svigter før den fase, så følg platformens gendannelsesdokumentation i stedet for at udlede en hardwarefejl af et manglende skærmbillede, og hold op med at trække strømmen som diagnostik.

Genopbyg adgangsvejen på et kørende system

Find den aktuelle uplink og adresse gennem det, der ejer netværkskonfigurationen, og sammenlign det med routerens aktuelle klientliste og med den adresse, SSH-klienten brugte. Et gemt værtsnavn eller en gammel DHCP-lease kan i ugevis pege på gårsdagens destination. Bekræft derefter, at sshd er aktiveret, lytter på en adresse, der findes, og er tilladt fra administrationsnetværket. Raspberry Pi's SSH-vejledning behandler aktivering af serveren og forbindelse til den aktuelle adresse som to separate trin, og en frisk Raspberry Pi OS-installation lader SSH være slået fra som standard.

Et værtsnavn kan peges om til en anden maskine, og et erstatningsbillede kommer med sin egen nøgle, så tjek fingeraftrykket ad en vej, du allerede stoler på, i stedet for at klikke advarslen bort. Sletning af advarslen er måden, hvorpå en midlertidig adresseændring bliver et permanent tillidsproblem. Hvis nøgleprompten er det eneste symptom, står du over for et identitetsspørgsmål og ikke et tilgængelighedsspørgsmål.

Følg svarets rute, før du bebrejder boardet

En VPN kan ændre rutevalget, mens det fysiske link forbliver tilknyttet, og det er præcis tilfældet, hvor Pi'en er oppe, lytter og stadig er utilgængelig. Anmodningen ankommer, og svaret forlader systemet gennem en tunnel, som administratorens klient ikke kan passere. En lokal konsol og en lyttende socket beviser intet om returvejen, så bekræft, hvilken grænseflade der bærer svaret, og hvilken gateway den vælger. Sammenlign det med det netværk, administratoren faktisk er på, for denne fejl fejldiagnosticeres som et dødt board oftere end nogen anden.

Den billigste kontrol er at se svaret forlade systemet: spørg på Pi'en, hvilken rute der ville bære administratorens adresse, og sammenlign den med den grænseflade, anmodningen ankom på. En uoverensstemmelse der forklarer hele symptomet og koster én kommando.

Én grænse ad gangen, og hvornår en genflashning er rigtig

Ret konfigurationen gennem dens ejer, efter at have bevaret den nuværende tilstand. At udskifte netværksadministratoren, tømme firewallen og gætte en statisk adresse er tre ændringer, der gør den næste observation ubrugelig. Hvis beviserne peger på VPN'ens rute eller filtrering, så fald tilbage til den klients egen stop- eller reparationsrutine og arbejd inden for den aftalte gendannelsesplan; en kontrolleret sammenligning er noget andet end at slå beskyttelsen fra på en vært, du ikke har forklaret.

Genflashning er et bevidst gendannelsesvalg, truffet når du forstår dataene, identiteten og den fase, der svigtede. Det er ikke det, et manglende login bør udløse som standard.

Opbevar konfigurationsregistret et sted, der kan læses uden Pi'en, og en vej tilbage, der ikke går gennem den tunnel, du er ved at ændre. Arbejd derefter i rækkefølge: bekræft fasen fra en lokal konsol, find den aktuelle adresse, tjek lytteren og dens politik, følg svarets rute, og ændr én ting. Hvis boardet aldrig nåede styresystemet, er gendannelsesdokumentationen det næste skridt og ikke netværket.