ਇੱਕ ਹੀ Pi ’ਤੇ Pi-hole ਅਤੇ VPN: ਕੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਜੇ ਵੀ ਸਮਰਥਿਤ ਹੈ?

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

ਸਮਰਥਨ ਰਿਲੀਜ਼ ਸ਼ਾਖਾ ਤੈਅ ਕਰਦੀ ਹੈ, ਪਰਿਵਾਰ ਦਾ ਨਾਮ ਨਹੀਂ

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

ਤੁਹਾਡੇ Pi ’ਤੇ ਅਜੇ ਬੂਟ ਹੋਣ ਵਾਲਾ ਪੁਰਾਣਾ ਇਮੇਜ ਸਮਰਥਨ ਦਾ ਸਬੂਤ ਨਹੀਂ। ਬੋਰਡ ਠੀਕ ਹੈ, ਪੈਕੇਜ ਸੂਚਕਾਂਕ ਪੁਰਾਣਾ ਹੈ, ਅਤੇ ਅਸੰਗਤੀ ਬਾਅਦ ਵਿੱਚ ਦਿਸਦੀ ਹੈ, ਜਦੋਂ ਇੰਸਟਾਲਰ ਅਜਿਹੀ ਨਿਰਭਰਤਾ ਖਿੱਚਦਾ ਹੈ ਜੋ ਰਿਲੀਜ਼ ਹੁਣ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦੀ।

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

ਬਾਈਨਰੀ ਟਾਰਗਿਟ ਨੂੰ ਆਪਣੀ ਵਰਤੋਂਕਾਰ-ਥਾਂ ਨਾਲ ਮਿਲਾਓ

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

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

ਜੇ ਉਹ ਦੋ ਆਰਕੀਟੈਕਚਰ ਲਾਈਨਾਂ ਨਹੀਂ ਮਿਲਦੀਆਂ, ਤੁਸੀਂ ਮਿਸ਼ਰਤ ਸੈੱਟਅੱਪ ’ਤੇ ਹੋ: ਇਕੱਲੇ Pi-hole ਲਈ ਚੱਲਣ ਵਾਲਾ, ਦੂਜੀ ਸੇਵਾ ਦੇਸੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਮੰਗੇ ਤਾਂ ਨਾਜ਼ੁਕ। ਸਾਫ਼ 64-ਬਿੱਟ ਇਮੇਜ ’ਤੇ ਦੁਬਾਰਾ ਫਲੈਸ਼ ਕਰਨਾ ਆਮ ਤੌਰ ’ਤੇ ਅਸੰਗਤੀ ਪੈਦਾ ਕਰਨ ਵਾਲੀ ਟੂਲਚੇਨ ਦੁਬਾਰਾ ਬਣਾਉਣ ਨਾਲੋਂ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ।

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

ਇੱਕ ਡੱਬਾ, ਦੋ ਸੇਵਾਵਾਂ, ਨੈੱਟਵਰਕ ਦਾ ਇੱਕ ਮਾਲਕ

ਪਹਿਲਾ ਪੈਕੇਜ ਚੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਪਤਾ-ਨਿਰਧਾਰਨ, ਰਿਜ਼ਾਲਵਰ ਅਤੇ ਟਨਲ ਕਿਸ ਦੇ ਹਨ, ਨਹੀਂ ਤਾਂ ਦੋ ਸੇਵਾਵਾਂ ਇੱਕੋ ਫਰਜ਼ ਦਾ ਦਾਅਵਾ ਕਰਨਗੀਆਂ ਅਤੇ ਕੋਈ ਵੀ ਸਾਫ਼ ਨਹੀਂ ਜਿੱਤੇਗੀ। Pi ਨੂੰ ਤੁਹਾਡੇ ਰਾਊਟਰ ਵੱਲੋਂ ਦਿੱਤੇ DHCP ਪੂਲ ਤੋਂ ਬਾਹਰ ਸਥਿਰ ਪਤਾ ਦਿਓ, ਅਤੇ ਟਨਲ ਨੂੰ ਉਸ ਦੇ ਆਪਣੇ ਸਬਨੈੱਟ ’ਤੇ ਰੱਖੋ: Pi ਲਈ 192.168.50.10 ਅਤੇ ਟਨਲ ਲਈ 10.42.0.0/24 ਇੱਕ ਚੱਲਣਯੋਗ ਵੰਡ ਹੈ, ਅਤੇ ਸੰਖਿਆਵਾਂ ਆਪ ਮਨਮਾਨੀ ਹਨ, ਜਿੰਨਾ ਚਿਰ ਉਹ ਤੁਹਾਡੇ ਰਾਊਟਰ ਵੱਲੋਂ ਪਹਿਲਾਂ ਹੀ ਦਿੱਤੇ ਜਾ ਰਹੇ ਨਾਲ ਨਹੀਂ ਟਕਰਾਉਂਦੀਆਂ। ਫਿਰ ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਕੰਪੋਨੈਂਟ ਪੋਰਟ 53 ’ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜੇ ਵਰਤਦੇ ਹੋ ਤਾਂ ਕਿਹੜਾ DHCP ਵੰਡਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਚਾਲੂ ਹੋਣ ਵੇਲੇ ਕਿਸ ਕੋਲ ਡਿਫ਼ਾਲਟ ਰੂਟ ਹੈ। ਸਕਰੀਨ ਰਹਿਤ ਇਮੇਜ ’ਤੇ ਉਹ ਆਖਰੀ ਕੰਮ NetworkManager ਜਾਂ systemd-networkd ਦਾ ਹੈ, ਅਤੇ ਅਜਿਹਾ ਪ੍ਰਦਾਤਾ ਕਲਾਇੰਟ ਸਥਾਪਤ ਕਰਨਾ ਜੋ ਰਿਜ਼ਾਲਵਰ ਕੌਨਫਿਗਰੇਸ਼ਨ ਵੀ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ ਉਹ ਰਾਹ ਹੈ ਜਿਸ ਨਾਲ ਲੋਕ ਜੀਵਤ ਟਨਲ ਅਤੇ ਮਰੀ DNS ਨਾਲ ਫਸ ਜਾਂਦੇ ਹਨ।

ਡੱਬਾ ਸਾਂਝਾ ਕਰਨਾ ਠੀਕ ਹੈ। ਭੂਮਿਕਾ ਸਾਂਝੀ ਕਰਨਾ ਨਹੀਂ। Pi-hole ਪੋਰਟ 53 ਦਾ ਇੱਕੋ-ਇੱਕ ਸਰੋਤਾ ਬਣਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਅਤੇ VPN ਡੀਮਨ ਆਪਣੀ DNS ਸੈਟਿੰਗ ਕਲਾਇੰਟਾਂ ਤੱਕ ਧੱਕਣਾ ਚਾਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਚੁਣੋ ਕਿ ਕਲਾਇੰਟਾਂ ਨੂੰ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਸ ’ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਦੂਜੇ ਨੂੰ ਰਾਹ ਤੋਂ ਹਟ ਕੇ ਰਹਿਣ ਲਈ ਸੰਰਚਿਤ ਕਰੋ।

ਜਿੱਥੇ ਹੋ ਸਕੇ ਪ੍ਰਬੰਧਕੀ ਮਾਰਗ ਟਨਲ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਜੇ ਰਿਜ਼ਾਲਵਰ ਅਤੇ ਟਨਲ ਇਕੱਠੇ ਫੇਲ੍ਹ ਹੋਣ, ਤੁਸੀਂ LAN ਪਤੇ ’ਤੇ SSH ਪਹੁੰਚਯੋਗ ਰੱਖਣਾ ਚਾਹੋਗੇ, ਅਤੇ ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪ੍ਰਬੰਧਨ ਸੇਵਾ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ’ਤੇ ਵੀ ਨਿਰਭਰ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।

ਅਗਲੇ ਅੱਪਗ੍ਰੇਡ ਨੂੰ ਚੋਣ ਦਾ ਹਿੱਸਾ ਬਣਾਓ

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

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

ਅੱਪਗ੍ਰੇਡ ਸਫਲ ਦਿਸੇ ਪਰ ਕੁਝ ਨਾ ਬਦਲੇ ਦਾ ਆਮ ਕਾਰਨ ਹੋਲਡ ਕੀਤੇ ਪੈਕੇਜ ਹਨ। ਹੋਲਡ ਜਾਣ-ਬੁੱਝ ਕੇ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਹਟਾਓ, ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਕਿਸ ਸੇਵਾ ਨੂੰ ਪਿਨ ਦੀ ਲੋੜ ਸੀ।

ਛਾਲ ਮਾਰਨ ਤੋਂ ਪਹਿਲਾਂ Pi-hole ਕੌਨਫਿਗਰੇਸ਼ਨ, ਸਥਿਰ ਲੀਜ਼ ਅਤੇ ਕੋਈ ਵੀ ਟਨਲ ਪਰੋਫਾਈਲ ਨਿਰਯਾਤ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਨਵੇਂ ਇਮੇਜ ’ਤੇ ਬਹਾਲ ਕਰ ਸਕਦੇ ਹੋ। ਛਾਲ ਤੋਂ ਬਾਅਦ ਆਮ ਕਲਾਇੰਟ DNS, ਟਨਲ ਪਿੱਛੇ ਦਾ ਨਿੱਜੀ ਸਰੋਤ, ਦੁਬਾਰਾ ਜੁੜਨਾ, ਅਤੇ ਗੇਟਵੇ ’ਤੇ ਕੋਈ ਵੀ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਪਰਖੋ। ਬੂਟ ਹੋ ਕੇ ping ਦਾ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਡੱਬਾ ਲਗਭਗ ਕੁਝ ਵੀ ਪਾਸ ਨਹੀਂ ਕੀਤਾ।

ਜਦੋਂ ਕੋਈ ਇੱਕ ਰਿਲੀਜ਼ ਦੋਵੇਂ ਸੇਵਾਵਾਂ ਨਾਲ ਨਹੀਂ ਮਿਲਦੀ

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

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

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