Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Absent first try for Focal: tdm-trinity_14.0.9~pre32-0ubuntu20.04+1_amd64.deb
Felix Miata composed on 2020-06-23 19:15 (UTC-0400):
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Absent first try for Focal: tdm-trinity_14.0.9~pre32-0ubuntu20.04+1_amd64.deb
Absent first try for Buster: kcalc-trinity_14.0.8-0debian10.0.0+0_amd64.deb
Felix Miata composed on 2020-06-23 23:08 (UTC-0400):
Felix Miata composed on 2020-06-23 19:15 (UTC-0400):
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Absent first try for Focal: tdm-trinity_14.0.9~pre32-0ubuntu20.04+1_amd64.deb
Absent first try for Buster: kcalc-trinity_14.0.8-0debian10.0.0+0_amd64.deb
Absent first try for Bullseye: kipi-plugins-trinity_14.0.9~pre19-0debian11.0.0...
On Friday 10 of July 2020 05:05:15 Felix Miata wrote:
Felix Miata composed on 2020-06-23 23:08 (UTC-0400):
Felix Miata composed on 2020-06-23 19:15 (UTC-0400):
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Absent first try for Focal: tdm-trinity_14.0.9~pre32-0ubuntu20.04+1_amd64.deb
Absent first try for Buster: kcalc-trinity_14.0.8-0debian10.0.0+0_amd64.deb
Absent first try for Bullseye: kipi-plugins-trinity_14.0.9~pre19-0debian11.0.0...
Hi Felix,
I tried to look for accesses to the specified package in the log on the primary redirector, and I see these entries there:
/var/log/apache2/ppa-access.log:93.197.35.80 - - [10/Jul/2020:01:35:29 +0000] "GET /trinity/deb/trinity-sb/pool/main-r14/k/kipi-plugins-trinity/kipi-plugins-trinity_14.0.9~pre19-0debian11.0.0+0~a_amd64.deb HTTP/1.1" 302 340 "-" "Wget/1.20.1 (linux-gnu)" /var/log/apache2/ppa-access.log:24.75.148.33 - - [10/Jul/2020:02:57:05 +0000] "GET /trinity-sb/pool/main-r14/k/kipi-plugins-trinity/kipi-plugins-trinity_14.0.9%7epre19-0debian11.0.0%2b0%7ea_amd64.deb HTTP/1.1" 302 0 "-" "Debian APT-HTTP/1.3 (2.1.6)" /var/log/apache2/ppa-access.log:24.75.148.33 - - [10/Jul/2020:02:57:19 +0000] "GET /trinity/deb/trinity-sb/pool/main-r14/k/kipi-plugins-trinity/kipi-plugins-trinity_14.0.9%7epre19-0debian11.0.0%2b0%7ea_amd64.deb HTTP/1.1" 302 322 "-" "Debian APT-HTTP/1.3 (2.1.6)" /var/log/apache2/ppa-access.log:24.75.148.33 - - [10/Jul/2020:02:58:31 +0000] "GET /trinity-sb/pool/main-r14/k/kipi-plugins-trinity/kipi-plugins-trinity_14.0.9%7epre19-0debian11.0.0%2b0%7ea_amd64.deb HTTP/1.1" 302 653 "-" "Debian APT-HTTP/1.3 (2.1.6)" /var/log/apache2/ppa-access.log:24.75.148.33 - - [10/Jul/2020:02:58:31 +0000] "GET /trinity/deb/trinity-sb/pool/main-r14/k/kipi-plugins-trinity/kipi-plugins-trinity_14.0.9%7epre19-0debian11.0.0%2b0%7ea_amd64.deb HTTP/1.1" 302 298 "-" "Debian APT-HTTP/1.3 (2.1.6)"
Cheers
Felix Miata composed on 2020-07-09 23:05 (UTC-0400):
Felix Miata composed on 2020-06-23 23:08 (UTC-0400):
Felix Miata composed on 2020-06-23 19:15 (UTC-0400):
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Absent first try for Focal: tdm-trinity_14.0.9~pre32-0ubuntu20.04+1_amd64.deb
Absent first try for Buster: kcalc-trinity_14.0.8-0debian10.0.0+0_amd64.deb
Absent first try for Bullseye: kipi-plugins-trinity_14.0.9~pre19-0debian11.0.0...
trinity-filesystem for 14.0.8 for openSUSE 15.1 this time around, but still not found after multiple retries, which means 14.0.8 is running on filesystem 14.0.7.
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Whole thread starter: http://trinity-devel.pearsoncomputing.net/?0::16292
Still happening (current Buster & 14.0.0 - 8->9 on host big41). I can't remember the last time it didn't happen.
On Sun November 1 2020 18:47:54 Felix Miata via tde-devels wrote:
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Whole thread starter: http://trinity-devel.pearsoncomputing.net/?0::16292
Still happening (current Buster & 14.0.0 - 8->9 on host big41). I can't remember the last time it didn't happen.
TTBOMK debian11 is not in 14.0.x on the mirrors, only PSB. I presume debian11 is also in TDE testing. But PSB, and presumably testing, no longer references 14.0.8. It's all 14.0.9 and will presumably soon be 14.0.10.
(1) Did you do apt-get update first?
(2) What please is in your /etc/apt/sources.list ?
--Mike
Mike Bird via tde-devels composed on 2020-11-01 19:33 (UTC-0800):
On Sun November 1 2020 18:47:54 Felix Miata via tde-devels wrote:
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Whole thread starter: http://trinity-devel.pearsoncomputing.net/?0::16292
Still happening (current Buster & 14.0.0 - 8->9 on host big41). I can't remember the last time it didn't happen.
TTBOMK
????
debian11 is not in 14.0.x on the mirrors, only PSB. I presume debian11 is also in TDE testing. But PSB, and presumably testing, no longer references 14.0.8. It's all 14.0.9 and will presumably soon be 14.0.10.
(1) Did you do apt-get update first?
I did apt update first.
(2) What please is in your /etc/apt/sources.list ?
# deb http://mirrors.us.kernel.org/debian/ buster main
deb http://ftp.debian.org/debian buster main contrib non-free #deb-src http://mirrors.us.kernel.org/debian/ buster main
deb http://security.debian.org/ buster/updates main contrib non-free #deb-src http://security.debian.org/ buster/updates main
deb http://ftp.debian.org/debian buster-updates main contrib non-free #deb-src http://mirrors.us.kernel.org/debian/ buster-updates main
deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian buster main #deb-src http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian buster main #deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0.0/debia... buster main
# Debian Multimedia deb http://www.deb-multimedia.org buster main non-free #deb-src http://www.deb-multimedia.org buster main non-free
On Sun November 1 2020 20:03:59 Felix Miata via tde-devels wrote:
TTBOMK
????
https://www.urbandictionary.com/define.php?term=TTBOMK
(2) What please is in your /etc/apt/sources.list ?
# deb http://mirrors.us.kernel.org/debian/ buster main
deb http://ftp.debian.org/debian buster main contrib non-free #deb-src http://mirrors.us.kernel.org/debian/ buster main
deb http://security.debian.org/ buster/updates main contrib non-free #deb-src http://security.debian.org/ buster/updates main
deb http://ftp.debian.org/debian buster-updates main contrib non-free #deb-src http://mirrors.us.kernel.org/debian/ buster-updates main
deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian buster main #deb-src http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian buster main #deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0.0/debi an buster main
# Debian Multimedia deb http://www.deb-multimedia.org buster main non-free #deb-src http://www.deb-multimedia.org buster main non-free
Sorry, I still don't see the problem, Felix. Would you please "apt-cache policy libkexiv2-3-trinity".
Also:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Was that copied-pasted or hand-copied, because I think the character after trinity should be an underline not a hyphen?
Thanks,
--Mike
Mike Bird via tde-devels composed on 2020-11-01 20:33 (UTC-0800):
On Sun November 1 2020 20:03:59 Felix Miata via tde-devels wrote:
Sorry, I still don't see the problem, Felix. Would you please "apt-cache policy libkexiv2-3-trinity".
libkexiv2-3-trinity: Installed: (none) Candidate: 4:14.0.9-0debian10.0.0+0 Version table: 4:14.0.9-0debian10.0.0+0 500 500 http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian buster/main amd64 Packages
Also:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Was that copied-pasted or hand-copied, because I think the character after trinity should be an underline not a hyphen?
That's from a 4 month old OP. I wouldn't have anything but a speculation that most likely it was C&P.
It seems like you're missing the point of the thread. What's happening is that when I do an upgrade, 100% of the packages download, minus 1 random trinity package. Then apt quits with a message about not finding the random TDE package. I then repeat the previous command, and it (seems that it) finds that one package and completes the upgrade command (most of the time). Based on the apt-cache command output (candidate, not installed), it seems like it's not finding the package it's claiming to find on the second try.
On Sun November 1 2020 21:00:39 Felix Miata wrote:
Also:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Was that copied-pasted or hand-copied, because I think the character after trinity should be an underline not a hyphen?
That's from a 4 month old OP. I wouldn't have anything but a speculation that most likely it was C&P.
It seems like you're missing the point of the thread. What's happening is that when I do an upgrade, 100% of the packages download, minus 1 random trinity package. Then apt quits with a message about not finding the random TDE package. I then repeat the previous command, and it (seems that it) finds that one package and completes the upgrade command (most of the time). Based on the apt-cache command output (candidate, not installed), it seems like it's not finding the package it's claiming to find on the second try.
Sorry Felix. There's no way I can figure what happened to you four months ago.
Since the problem is repeatable for you I would expect more people to encounter it if it was a server or mirror problem. It might be something in your firewall or ISP or something else. There are hundreds of possibilities. For example your ISP's DNS server may be rate limiting you.
As this happens to you regularly I suggest you make a packet capture and try to determine from that the reason for the download failure.
--Mike
Mike Bird via tde-devels composed on 2020-11-01 23:13 (UTC-0800):
Sorry Felix. There's no way I can figure what happened to you four months ago.
4 months ago doesn't matter except in that I probably mentioned it here first then. It started considerably before then, probably before I moved, which brought me an entirely new ISP (Spectrum -> FiberVision) and a lot more speed then, and another new one (Zito) and still more speed since, when FiberVision was purchased by Zito.
# speedtest-cli ... Testing download speed....................................... Download: 100.84 Mbit/s...
Lots more speed than I'm used to. Upgrading Fedora from 33 to Rawhide a little while ago took less than 45 minutes, including the cloning and incident configuration adjustments.
As this happens to you regularly I suggest you make a packet capture and try to determine from that the reason for the download failure.
I don't know anything about packet capture, and even if I did, what it might be that I'd be looking for. Right after I send this I'll be cloning today's problem Buster to another partition for a dist-upgrade to Bullseye. Maybe you could suggest something more helpful than adjusting sources.list. Reproduction AFAIR may only happen when there is a TDE version upgrade to apply. There's usually plenty of time to forget specifics between incidents.
On Sun November 1 2020 18:47:54 Felix Miata via tde-devels wrote:
Still happening (current Buster & 14.0.0 - 8->9 on host big41). I can't remember the last time it didn't happen.
On Mon November 2 2020 00:15:46 Felix Miata via tde-devels wrote:
There's usually plenty of time to forget specifics between incidents.
(1) I'm trying to understand how often this happens?
(2) Also could you please provide a console log of the error, preferably from the apt update all the way through the failed upgrade.
(3) Is there a reason you believe this to be a TDE problem rather than an apt problem or communication problem?
Thanks,
--Mike
Mike Bird via tde-devels composed on 2020-11-02 00:58 (UTC-0800):
On Sun November 1 2020 18:47:54 Felix Miata via tde-devels wrote:
Still happening (current Buster & 14.0.0 - 8->9 on host big41). I can't remember the last time it didn't happen.
On Mon November 2 2020 00:15:46 Felix Miata via tde-devels wrote:
There's usually plenty of time to forget specifics between incidents.
(1) I'm trying to understand how often this happens?
IIRc, whenever I upgrade an installation for the first time after a new TDE release. Time between upgrades can be anywhere from a week to a month to 4, 5, 6 months or more.
(2) Also could you please provide a console log of the error, preferably from the apt update all the way through the failed upgrade.
What exactly is "console log"?
http://fm.no-ip.com/Tmp/Linux/TDE/typescript-big41-bullseye-distupgrade.html
If you know how to purge the junk from typescript files, I'd appreciate hearing about it.
(3) Is there a reason you believe this to be a TDE problem rather than an apt problem or communication problem?
Never happens except with some TDE package. I don't recall ATM if it's only with .debs, or if it happens with .rpms too.
Thanks Felix.
Hi Slávek,
Can you find any reason for this on 37.205.10.16 server sometime between 2020-11-02 04:19:40-05:00 and 2020-11-02 04:28:15-05:00
Err:30 http://mirror.ppa.trinitydesktop.org/trinity-sb bullseye/main-r14
amd64 kbstate-trinity amd64 4:14.0.9-0debian11.0.0+0~a
Error reading from server. Remote end closed connection [IP: 37.205.10.16
80]
(It was successful on a second attempt during that time window.)
Downloading IP might have been 24.75.154.218.
--Mike
On Monday 02 of November 2020 14:47:02 Mike Bird via tde-devels wrote:
Thanks Felix.
Hi Slávek,
Can you find any reason for this on 37.205.10.16 server sometime between 2020-11-02 04:19:40-05:00 and 2020-11-02 04:28:15-05:00
Err:30 http://mirror.ppa.trinitydesktop.org/trinity-sb bullseye/main-r14
amd64 kbstate-trinity amd64 4:14.0.9-0debian11.0.0+0~a
Error reading from server. Remote end closed connection [IP: 37.205.10.16
80]
(It was successful on a second attempt during that time window.)
Downloading IP might have been 24.75.154.218.
--Mike ____________________________________________________ tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinityd esktop.org
Hi,
if I calculate the time zone correctly, it should be the accesses obtained by this filter:
fgrep 24.75.154.218 /var/log/apache2/ppa-{access,error}.log | grep "02/Nov/2020:09" >apache-access-felix.log
At first glance, I don't see anything strange there. When I filtered the records with codes 200 and 302, the output was empty. The output from the above filter is in the attachment.
Cheers
Thanks Slávek.
OK, so here's the state of play if someone smarter than me has any ideas.
Felix is downloading at 10.4MB/s - over 80Mbps. Could the server think this is a DOS attack? I'm 99% certain there's not a transparent proxy involved.
--Mike
Felix during apt upgrade (from multiple repos in parallel) sees: =================================== Get:22 http://mirror.ppa.trinitydesktop.org/trinity-sb bullseye/main-r14 amd64 juk-trinity amd64 4:14.0.9-0debian11.0.0+0~a [699 kB] [33m 31% [22 juk-trinity 46.3 kB/699 kB 7%] [316 python3.8-minimal 14.0 kB/1,863 kB 1%] [Waiting for headers] 9,609 kB/s 33s[0m
Err:30 http://mirror.ppa.trinitydesktop.org/trinity-sb bullseye/main-r14 amd64 kbstate-trinity amd64 4:14.0.9-0debian11.0.0+0~a Error reading from server. Remote end closed connection [IP: 37.205.10.16 80] [33m 31% [22 juk-trinity 305 kB/699 kB 44%] [316 python3.8-minimal 14.0 kB/1,863 kB 1%] [Connecting to mirror.ppa.trinitydesktop.org (37.205.10.16)] 9,609 kB/s 33s[0m[33m 31% [316 python3.8-minimal 16.9 kB/1,863 kB 1%] [Connecting to mirror.ppa.trinitydesktop.org (37.205.10.16)] 9,609 kB/s 33s[0m
Get:23 http://mirror.ppa.trinitydesktop.org/trinity-sb bullseye/main-r14 amd64 kaboodle-trinity amd64 4:14.0.9-0debian11.0.0+0~a [120 kB] [33m 31% [23 kaboodle-trinity 65.5 kB/120 kB 55%] [316 python3.8-minimal 16.9 kB/1,863 kB 1%] [Connecting to mirror.ppa.trinitydesktop.org (37.205.10.16)] 9,609 kB/s 33s[0m[33m ===================================
Meanwhile the server sees only: =================================== /var/log/apache2/ppa-access.log:24.75.154.218 - - [02/Nov/2020:09:20:19 +0000] "GET /trinity-sb/pool/main-r14/t/tdemultimedia-trinity/juk-trinity_14.0.9-0debian11.0.0%2b0%7ea_amd64.deb HTTP/1.1" 302 0 "-" "Debian APT-HTTP/1.3 (1.8.2.1)" /var/log/apache2/ppa-access.log:24.75.154.218 - - [02/Nov/2020:09:20:19 +0000] "GET /trinity-sb/pool/main-r14/t/tdemultimedia-trinity/kaboodle-trinity_14.0.9-0debian11.0.0%2b0%7ea_amd64.deb HTTP/1.1" 302 0 "-" "Debian APT-HTTP/1.3 (1.8.2.1)" ===================================
On Monday 02 of November 2020 16:46:00 Mike Bird via tde-devels wrote:
Thanks Slávek.
OK, so here's the state of play if someone smarter than me has any ideas.
Felix is downloading at 10.4MB/s - over 80Mbps. Could the server think this is a DOS attack? I'm 99% certain there's not a transparent proxy involved.
On mirror.ppa.trinitydesktop.org (37.205.10.16), which is not preceded by a foreign firewall, there is apache with a redirector that handles requests. The apache log shows the IP address from Felix, so yes, it should confirm that the requests are coming from his address, not hidden behind some transparent proxy. I have no idea if there could be some hidden UTM inspecting traffic and acting weird.
For example, on UPC (now Vodafone) I observe that downloaded packages are sometimes damaged. Usually the size is correct, but the checksum is incorrect. I observed this behavior when there was a UTM in the way that behaved poorly when downloading using HTTP/1.1. When HTTP/1.0 was used, it behaved correctly. However, even in this case I see the requests in the apache log from the correct IP address :(
In any case, this is clearly a different case from Felix's.
I don't see any unusual network load on the VPS. The bandwidth on a VPS should provide 300 MBps, however this is not so important because the file download redirector refers to mirrors. Currently, our VPS is located on node9.prg, which does not show any significant load:
https://prasiatko.vpsfree.cz/munin/prg.vpsfree.cz/node9.prg.vpsfree.cz/index...
This really doesn't look like a DOS attack. Any ideas what to verify?
--Mike
Felix during apt upgrade (from multiple repos in parallel) sees:
Get:22 http://mirror.ppa.trinitydesktop.org/trinity-sb bullseye/main-r14 amd64 juk-trinity amd64 4:14.0.9-0debian11.0.0+0~a [699 kB] [33m 31% [22 juk-trinity 46.3 kB/699 kB 7%] [316 python3.8-minimal 14.0 kB/1,863 kB 1%] [Waiting for headers] 9,609 kB/s 33s[0m
Err:30 http://mirror.ppa.trinitydesktop.org/trinity-sb bullseye/main-r14 amd64 kbstate-trinity amd64 4:14.0.9-0debian11.0.0+0~a Error reading from server. Remote end closed connection [IP: 37.205.10.16 80] [33m 31% [22 juk-trinity 305 kB/699 kB 44%] [316 python3.8-minimal 14.0 kB/1,863 kB 1%] [Connecting to mirror.ppa.trinitydesktop.org (37.205.10.16)] 9,609 kB/s 33s[0m[33m 31% [316 python3.8-minimal 16.9 kB/1,863 kB 1%] [Connecting to mirror.ppa.trinitydesktop.org (37.205.10.16)] 9,609 kB/s 33s[0m
Get:23 http://mirror.ppa.trinitydesktop.org/trinity-sb bullseye/main-r14 amd64 kaboodle-trinity amd64 4:14.0.9-0debian11.0.0+0~a [120 kB] [33m 31% [23 kaboodle-trinity 65.5 kB/120 kB 55%] [316 python3.8-minimal 16.9 kB/1,863 kB 1%] [Connecting to mirror.ppa.trinitydesktop.org (37.205.10.16)] 9,609 kB/s 33s[0m[33m ===================================
Meanwhile the server sees only:
/var/log/apache2/ppa-access.log:24.75.154.218 - - [02/Nov/2020:09:20:19 +0000] "GET /trinity-sb/pool/main-r14/t/tdemultimedia-trinity/juk-trinity_14.0.9-0de bian11.0.0%2b0%7ea_amd64.deb HTTP/1.1" 302 0 "-" "Debian APT-HTTP/1.3 (1.8.2.1)" /var/log/apache2/ppa-access.log:24.75.154.218 - - [02/Nov/2020:09:20:19 +0000] "GET /trinity-sb/pool/main-r14/t/tdemultimedia-trinity/kaboodle-trinity_14.0. 9-0debian11.0.0%2b0%7ea_amd64.deb HTTP/1.1" 302 0 "-" "Debian APT-HTTP/1.3 (1.8.2.1)" =================================== ____________________________________________________ tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinityd esktop.org
Cheers
Slávek Banko via tde-devels wrote:
I don't see any unusual network load on the VPS. The bandwidth on a VPS should provide 300 MBps, however this is not so important because the file download redirector refers to mirrors. Currently, our VPS is located on node9.prg, which does not show any significant load:
https://prasiatko.vpsfree.cz/munin/prg.vpsfree.cz/node9.prg.vpsfree.cz/index...
This really doesn't look like a DOS attack. Any ideas what to verify?
interesting thread, but no time to look closer - however I've seen packets being dropped silently by firewalls, routers and switches and strange things happening as result - things like this here, same if routes do not work properly (but it does not look like this), so if it is not a firewall or the server itself, it might be something on the network - tcpdump/wireshark when this happens might help.
Also I remember Felix has many machines - no idea what infrastructure he has, but it could be related to that fact.
I don't have the bandwidth at home to emulate Felix so ...
I ran tests of "apt clean; apt update; apt --download-only install --install-recommends tde-trinity; apt clean" twice each on three different VPSs, each in a different data center in a different US state. Prior to testing the VPSs had no X Windows and no TDE other than the keyring. Debian Buster. Speeds for the TDE portion of the downloads appeared to be roughly 10-35MBps (not bps).
With TDE r14.0.x I encountered no download errors.
I ran the six tests again, this time against TDE PSB. Again no download errors on TDE but I did get one download failure one time from Debian:
E: Failed to fetch
http://ftp.us.debian.org/debian/pool/main/p/poppler-data/poppler-data_0.4.9-...
Undetermined Error [IP: 208.80.154.15 80] E: Some files failed to download
I conclude this is a network or apt problem rather than a TDE problem. It occurs more frequently for Felix so it might be a local router problem such as NAT table exhaustion.
I looked at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=stable;package=apt and there are HUNDREDS of open bugs. I couldn't find one that matched this but I don't see any point in trying to report an intermittent issue that might be a communication problem rather than an apt bug.
I don't think there's anything more that TDE can do. The workaround is to hit up-arrow then enter if download fails.
--Mike
On Tuesday 03 of November 2020 01:35:58 Mike Bird via tde-devels wrote:
I don't have the bandwidth at home to emulate Felix so ...
I ran tests of "apt clean; apt update; apt --download-only install --install-recommends tde-trinity; apt clean" twice each on three different VPSs, each in a different data center in a different US state. Prior to testing the VPSs had no X Windows and no TDE other than the keyring. Debian Buster. Speeds for the TDE portion of the downloads appeared to be roughly 10-35MBps (not bps).
With TDE r14.0.x I encountered no download errors.
I ran the six tests again, this time against TDE PSB. Again no download errors on TDE but I did get one download failure
one time from Debian:
E: Failed to fetch
http://ftp.us.debian.org/debian/pool/main/p/poppler-data/poppler-data_0. 4.9-2_all.deb
Undetermined Error [IP: 208.80.154.15 80] E: Some files failed to download
I conclude this is a network or apt problem rather than a TDE problem. It occurs more frequently for Felix so it might be a local router problem such as NAT table exhaustion.
I looked at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=stable;package=apt and there are HUNDREDS of open bugs. I couldn't find one that matched this but I don't see any point in trying to report an intermittent issue that might be a communication problem rather than an apt bug.
I don't think there's anything more that TDE can do. The workaround is to hit up-arrow then enter if download fails.
--Mike ____________________________________________________
If this happens frequently for Felix, it may be a good idea to split the update so that first apt calls "apt upgrade --download-only", and only when everything is successfully downloaded does the package upgrade continue.
Cheers
Slávek Banko via tde-devels composed on 2020-11-03 09:36 (UTC+0100):
Mike Bird via tde-devels wrote:
I don't think there's anything more that TDE can do. The workaround is to hit up-arrow then enter if download fails.
If this happens frequently for Felix, it may be a good idea to split the update so that first apt calls "apt upgrade --download-only", and only when everything is successfully downloaded does the package upgrade continue.
NAICT, that's exactly what apt/apt-get/aptitude is/are doing. They exit right after the failed package fetch info shows up onscreen. I just up-arrow, <enter>, it fetches the missing package, and installs everything.
Felix Miata wrote:
Slávek Banko via tde-devels composed on 2020-11-03 09:36 (UTC+0100):
Mike Bird via tde-devels wrote:
I don't think there's anything more that TDE can do. The workaround is to hit up-arrow then enter if download fails.
If this happens frequently for Felix, it may be a good idea to split the update so that first apt calls "apt upgrade --download-only", and only when everything is successfully downloaded does the package upgrade continue.
NAICT, that's exactly what apt/apt-get/aptitude is/are doing. They exit right after the failed package fetch info shows up onscreen. I just up-arrow, <enter>, it fetches the missing package, and installs everything. -- Evolution as taught in public schools, like religion, is based on faith, not on science.
We and partners had delay in a project beginning this year because one firewall had firmware bug and was dropping packages which resulted in breaking up connections at random. As in the past years it was not about the quality but profit only, I can imagine we'll have all kind of issues at lower levels in the future. A lot of time will be spent in such debugging session - I am not a prophet but it is logical to assume. It might be good for linux based open source devices though.
On 2020/11/02 11:33 AM, Mike Bird via tde-devels wrote:
TTBOMK debian11 is not in 14.0.x on the mirrors, only PSB. I presume debian11 is also in TDE testing. But PSB, and presumably testing, no longer references 14.0.8. It's all 14.0.9 and will presumably soon be 14.0.10.
Debian 11 (bullseye) is not officially release as stable, so there will not be official packages for it. NEvertheless, both PSB and PTB packages are available.
Cheers Michele
On Monday 02 of November 2020 03:47:54 Felix Miata via tde-devels wrote:
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Whole thread starter: http://trinity-devel.pearsoncomputing.net/?0::16292
Still happening (current Buster & 14.0.0 - 8->9 on host big41). I can't remember the last time it didn't happen.
By the way, the link to the thread in the new web archive provides a view of the whole thread:
https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydeskt...
Cheers
Felix Miata composed on 2020-11-01 21:47 (UTC-0500):
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Whole thread starter: http://trinity-devel.pearsoncomputing.net/?0::16292
Still happening (current Buster & 14.0.0 - 8->9 on host big41). I can't remember the last time it didn't happen.
Yet another host, ab85m, Ubuntu 20.04: failed to fetch libtqt3-integration-trinity_14.0.10~pre5blah... error reading from server. Remote end closed the connection [IP: 37.205.10.16 80]
As usual, solved by
up enter
Felix Miata composed on 2020-11-18 20:38 (UTC-0500):
Felix Miata composed on 2020-11-01 21:47 (UTC-0500):
Felix Miata composed on 2020-06-18 21:48 (UTC-0400):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
Whole thread starter: http://trinity-devel.pearsoncomputing.net/?0::16292
Still happening (current Buster & 14.0.0 - 8->9 on host big41). I can't remember the last time it didn't happen.
Yet another host, ab85m, Ubuntu 20.04: failed to fetch libtqt3-integration-trinity_14.0.10~pre5blah... error reading from server. Remote end closed the connection [IP: 37.205.10.16 80]
As usual, solved by
up enter
Yet another host, fi965, Bullseye: failed to fetch kmenuedit-trinity_14.0.10~pre5blah... error reading from server. Remote end closed the connection [IP: 37.205.10.16 80]
As usual, solved merely by
up enter
Felix Miata composed on 2020-06-18 21:48 (UTC-0500):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
This just happened with Mageia 7 with 2 packages, trinity-tdelibs & lib64avahi-tqt1, the former going from 14.0.7 to 14.0.9, apparently having happened before but ignored by me.
To recap, all other packages were fetched on first 'urpmi --auto-select', but the two failed, and were successfully fetched simply by rerunning 'urpmi --auto-select'.
Felix Miata composed on 2020-11-17 01:26 (UTC-0500):
Felix Miata composed on 2020-06-18 21:48 (UTC-0500):
Does Debian have any kind of configuration option that can make 'apt upgrade' try harder to download all packages instead of all except one that for whatever mirror failure reason fails, and halting the upgrade process because that one file didn't download? It seems typical here that one package, any package, isn't found on the trinity mirrors on the first pass, but on second invocation of apt upgrade, that one package is fetched, and the entire apt upgrade continues to completion.
The latest case was just now, sb on Bullseye:
libkexiv2-3-trinity-14.0.8-0debian11.0.0+0~a_amd64.deb
This just happened with Mageia 7 with 2 packages, trinity-tdelibs & lib64avahi-tqt1, the former going from 14.0.7 to 14.0.9, apparently having happened before but ignored by me.
To recap, all other packages were fetched on first 'urpmi --auto-select', but the two failed, and were successfully fetched simply by rerunning 'urpmi --auto-select'.
On same PC as just above, but with Mageia 8, urpmi reports cannot install trinity-tdelibs because of unsatisfied /etc/ssl/certs/ca-bundle.crt, a symlink to /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt, which has a current timestamp and 250508 bytes. This I know I've see before. I suppose this may be related to having to use Mageia 7 repos to run TDE in this fully functional perpetual pre-release 8, and urpmi claiming MD5SUM from mirrors.ppa.trinitydesktop.org is invalid.
-
deloptes -
Felix Miata -
Felix Miata -
Michele Calgaro -
Mike Bird -
Slávek Banko