ਹੈੱਡਲੈੱਸ Pi ਦੀ ਬੂਟ ਅਸਫਲਤਾ ਨੂੰ ਨੈੱਟਵਰਕ ਅਸਫਲਤਾ ਤੋਂ ਵੱਖਰਾ ਪਛਾਣਨਾ

ਚਾਰਾਂ ਵਿੱਚੋਂ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਚੀਜ਼ ਅਸਫਲ ਹੋਈ, ਇਹ ਕਿਸੇ ਦੇ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਕਾਰਡ ਕੇਸ ਵਿੱਚੋਂ ਬਾਹਰ ਆ ਜਾਂਦਾ ਹੈ। VPN ਜਾਂ ਨੈੱਟਵਰਕ ਬਦਲਣ ਤੋਂ ਬਾਅਦ Pi ਨੇ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ, ਅਤੇ ਰੀਫਲੈਸ਼ ਹੀ ਬਚਿਆ ਇੱਕੋ-ਇੱਕ ਕਦਮ ਲੱਗਦਾ ਹੈ। ਅਜਿਹਾ ਘੱਟ ਹੀ ਹੁੰਦਾ ਹੈ: ਲੀਜ਼ ਖਿਸਕ ਸਕਦੀ ਹੈ, sshd ਰੁਕ ਸਕਦਾ ਹੈ, ਜਾਂ ਜਵਾਬ ਅਜਿਹੇ ਰਾਹ ਰਾਹੀਂ ਨਿਕਲ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਲੱਭ ਨਹੀਂ ਸਕਦੇ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ ਹੱਲ ਹੈ। ਲਾਹੇਵੰਦ ਕੰਮ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਜੋ ਵੇਖਿਆ ਨੂੰ ਉਸ ਤੋਂ ਵੱਖ ਕਰੋ ਜੋ ਤੁਸੀਂ ਮੰਨ ਲਿਆ।

ਚਾਰ ਨਤੀਜੇ, ਇੱਕ ਨਹੀਂ

ਬੂਟ ਹੋਣਾ, ਪਤਾ ਮਿਲਣਾ, ਸੁਣਨਾ ਅਤੇ ਪਹੁੰਚਣਾ—ਇਹ ਚਾਰ ਵੱਖਰੇ ਨਤੀਜੇ ਹਨ, ਅਤੇ ਬਾਕੀ ਬਚੇ ਰਹਿੰਦਿਆਂ ਵੀ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ। ਬੋਰਡ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੂਟ ਹੋ ਕੇ ਵੀ ਨੈੱਟਵਰਕ 'ਤੇ ਕਦੇ ਨਹੀਂ ਦਿਸ ਸਕਦਾ। ਇਹ ਕਿਸੇ ਦੇ ਨਾ ਸੋਚੇ ਪਤੇ ਨਾਲ ਦਿਸ ਸਕਦਾ ਹੈ, ਜਾਂ ਸਹੀ ਪਤਾ ਰੱਖਦਿਆਂ SSH ਬੰਦ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਤਿੰਨੇ ਸਹੀ ਕਰ ਕੇ ਵੀ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਰਹਿ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਜਵਾਬ ਗ਼ਲਤ ਗੇਟਵੇ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ।

ਰੀਫਲੈਸ਼ ਦੀ ਆਦਤ ਉਨ੍ਹਾਂ ਚਾਰਾਂ ਨੂੰ ਇੱਕ ਸਵਾਲ ਵਿੱਚ ਸਮੇਟ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਅਕਸਰ ਇੱਕ ਚੱਲਦਾ Pi ਦਿੰਦੀ ਹੈ ਪਰ ਇਹ ਕੋਈ ਸਪੱਸ਼ਟੀਕਰਨ ਨਹੀਂ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਟੁੱਟਿਆ।

ਸਬੂਤ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ

ਕੁਝ ਵੀ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਗੱਲਾਂ ਲਿਖੋ: ਆਖ਼ਰੀ ਵਾਰ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪਤਾ ਅਤੇ ਅਪਲਿੰਕ, ਕੀ ਬਦਲਿਆ, ਅਤੇ ਪਹਿਲਾ ਕੰਮ ਜੋ ਰੁਕ ਗਿਆ। ਜੋ ਹੋਸਟਨਾਮ ਹੁਣ ਹੱਲ ਨਹੀਂ ਹੁੰਦਾ, ਜੋ SSH ਕਨੈਕਸ਼ਨ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਕੇ ਰੁਕ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜੋ TCP ਕਨੈਕਸ਼ਨ ਨਾਮਨਜ਼ੂਰ ਹੁੰਦਾ ਹੈ—ਇਹ ਤਿੰਨ ਵੱਖਰੇ ਨਿਰੀਖਣ ਹਨ ਜੋ ਤਿੰਨ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ। ਅਸਫਲ ping ਇੱਕ ਪਤੇ ਦੀ ਪਹੁੰਚ ਜਾਂਚਦਾ ਹੈ ਅਤੇ ਉੱਪਰ ਦੱਸੇ ਹਰ ਕਾਰਨ ਨਾਲ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹ ਬੋਰਡ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜੋ ਕਦੇ ਸ਼ੁਰੂ ਹੀ ਨਹੀਂ ਹੋਇਆ। ਇਸ ਲਈ ਇਹ ਬੂਟ ਟੈਸਟ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦਾ।

ਜੇ ਸਥਾਨਕ ਡਿਸਪਲੇ ਜਾਂ ਰਿਕਵਰੀ ਕੰਸੋਲ ਉਪਲਬਧ ਹੋਵੇ ਤਾਂ ਇਸਤੇਮਾਲ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਜਿਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਉਹ ਹੈ ਕਿ ਮਸ਼ੀਨ ਆਪਣੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਰੀਫਲੈਸ਼ ਸਿਰਫ਼ ਇਹੀ ਸਵਾਲ ਹੱਲ ਕਰਦਾ। ਜੇ ਬੋਰਡ ਉਸ ਪੜਾਅ ਤੋਂ ਪਹਿਲਾਂ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਸਕ੍ਰੀਨਸ਼ਾਟ ਨਾ ਹੋਣ ਤੋਂ ਹਾਰਡਵੇਅਰ ਖ਼ਰਾਬੀ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਪਲੇਟਫਾਰਮ ਦੇ ਰਿਕਵਰੀ ਦਸਤਾਵੇਜ਼ ਦੀ ਪਾਲਣਾ ਕਰੋ, ਅਤੇ ਨਿਦਾਨ ਵਜੋਂ ਪਾਵਰ ਖਿੱਚਣਾ ਬੰਦ ਕਰੋ।

ਚੱਲ ਰਹੇ ਸਿਸਟਮ 'ਤੇ ਪਹੁੰਚ ਦਾ ਰਾਹ ਦੁਬਾਰਾ ਬਣਾਓ

ਮੌਜੂਦਾ ਅਪਲਿੰਕ ਅਤੇ ਪਤਾ ਨੈੱਟਵਰਕ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਦੇ ਮਾਲਕ ਰਾਹੀਂ ਲੱਭੋ, ਫਿਰ ਇਸ ਦੀ ਤੁਲਨਾ ਰਾਊਟਰ ਦੀ ਮੌਜੂਦਾ ਕਲਾਇੰਟ ਸੂਚੀ ਅਤੇ SSH ਕਲਾਇੰਟ ਵੱਲੋਂ ਵਰਤੇ ਪਤੇ ਨਾਲ ਕਰੋ। ਸੰਭਾਲਿਆ ਹੋਸਟਨਾਮ ਜਾਂ ਪੁਰਾਣੀ DHCP ਲੀਜ਼ ਹਫ਼ਤਿਆਂ ਤੱਕ ਕੱਲ੍ਹ ਦੇ ਟਿਕਾਣੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦੀ ਹੈ। ਫਿਰ ਪੱਕਾ ਕਰੋ ਕਿ sshd ਸਮਰੱਥ ਹੈ, ਕਿਸੇ ਮੌਜੂਦ ਪਤੇ 'ਤੇ ਸੁਣ ਰਿਹਾ ਹੈ, ਅਤੇ ਪ੍ਰਸ਼ਾਸਨ ਨੈੱਟਵਰਕ ਤੋਂ ਮਨਜ਼ੂਰ ਹੈ। Raspberry Pi ਦੀ SSH ਗਾਈਡ ਸਰਵਰ ਸਮਰੱਥ ਕਰਨ ਅਤੇ ਮੌਜੂਦਾ ਪਤੇ ਨਾਲ ਜੁੜਨ ਨੂੰ ਦੋ ਵੱਖਰੇ ਕਦਮ ਮੰਨਦੀ ਹੈ, ਅਤੇ ਨਵੀਂ Raspberry Pi OS ਇੰਸਟਾਲ SSH ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਬੰਦ ਰੱਖਦੀ ਹੈ।

ਹੋਸਟਨਾਮ ਨੂੰ ਕਿਸੇ ਹੋਰ ਮਸ਼ੀਨ ਵੱਲ ਮੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਬਦਲਵੀਂ ਇਮੇਜ ਆਪਣੀ ਚਾਬੀ ਨਾਲ ਆਉਂਦੀ ਹੈ, ਇਸ ਲਈ ਚੇਤਾਵਨੀ ਨੂੰ ਕਲਿੱਕ ਕਰਕੇ ਲੰਘਣ ਦੀ ਥਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਭਰੋਸਾ ਕਰਦੇ ਰਾਹ ਰਾਹੀਂ ਫਿੰਗਰਪ੍ਰਿੰਟ ਜਾਂਚੋ। ਚੇਤਾਵਨੀ ਮਿਟਾਉਣਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਅਸਥਾਈ ਪਤਾ-ਬਦਲਾਅ ਸਥਾਈ ਭਰੋਸੇ ਦੀ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦਾ ਹੈ। ਜੇ ਚਾਬੀ ਦੀ ਪੁੱਛ ਹੀ ਇੱਕੋ-ਇੱਕ ਲੱਛਣ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪਹੁੰਚ ਦਾ ਨਹੀਂ, ਪਛਾਣ ਦਾ ਸਵਾਲ ਵੇਖ ਰਹੇ ਹੋ।

ਬੋਰਡ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਦਾ ਰਾਹ ਲੱਭੋ

ਭੌਤਿਕ ਲਿੰਕ ਜੁੜਿਆ ਰਹਿੰਦਿਆਂ ਵੀ VPN ਰਾਹ ਦੀ ਚੋਣ ਬਦਲ ਸਕਦਾ ਹੈ, ਅਤੇ Pi ਦਾ ਚਾਲੂ, ਸੁਣਦਾ ਹੋਇਆ ਵੀ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੋਣਾ ਠੀਕ ਉਹੀ ਹਾਲਤ ਹੈ। ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਅਜਿਹੀ ਸੁਰੰਗ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਪ੍ਰਸ਼ਾਸਕ ਦਾ ਕਲਾਇੰਟ ਪਾਰ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਸਥਾਨਕ ਕੰਸੋਲ ਅਤੇ ਸੁਣਦਾ ਸਾਕਟ ਵਾਪਸੀ ਦੇ ਰਾਹ ਬਾਰੇ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ਪੱਕਾ ਕਰੋ ਕਿ ਕਿਹੜਾ ਇੰਟਰਫ਼ੇਸ ਜਵਾਬ ਢੋਂਦਾ ਹੈ ਅਤੇ ਕਿਹੜਾ ਗੇਟਵੇ ਚੁਣਦਾ ਹੈ। ਇਸ ਦੀ ਤੁਲਨਾ ਉਸ ਨੈੱਟਵਰਕ ਨਾਲ ਕਰੋ ਜਿਸ 'ਤੇ ਪ੍ਰਸ਼ਾਸਕ ਅਸਲ ਵਿੱਚ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਅਸਫਲਤਾ ਹੋਰ ਕਿਸੇ ਨਾਲੋਂ ਵੱਧ ਵਾਰ ਮਰੇ ਬੋਰਡ ਵਜੋਂ ਗ਼ਲਤ ਨਿਦਾਨ ਹੁੰਦੀ ਹੈ।

ਸਭ ਤੋਂ ਸਸਤੀ ਜਾਂਚ ਇਹ ਹੈ ਕਿ ਜਵਾਬ ਨੂੰ ਨਿਕਲਦਾ ਵੇਖੋ: Pi 'ਤੇ ਪੁੱਛੋ ਕਿ ਕਿਹੜਾ ਰਾਹ ਪ੍ਰਸ਼ਾਸਕ ਦਾ ਪਤਾ ਢੋਵੇਗਾ ਅਤੇ ਇਸ ਦੀ ਤੁਲਨਾ ਉਸ ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਕਰੋ ਜਿੱਥੋਂ ਬੇਨਤੀ ਆਈ ਸੀ। ਉੱਥੇ ਅਸੰਗਤੀ ਪੂਰੇ ਲੱਛਣ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਹੀ ਹੁਕਮ ਦਾ ਖ਼ਰਚ ਹੈ।

ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਹੱਦ, ਅਤੇ ਰੀਫਲੈਸ਼ ਕਦੋਂ ਸਹੀ ਹੈ

ਮੌਜੂਦਾ ਹਾਲਤ ਸੰਭਾਲਣ ਤੋਂ ਬਾਅਦ ਉਸ ਦੇ ਮਾਲਕ ਰਾਹੀਂ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਠੀਕ ਕਰੋ। ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਬਦਲਣਾ, ਫਾਇਰਵਾਲ ਖ਼ਾਲੀ ਕਰਨਾ ਅਤੇ ਸਥਿਰ ਪਤਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ—ਇਹ ਤਿੰਨ ਬਦਲਾਅ ਅਗਲੇ ਨਿਰੀਖਣ ਨੂੰ ਬੇਕਾਰ ਕਰ ਦਿੰਦੇ ਹਨ। ਜੇ ਸਬੂਤ VPN ਦੇ ਰਾਹ ਜਾਂ ਫਿਲਟਰਿੰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਉਸੇ ਕਲਾਇੰਟ ਦੀ ਆਪਣੀ ਰੋਕਣ ਜਾਂ ਮੁਰੰਮਤ ਦੀ ਵਿਧੀ 'ਤੇ ਮੁੜੋ, ਸਹਿਮਤ ਰਿਕਵਰੀ ਯੋਜਨਾ ਦੇ ਅੰਦਰ ਕੰਮ ਕਰੋ; ਨਿਯੰਤਰਿਤ ਤੁਲਨਾ ਅਤੇ ਤੁਸੀਂ ਸਮਝਾਇਆ ਨਾ ਹੋਇਆ ਹੋਸਟ 'ਤੇ ਸੁਰੱਖਿਆ ਬੰਦ ਕਰਨਾ—ਇਹ ਦੋ ਵੱਖਰੀਆਂ ਗੱਲਾਂ ਹਨ।

ਰੀਫਲੈਸ਼ ਇੱਕ ਸੁਚੇਤ ਰਿਕਵਰੀ ਚੋਣ ਹੈ, ਜੋ ਡੇਟਾ, ਪਛਾਣ ਅਤੇ ਅਸਫਲ ਹੋਏ ਪੜਾਅ ਨੂੰ ਸਮਝਣ ਤੋਂ ਬਾਅਦ ਲਈ ਜਾਂਦੀ ਹੈ। ਲਾਗਇਨ ਨਾ ਮਿਲਣਾ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਸ ਨੂੰ ਨਹੀਂ ਭੜਕਾਉਣਾ ਚਾਹੀਦਾ।

ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਦਾ ਰਿਕਾਰਡ Pi ਤੋਂ ਬਿਨਾਂ ਪੜ੍ਹੇ ਜਾ ਸਕਣ ਵਾਲੀ ਥਾਂ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਵਾਪਸ ਆਉਣ ਦਾ ਅਜਿਹਾ ਰਾਹ ਰੱਖੋ ਜੋ ਤੁਸੀਂ ਬਦਲਣ ਵਾਲੀ ਸੁਰੰਗ ਵਿੱਚੋਂ ਨ ਲੰਘੇ। ਫਿਰ ਕ੍ਰਮ ਨਾਲ ਕੰਮ ਕਰੋ: ਸਥਾਨਕ ਕੰਸੋਲ ਤੋਂ ਪੜਾਅ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਮੌਜੂਦਾ ਪਤਾ ਲੱਭੋ, ਲਿਸਨਰ ਅਤੇ ਉਸ ਦੀ ਨੀਤੀ ਜਾਂਚੋ, ਜਵਾਬ ਦਾ ਰਾਹ ਲੱਭੋ, ਅਤੇ ਇੱਕ ਹੀ ਚੀਜ਼ ਬਦਲੋ। ਜੇ ਬੋਰਡ ਕਦੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ, ਤਾਂ ਅਗਲਾ ਕਦਮ ਨੈੱਟਵਰਕ ਨਹੀਂ, ਰਿਕਵਰੀ ਦਸਤਾਵੇਜ਼ ਹੈ।