Paghiwalayin ang pagkabigo sa boot ng headless na Pi sa pagkabigo ng network

Inilalabas ang card sa pambalot bago pa may magtanong kung alin sa apat na bagay ang talagang nabigo. Tumigil sa pagtugon ang Pi pagkatapos ng pagbabago sa VPN o network, at ang muling pag-flash ang tila tanging natitirang hakbang. Bihira itong mangyari: maaaring lumipat ang lease, maaaring tumigil ang sshd, o maaaring lumabas ang tugon sa rutang hindi mo masundan, at bawat isa sa mga ito ay may sariling lunas. Ang kapaki-pakinabang na gawain ay ang paghiwalayin ang naobserbahan mo sa inakala mo.

Apat na resulta, hindi isa

Boot, address, pakikinig at maabot ay apat na magkakahiwalay na resulta, at alinman sa mga ito ay maaaring mabigo habang nananatili ang iba. Maaaring perpektong mag-boot ang isang board at hindi kailanman lumitaw sa network. Maaari itong lumitaw sa address na walang inaasahan, o panatilihin ang tamang address habang patay ang SSH. Maaari nitong gawin nang tama ang tatlo at hindi pa rin maabot dahil lumalabas ang mga tugon sa maling gateway.

Pinagsasama-sama ng ugali ng muling pag-flash ang apat na iyon sa isang tanong, at kaya madalas itong magbigay ng gumaganang Pi at walang paliwanag kung ano talaga ang nasira.

Saan talaga nagtatapos ang ebidensya

Isulat ang tatlong bagay bago humawak ng kahit ano: ang address at uplink na huling gumana, ano ang binago, at ang unang operasyong tumigil sa paggana. Ang hostname na hindi na nagre-resolve, koneksyong SSH na nag-eexpire, at koneksyong TCP na tinatanggihan ay tatlong magkakaibang obserbasyon na tumuturo sa tatlong magkakaibang sapin. Ang bigong ping ay sumusubok sa pag-abot sa isang address at nabibigo sa lahat ng dahilan sa itaas, kasama ang board na hindi kailanman umandar. Kaya hindi ito maaaring pumalit sa pagsubok ng boot.

Kung may lokal na display o recovery console, gamitin ito, dahil ang tanong na sinasagot nito ay kung naaabot ng makina ang operating system nito. Iyon lamang ang tanong na masosolusyunan ng muling pag-flash. Kung nabigo ang board bago ang yugtong iyon, sundan ang dokumentasyon ng recovery ng platform sa halip na maghinuha ng sira sa hardware mula sa kulang na screenshot, at itigil ang pagbunot ng kuryente bilang diagnostic.

Itayong muli ang daan ng pag-access sa tumatakbong sistema

Hanapin ang kasalukuyang uplink at address sa pamamagitan ng nagmamay-ari ng configuration ng network, pagkatapos ihambing ito sa kasalukuyang listahan ng kliyente ng router at sa address na ginamit ng SSH client. Ang naka-save na hostname o lumang DHCP lease ay maaaring tumuro sa destinasyon ng kahapon nang ilang linggo. Pagkatapos tiyakin na naka-enable ang sshd, nakikinig sa address na umiiral, at pinapayagan mula sa administrasyon network. Itinuturing ng gabay sa SSH ng Raspberry Pi ang pag-enable ng server at pagkonekta sa kasalukuyang address bilang dalawang magkahiwalay na hakbang, at iniiwan ng bagong install ng Raspberry Pi OS na patay ang SSH bilang default.

Maaaring muling ituro ang hostname sa ibang makina, at ang kapalit na image ay may sariling key, kaya suriin ang fingerprint sa daang pinagkakatiwalaan mo na sa halip na i-click lampasan ang babala. Ang pagbura ng babala ay ang paraan kung paano nagiging permanenteng problema sa tiwala ang pansamantalang pagbabago ng address. Kung ang prompt ng key lang ang sintomas, tanong ng pagkakakilanlan ang tinitignan mo, hindi ng pag-abot.

Sundan ang ruta ng tugon bago sisihin ang board

Maaaring baguhin ng VPN ang pagpili ng ruta habang nananatiling konektado ang pisikal na link, at iyon mismo ang kaso kung saan naka-on ang Pi, nakikinig, at hindi pa rin maabot. Dumarating ang kahilingan at lumalabas ang tugon sa tunnel na hindi madaanan ng kliyente ng administrador. Ang lokal na console at nakikinig na socket ay walang pinapatunayan tungkol sa pabalik na daan, kaya tiyakin kung aling interface ang nagdadala ng tugon at aling gateway ang pinipili nito. Ihambing ito sa network kung saan talaga naroon ang administrador, dahil ang kabiguang ito ay mas madalas na mali ang diagnosis bilang patay na board kaysa sa iba.

Ang pinakamurang pagsusuri ay panoorin ang tugon na lumalabas: sa Pi, itanong kung aling ruta ang magdadala sa address ng administrador at ihambing ito sa interface kung saan dumating ang kahilingan. Ang hindi pagkakatugma doon ay nagpapaliwanag sa buong sintomas at isang utos lang ang halaga.

Isang hangganan sa isang pagkakataon, at kailan tama ang muling pag-flash

Itama ang configuration sa pamamagitan ng may-ari nito pagkatapos i-preserve ang kasalukuyang estado. Ang pagpalit ng network manager, paglilinis ng firewall at paghula ng static address ay tatlong pagbabagong gumagawa sa susunod na obserbasyon na walang saysay. Kung ang ebidensya ay tumuturo sa ruta o pag-filter ng VPN, bumalik sa sariling routine ng paghinto o pag-aayos ng kliyenteng iyon, nagtatrabaho sa loob ng napagkasunduang plano sa recovery; ang kontroladong paghahambing ay iba sa pagpatay ng proteksyon sa host na hindi mo pa naipaliwanag.

Ang muling pag-flash ay sinadyang pagpili ng recovery, ginagawa kapag nauunawaan mo ang data, pagkakakilanlan at yugtong nabigo. Hindi ito ang dapat na papukawin ng nawawalang login bilang default.

Itago ang talaan ng configuration sa lugar na mababasa nang walang Pi, at daang pabalik na hindi dumadaan sa tunnel na babaguhin mo. Pagkatapos ay magtrabaho nang sunod-sunod: tiyakin ang yugto mula sa lokal na console, hanapin ang kasalukuyang address, suriin ang listener at ang patakaran nito, sundan ang ruta ng tugon, at baguhin ang isang bagay. Kung hindi kailanman naabot ng board ang operating system, ang dokumentasyon ng recovery ang susunod na hakbang, hindi ang network.