VPN ਇੰਸਟਾਲਰ 32-ਬਿਟ ਕਹਿੰਦਾ ਹੈ: ਇਸ ਦੀ ਬਜਾਏ ELF ਹੈਡਰ ਦੇਖੋ

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

ਕਲਾਸ ਸ਼ਬਦ ਦਾ ਆਕਾਰ ਕਹਿੰਦੀ ਹੈ, ਮਸ਼ੀਨ ਨਿਰਦੇਸ਼ ਸਮੂਹ

Linux ELF ਸੰਦਰਭ ਫਾਈਲ ਹੈਡਰ ਵਿੱਚ ਕਲਾਸ ਫੀਲਡ ਅਤੇ ਮਸ਼ੀਨ ਫੀਲਡ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਕਲਾਸ ਦੱਸਦੀ ਹੈ ਕਿ ਫਾਈਲ 32-ਬਿਟ ਜਾਂ 64-ਬਿਟ ਰੂਪ ਵਰਤਦੀ ਹੈ; ਮਸ਼ੀਨ ਦੱਸਦੀ ਹੈ ਕਿ ਇਹ ਕਿਹੜੇ ਨਿਰਦੇਸ਼ ਸਮੂਹ ਲਈ ਬਣਾਈ ਗਈ। 32-ਬਿਟ x86 build ਅਤੇ 32-ਬਿਟ ARM build ਪਹਿਲੇ ਉੱਤੇ ਸਹਿਮਤ ਅਤੇ ਦੂਜੇ ਉੱਤੇ ਵੱਖਰੇ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ ਸਹੀ ਸ਼ਬਦ ਆਕਾਰ ਦਾ ਵਾਅਦਾ ਕਰਨ ਵਾਲਾ ਲੇਬਲ ਵੀ ਅਜਿਹਾ ਕੋਡ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਪ੍ਰੋਸੈਸਰ ਡੀਕੋਡ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਪੜ੍ਹਨ ਯੋਗ ਤੀਜਾ ਮੁੱਲ ਮੰਗਿਆ ਗਿਆ ਇੰਟਰਪ੍ਰੀਟਰ ਹੈ, ਜਿਸਦਾ ਨਾਮ ਪ੍ਰੋਗਰਾਮ ਹੈਡਰ ਤਦ ਲੈਂਦੇ ਹਨ ਜਦੋਂ ਬਾਈਨਰੀ ਇੱਕ ਘੋਸ਼ਿਤ ਕਰਦੀ ਹੈ।

readelf -h -- ./vendor-vpn
readelf -l -- ./vendor-vpn
readelf -d -- ./vendor-vpn | grep NEEDED

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

ਇਹ ਕਰਨਲ ਤੋਂ ਕਿਹੜਾ ਇੰਟਰਪ੍ਰੀਟਰ ਮੰਗਦਾ ਹੈ

ਇੰਟਰਪ੍ਰੀਟਰ ਘੋਸ਼ਿਤ ਕਰਨ ਵਾਲੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫਾਈਲ ਕਰਨਲ ਤੋਂ ਇੱਕ ਖਾਸ ਲੋਡਰ ਪਥ ਮੰਗਦੀ ਹੈ। ਜਦੋਂ ਉਹ ਲੋਡਰ ਨਹੀਂ ਹੁੰਦਾ, ਤੁਹਾਡੀ ਦੱਸੀ ਫਾਈਲ ਠੀਕ ਉੱਥੇ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਸ਼ੁਰੂ ਹੋਣਾ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਥੇ ਹੀ ਲੋਕ ਫੈਸਲਾ ਕਰਦੇ ਹਨ ਕਿ ਡਾਊਨਲੋਡ ਖਰਾਬ ਹੈ, ਜਦੋਂ ਕਿ ਅਸਲ ਜਵਾਬ ਅਜਿਹਾ ਲੋਡਰ ਹੈ ਜੋ ਵੰਡ ਨਹੀਂ ਦਿੰਦੀ।

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

file --brief ./vendor-vpn

ਡਾਊਨਲੋਡ ਨੂੰ ਪੈਕੇਜ ਆਰਕੀਟੈਕਚਰ ਨਾਲ ਮਿਲਾਓ

ਵੰਡਾਂ ਦੀ ਪੈਕੇਜ ਆਰਕੀਟੈਕਚਰ ਉਹੀ ਫ਼ਰਕ ਆਪਣੀ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ ਏਨਕੋਡ ਕਰਦੀ ਹੈ, ਅਤੇ ਵਿਕਰੇਤਾ ਦਾ ਸਹਾਇਤਾ ਬਿਆਨ ਉਸੇ ਸ਼ਬਦਾਵਲੀ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ। ਤੁਹਾਡੇ ਪੈਕੇਜ ਮੈਨੇਜਰ ਵੱਲੋਂ ਦੱਸੇ ਮੁੱਲ ਦੀ ਤੁਲਨਾ ਵਿਕਰੇਤਾ ਵੱਲੋਂ ਦਸਤਾਵੇਜ਼ ਕੀਤੇ ਮੁੱਲ ਨਾਲ ਕਰੋ, ਫਾਈਲ ਨਾਮ ਨਾਲ ਮਾਰਕੀਟਿੰਗ ਲੇਬਲ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੀ ਬਜਾਏ। ਮੁਸ਼ਕਲ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਜੋੜੇ amd64 ਬਨਾਮ arm64, ਅਤੇ armhf ਬਨਾਮ armel ਹਨ, ਕਿਉਂਕਿ ਹਰ ਜੋੜਾ ਡਾਊਨਲੋਡ ਸੂਚੀ ਵਿੱਚ ਬਦਲਣਯੋਗ ਦਿਸਦਾ ਹੈ। x64 ਜਾਂ ia32 ਨਾਲ ਖ਼ਤਮ ਹੋਣ ਵਾਲਾ ਫਾਈਲ ਨਾਮ build ਟਾਰਗੇਟ ਦੱਸਦਾ ਹੈ, ਉਸਨੂੰ ਰੱਖਣ ਵਾਲੀ ਮਸ਼ੀਨ ਨਹੀਂ।

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

dpkg --print-architecture

ENOEXEC ਅਤੇ ENOENT ਵੱਖਰੀਆਂ ਫੇਲ੍ਹਤਾਵਾਂ ਹਨ

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

ENOEXEC ਦਾ ਅਰਥ ਹੈ ਰੂਪ ਪਛਾਣਿਆ ਨਹੀਂ ਗਿਆ: ਗ਼ਲਤ ਆਰਕੀਟੈਕਚਰ, ਗ਼ਲਤ ਕਲਾਸ ਜਾਂ ਅਜਿਹੀ ਚੀਜ਼ ਜੋ ਬਿਲਕੁਲ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਨਹੀਂ। ELF ਫਾਈਲ ਉੱਤੇ ENOENT ਦਾ ਅਰਥ ਆਮ ਤੌਰ ’ਤੇ ਇੰਟਰਪ੍ਰੀਟਰ ਦਾ ਨਾ ਹੋਣਾ ਹੈ, ਭਾਵੇਂ ਤੁਹਾਡੀ ਮੰਗੀ ਫਾਈਲ ਮੌਜੂਦ ਹੈ। ਉਹੀ ENOENT ਇਹ ਵੀ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਸਕ੍ਰਿਪਟ ਦਾ ਇੰਟਰਪ੍ਰੀਟਰ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਸਕ੍ਰਿਪਟ ਦੀ ਪਹਿਲੀ ਲਾਈਨ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਸੁਨੇਹਾ ਪਰਤ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਹਰ “ਨਹੀਂ ਮਿਲਿਆ” ਨੂੰ ਗੁੰਮ ਸੰਰਚਨਾ ਮੰਨਣਾ ਜਾਂਚ ਨੂੰ ਗ਼ਲਤ ਦਿਸ਼ਾ ਵੱਲ ਭੇਜਦਾ ਹੈ। ਟਿਕਟ ਵਿੱਚ ਗ਼ਲਤੀ ਦਾ ਮੁੱਲ ਉੱਧਰਤ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਆਸਪਾਸ ਦੇ ਵਾਕ ਨਾਲੋਂ ਮੁੜ ਕਹਿਣ ਵਿੱਚ ਬਿਹਤਰ ਟਿਕਦਾ ਹੈ।

ਬਾਈਨਰੀ ਸ਼ੁਰੂ ਨਾ ਹੋਣ ’ਤੇ ਕੀ ਨਾ ਕਰੋ

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

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