Update from 9.2.1 to 9.3 fails. Appears to be corrupted update URLs or something with Tailscale running on the box about dietpi

[binkleyz2]

Just to add, trying a normal apt update now fails as well

dietpi@Choad:~$ sudo apt update
Reading package lists... Done
E: Could not get lock /var/lib/apt/lists/lock. It is held by process 979 (apt-get)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to lock directory /var/lib/apt/lists/
dietpi@Choad:~$

[MichaIng]

Not sure how to interpret the output of nslookup. 100.100.100.100 seems to be the IP of the nameserver, not the resolved hostname. Seems to be common when it cannot resolve it at all.

Works fine here:

root@micha:~# getent ahosts ftp.us.debian.org
2620:0:861:2:208:80:154:139 STREAM ftp.us.debian.org
2620:0:861:2:208:80:154:139 DGRAM
2620:0:861:2:208:80:154:139 RAW
2600:3404:200:237::2 STREAM
2600:3404:200:237::2 DGRAM
2600:3404:200:237::2 RAW
2600:3402:200:227::2 STREAM
2600:3402:200:227::2 DGRAM
2600:3402:200:227::2 RAW
64.50.236.52    STREAM
64.50.236.52    DGRAM
64.50.236.52    RAW
64.50.233.100   STREAM
64.50.233.100   DGRAM
64.50.233.100   RAW
208.80.154.139  STREAM
208.80.154.139  DGRAM
208.80.154.139  RAW

AFAIK, by default, Tailscale does not change the DNS nameserver, does it? Of course should be easy to test by stopping/disconnecting it.

I wonder as well why you have https://deb.debian.org as well as http://ftp.us.debian.org requests. The first is a CDN, but since Stretch, APT uses its SRV records instead of following a HTTP redirect, so when having only https://deb.debian.org in sources.list, there should never be another Debian mirror visible in outputs.

The 2nd error is when there is a parallel APT update running, or when one was uncleanly killed. Check e.g. via htop whether there is really no other APT instance running, and in case remove the /var/lib/apt/lists/lock file manually.

[binkleyz2]

If tsilscale is running as a client, I think it would change the dns server setting to use its internal interface, here 100.100.100.100.  This is a remote box I’m helping a friend maintain while he’s out of country in order to leverage wireguard, so I’m a little leery about making networking changes, since if it gets messed up I won’t be able to reconnect for about a month or so when they’re back. For what it’s worth I have a more or less indentical seOn Apr 18, 2024, at 14:09, MichaIng ***@***.***> wrote: Not sure how to interpret the output of nslookup. 100.100.100.100 seems to be the IP of the nameserver, not the resolved hostname. Seems to be common when it cannot resolve it at all. Works fine here: ***@***.***:~# getent ahosts ftp.us.debian.org 2620:0:861:2:208:80:154:139 STREAM ftp.us.debian.org 2620:0:861:2:208:80:154:139 DGRAM 2620:0:861:2:208:80:154:139 RAW 2600:3404:200:237::2 STREAM 2600:3404:200:237::2 DGRAM 2600:3404:200:237::2 RAW 2600:3402:200:227::2 STREAM 2600:3402:200:227::2 DGRAM 2600:3402:200:227::2 RAW 64.50.236.52 STREAM 64.50.236.52 DGRAM 64.50.236.52 RAW 64.50.233.100 STREAM 64.50.233.100 DGRAM 64.50.233.100 RAW 208.80.154.139 STREAM 208.80.154.139 DGRAM 208.80.154.139 RAW AFAIK, by default, Tailscale does not change the DNS nameserver, does it? Of course should be easy to test by stopping/disconnecting it. I wonder as well why you have https://deb.debian.org as well as http://ftp.us.debian.org requests. The first is a CDN, but since Stretch, APT uses its SRV records instead of following a HTTP redirect, so when having only https://deb.debian.org in sources.list, there should never be another Debian mirror visible in outputs. The 2nd error is when there is a parallel APT update running, or when one was uncleanly killed. Check e.g. via htop whether there is really no other APT instance running, and in case remove the /var/lib/apt/lists/lock file manually. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[binkleyz2]

Sorry, hit send prematurely. I was saying that I have a more or less identical setup at home and didn’t run into this issue when upgrading from 9.2.1 to 9.3, so not sure what the issue is. I’m going to try and remove the alt lock and see if I can get past any of those errors manually and will get back to you. I’ve already rebooted so I doubt there is an active apt process running. On Apr 18, 2024, at 18:42, Sir SpamALot ***@***.***> wrote:If tsilscale is running as a client, I think it would change the dns server setting to use its internal interface, here 100.100.100.100.  This is a remote box I’m helping a friend maintain while he’s out of country in order to leverage wireguard, so I’m a little leery about making networking changes, since if it gets messed up I won’t be able to reconnect for about a month or so when they’re back. For what it’s worth I have a more or less indentical seOn Apr 18, 2024, at 14:09, MichaIng ***@***.***> wrote: Not sure how to interpret the output of nslookup. 100.100.100.100 seems to be the IP of the nameserver, not the resolved hostname. Seems to be common when it cannot resolve it at all. Works fine here: ***@***.***:~# getent ahosts ftp.us.debian.org 2620:0:861:2:208:80:154:139 STREAM ftp.us.debian.org 2620:0:861:2:208:80:154:139 DGRAM 2620:0:861:2:208:80:154:139 RAW 2600:3404:200:237::2 STREAM 2600:3404:200:237::2 DGRAM 2600:3404:200:237::2 RAW 2600:3402:200:227::2 STREAM 2600:3402:200:227::2 DGRAM 2600:3402:200:227::2 RAW 64.50.236.52 STREAM 64.50.236.52 DGRAM 64.50.236.52 RAW 64.50.233.100 STREAM 64.50.233.100 DGRAM 64.50.233.100 RAW 208.80.154.139 STREAM 208.80.154.139 DGRAM 208.80.154.139 RAW AFAIK, by default, Tailscale does not change the DNS nameserver, does it? Of course should be easy to test by stopping/disconnecting it. I wonder as well why you have https://deb.debian.org as well as http://ftp.us.debian.org requests. The first is a CDN, but since Stretch, APT uses its SRV records instead of following a HTTP redirect, so when having only https://deb.debian.org in sources.list, there should never be another Debian mirror visible in outputs. The 2nd error is when there is a parallel APT update running, or when one was uncleanly killed. Check e.g. via htop whether there is really no other APT instance running, and in case remove the /var/lib/apt/lists/lock file manually. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[binkleyz2]

Not sure why this worked, but clearing the lock file from the /var/lib/apt/lists and then rerunning a manual apt update and upgrade cycle, plus a reboot, seems to have resolved whatever the issue is, as I was able to rerun dietpi-update without issue, though it wound up doing nothing the third time around.. the system now shows as being on 9.3.0

I generated a new debug log if you'd like to see:

07b1b3b4-f600-4a9c-9216-d575fae1f66e

[MichaIng]

Tailscale can surely enforce a different DNS, but AFAIK it does not do OOTB, as it is usually used to connect to a particular remote device and access its own resources only, not to access to other devices or the internet through it. A different DNS would be used only to either get access to other remote LAN hosts via local hostnames (instead of IP addresses) or hiding DNS requests from insecure/untrusted networks, when you use the VPN for privacy reasons. Usually it should be possible to disable using the Tailscale/VPN provided DNS at the client only, hence if anything does not work, you can just revert the change.

However, looks like the issue with resolving this Debian hostname via 100.100.100.100 was temporary only.

Checking your bug report upload, you use(d) Nala which generated /etc/apt/sources.list.d/nala-sources.list, which contains 4 mirrors of the same Debian repository, including the one which caused the error, while /etc/apt/sources.list contains the Debian repository already, hence overall 5 times the same repo. As long as you do not actively use Nala, you should remove that.

rm /etc/apt/sources.list.d/nala-sources.list

Nala uses the multiple mirrors for its parallel APT package download feature. However, I know and tested such features, and they do not really speed up things, since the additional processing of leveraging the multiple servers and merging the downloads is usually more time consuming than what you can safe when using just the close mirror served by the deb.debian.org CDN. At least it makes sense to really compare apt-get with a single list with nala with the 4 additional lists, using e.g. the time command. Also the way the mirrors are selected by Nala and similar projects is not great: They check the ping time only, not the download bandwidth. Using the "fastest" mirror offered by these tools in my case always leads to a slower (single server) download, compared to what deb.debian.org serves, simply because ping time does not really matter, but the bandwidth does. What I do not understand is, why Nala writes these mirrors to /etc/apt/sources.list.d, while it does not actually use APT but causing APT to take much longer etc. It could just use an own config file that does not disturb APT. In this regards, apt-fast does it a better way, but still was overall slower than plain APT on all my tests. So much for my lecture against using such APT wrappers/alternatives, as plain Debian APT does everything too well already 😄.

[binkleyz2]

Tell you what, Nala has NEVER seemed like it was faster, but I got caught up in some hype about it and installed it. Used it a few times but it seemed to cause more issues than it theoretically solved, mainly in its habit of wanting to pull down more packages than are really necessary AND causing a kernel update to nearly fail in the process.

So, yes, will wind up removing Nala from the two servers I have it installed on.

I think you can consider this issue closed if you're also amenable to that.

[MichaIng]

Yeah, my impression for this and apt-fast was also that people started using it because of course it sounds reasonable at first, that parallel downloads speed up things. But no one really seem to have benchmarked it, at least in case of apt-fast until I started a topic and benchmarked it myself with many scenarios. There was only one user where it was faster, because the single APT mirror he used got him 200k download speed only. If there is really no faster APT mirror available at a location, then of course Nala and apt-fast will be a benefit, but these seem to be edge cases. Often the simpler/plain solution remains the best.