Update from 9.2.1 to 9.3 fails. Appears to be corrupted update URLs or something with Tailscale running on the box #7025
Comments
|
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:~$ |
|
Not sure how to interpret the output of 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 RAWAFAIK, 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 The 2nd error is when there is a parallel APT update running, or when one was uncleanly killed. Check e.g. via |
|
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: ***@***.***>
|
|
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: ***@***.***>
|
|
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 |
|
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 Checking your bug report upload, you use(d) Nala which generated rm /etc/apt/sources.list.d/nala-sources.listNala 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 |
|
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. |
|
Yeah, my impression for this and |
Creating a bug report/issue
Required Information
cat /boot/dietpi/.version9.2.1echo $G_DISTRO_NAME $G_RASPBIANBookowormuname -a6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linuxecho $G_HW_MODEL_NAMEor (EG: RPi3) Native_PCAdditional Information (if applicable)
echo $G_HW_UUID07b1b3b4-f600-4a9c-9216-d575fae1f66eSteps to reproduce
Expected behaviour
Actual behaviour
Extra details
The text was updated successfully, but these errors were encountered: