ਕੀ ਤੁਹਾਡੀ VPN ਬਾਈਨਰੀ ਇਸ CPU ਲਈ ਬਣੀ ਹੈ? ELF ਹੈਡਰ ਪੜ੍ਹੋ

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

ਵਰਗ ਅਤੇ ਮਸ਼ੀਨ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ

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

ਉਹੀ ਉਲਝਣ 64-ਬਿੱਟ ਲੇਬਲਾਂ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਜਿੱਥੇ aarch64 ਅਤੇ x86-64 ਸ਼ਬਦ ਦਾ ਆਕਾਰ ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਵੀ ਹਦਾਇਤ ਸਾਂਝੀ ਨਹੀਂ ਕਰਦੇ। ਇੱਕ 64-ਬਿੱਟ ਡਾਊਨਲੋਡ ਸੂਚੀਬੱਧ ਕਰਨ ਵਾਲਾ ਵਿਕਰੇਤਾ ਪੰਨਾ ਆਪਣਾ ਬਿਲਡ ਦੱਸਦਾ ਹੈ, ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਨਹੀਂ। ਪੰਨੇ ਦੇ ਕਾਲਮ ਸਿਰਲੇਖ ਦੀ ਬਜਾਏ ਫਾਈਲ ਦਾ ਹੈਡਰ ਜਾਂਚੋ।

readelf -h ./vendor-vpn
readelf -l ./vendor-vpn | head -20
file ./vendor-vpn

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

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

ਇੰਸਟਾਲਰ ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੈਡਰ ਪੜ੍ਹੋ

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

ਮਸ਼ੀਨ ਖੇਤਰ ਦੀ ਤੁਲਨਾ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਦੀ ਪੈਕੇਜ ਆਰਕੀਟੈਕਚਰ ਨਾਲ ਕਰੋ, ਬੋਰਡ ਦੇ ਮਾਰਕੀਟਿੰਗ ਨਾਮ ਨਾਲ ਨਹੀਂ। 32-ਬਿੱਟ ਯੂਜ਼ਰਲੈਂਡ ਚਲਾਉਂਦੇ 64-ਬਿੱਟ CPU ਨੂੰ 32-ਬਿੱਟ ਬਿਲਡ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਵੇਰਵਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਡਾਊਨਲੋਡ ਮੂਲ ਹੈ। ਬੋਰਡ ਦੀ ਸਮਰੱਥਾ ਸੀਮਾ ਨਹੀਂ ਹੈ; ਸਥਾਪਿਤ ਯੂਜ਼ਰਲੈਂਡ ਹੀ ਸੀਮਾ ਹੈ।

dpkg --print-architecture
uname -m
getconf LONG_BIT

ਪਹਿਲੀ ਕਮਾਂਡ ਦੱਸਦੀ ਹੈ ਕਿ ਸਿਸਟਮ ਕਿਸ ਆਰਕੀਟੈਕਚਰ ਲਈ ਪੈਕੇਜ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਮੁੱਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਾਕੀ ਦੋ ਕਰਨਲ ਅਤੇ ਸ਼ਬਦ ਦਾ ਆਕਾਰ ਦੱਸਦੀਆਂ ਹਨ, ਅਤੇ ਬਹੁ-ਆਰਕੀਟੈਕਚਰ ਸਥਾਪਨਾ ਵਿੱਚ ਉਹ ਯੂਜ਼ਰਲੈਂਡ ਨਾਲ ਵੱਖਰੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।

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

ਇੰਟਰਪ੍ਰੀਟਰ ਜਾਂਚੋ, ਸਿਰਫ਼ ਆਰਕੀਟੈਕਚਰ ਨਹੀਂ

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

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

readelf -l ./vendor-vpn | grep -A1 INTERP
ls -l /lib64/ld-linux-x86-64.so.2

ਪਹਿਲੀ ਕਮਾਂਡ ਬਾਈਨਰੀ ਵੱਲੋਂ ਮੰਗੇ ਇੰਟਰਪ੍ਰੀਟਰ ਮਾਰਗ ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੈ। ਦੂਜੀ ਜਾਂਚਦੀ ਹੈ ਕਿ ਉਹ ਮਾਰਗ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ, ਜੋ ਗਲਤ ਬਿਲਡ ਨੂੰ ਗੁੰਮ ਲੋਡਰ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

ਭਰੋਸੇਯੋਗ ਨਾ ਹੋਣ ਵਾਲੀ ਬਾਈਨਰੀ 'ਤੇ ਨਿਰਭਰਤਾ-ਸੂਚੀ ਨਾ ਚਲਾਓ, ਕਿਉਂਕਿ ਕੁਝ ਲਾਗੂਕਰਨ ਉਸ ਫਾਈਲ ਨੂੰ ਚਲਾ ਸਕਦੇ ਹਨ ਜਿਸਦੀ ਉਹ ਜਾਂਚ ਕਰਦੇ ਹਨ। ਜਾਂਚ ਨੂੰ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਰੱਖੋ ਅਤੇ ਅਸਮਰਥਿਤ ਬਿਲਡ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਲੋਡਰ ਸਿੰਮਲਿੰਕ ਜੋੜਨ ਦੇ ਲਾਲਚ ਨੂੰ ਰੋਕੋ।

ਤੱਥ ਹੱਥ ਵਿੱਚ ਰੱਖ ਕੇ ਬਿਲਡ ਮੰਗੋ

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

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