Skilja en startfel på en huvudlös Pi från ett nätverksfel

Kortet kommer ut ur höljet innan någon har frågat vilken av de fyra sakerna som faktiskt misslyckades. Pi:n slutade svara efter en VPN- eller nätverksändring, och en omflashning känns som det enda drag som återstår. Det är det sällan: lånet kan flytta sig, sshd kan stoppa, eller svaret kan lämna via en väg du inte kan följa, och var och en av dessa har sin egen lösning. Det nyttiga arbetet är att skilja det du observerade från det du antog.

Fyra resultat, inte ett

Startad, adresserad, lyssnande och nåbar är fyra separata utfall, och vilket som helst av dem kan misslyckas medan de andra fortfarande håller. Ett kort kan starta perfekt och aldrig dyka upp på nätverket. Det kan dyka upp med en adress som ingen förväntade, eller behålla rätt adress med SSH avstängt. Det kan få alla tre rätt och ändå vara onåbart eftersom svar går ut genom fel gateway.

Omflashningsinstinkten pressar ihop de fyra till en enda fråga, och därför ger den så ofta en fungerande Pi och ingen förklaring till vad som faktiskt gick sönder.

Där bevisen faktiskt slutar

Skriv ned tre saker innan du rör något: adressen och uppkopplingen som senast fungerade, vad som ändrades, och den första operation som slutade fungera. Ett värdnamn som inte längre slås upp, en SSH-anslutning som tidsutlöper, och en TCP-anslutning som avvisas är tre olika observationer som pekar på tre olika lager. En misslyckad ping testar nåbarheten för en adress och misslyckas av alla skälen ovan, inklusive ett kort som aldrig startade. Därför kan den inte ersätta ett starttest.

Om en lokal skärm eller en återställningskonsol finns tillgänglig, använd den, eftersom frågan den besvarar är om maskinen når sitt operativsystem. Det är den enda frågan en omflashning skulle lösa. Om kortet misslyckas före det steget, följ plattformens återställningsdokumentation i stället för att sluta dig till ett hårdvarufel från en saknad skärmbild, och sluta dra ur strömmen som diagnostik.

Bygg om åtkomstvägen på ett körande system

Hitta den aktuella uppkopplingen och adressen genom det som äger nätverkskonfigurationen, och jämför det sedan med routerns aktuella klientlista och med adressen som SSH-klienten använde. Ett sparat värdnamn eller ett gammalt DHCP-lån kan i veckor peka på gårdagens mål. Bekräfta därefter att sshd är aktiverat, lyssnar på en adress som finns, och är tillåtet från administrationsnätet. Raspberry Pi:s SSH-vägledning behandlar aktivering av servern och anslutning till den aktuella adressen som två separata steg, och en färsk Raspberry Pi OS-installation lämnar SSH avstängt som standard.

Ett värdnamn kan pekas om till en annan maskin, och en ersättningsbild kommer med sin egen nyckel, så kontrollera fingeravtrycket via en väg du redan litar på i stället för att klicka förbi varningen. Att radera varningen är hur en tillfällig adressändring blir ett permanent tillitsproblem. Om nyckelfrågan är det enda symptomet tittar du på en identitetsfråga och inte en nåbarhetsfråga.

Följ svarets väg innan du skyller på kortet

En VPN kan ändra vägvalet medan den fysiska länken förblir ansluten, och det är precis det fall där Pi:n är uppe, lyssnar och ändå är onåbar. Begäran kommer in och svaret går ut genom en tunnel som administratörens klient inte kan passera. En lokal konsol och en lyssnande socket bevisar ingenting om returvägen, så bekräfta vilket gränssnitt som bär svaret och vilken gateway det väljer. Jämför det med nätverket som administratören faktiskt befinner sig på, eftersom detta fel feldiagnostiseras som ett dött kort oftare än något annat.

Den billigaste kontrollen är att se svaret lämna: på Pi:n, fråga vilken väg som skulle bära administratörens adress och jämför den med gränssnittet som begäran kom in på. En avvikelse där förklarar hela symptomet och kostar ett enda kommando.

En gräns i taget, och när omflashning är rätt

Rätta konfigurationen genom dess ägare efter att ha bevarat nuvarande tillstånd. Att byta nätverkshanterare, tömma brandväggen och gissa en statisk adress är tre ändringar som gör nästa observation värdelös. Om bevisen pekar på VPN:ns väg eller filtrering, fall tillbaka på den klientens egen stopp- eller reparationsrutin, och arbeta inom den överenskomna återställningsplanen; en kontrollerad jämförelse är något annat än att stänga av skydd på en värd du inte har förklarat.

Omflashning är ett medvetet återställningsval, fattat när du förstår data, identitet och det steg som misslyckades. Det är inte det som en saknad inloggning ska utlösa som standard.

Förvara konfigurationsposten på en plats som går att läsa utan Pi:n, och en väg tillbaka som inte går genom tunneln du är på väg att ändra. Arbeta sedan i ordning: bekräfta steget från en lokal konsol, hitta den aktuella adressen, kontrollera lyssnaren och dess policy, följ svarets väg, och ändra en sak. Om kortet aldrig nådde operativsystemet är återställningsdokumentationen nästa steg och inte nätverket.