tickets #120067
closedDownloading of GNOME_Next.x86_64-43.1-Build22.189.iso differs, expected 1.4 GiB but downloaded 74 MiB, aborts prematurely often
80%
Description
Observation¶
openQA test in scenario opensuse-43.1-Gnome-Live-x86_64-gnome-live@64bit-4G fails in
GRU
with the error message
"Reason: Downloading "http://download.opensuse.org/repositories/GNOME:/Medias/images/iso/GNOME_Next.x86_64-43.1-Build22.189.iso" failed with: Size of "/var/lib/openqa/share/factory/iso/GNOME_Next.x86_64-43.1-Build22.189.iso" differs, expected 1.4 GiB but downloaded 74 MiB".
Reproducible¶
I can reproduce the error easily calling
wget http://download.opensuse.org/repositories/GNOME:/Medias/images/iso/GNOME_Next.x86_64-43.1-Build22.189.iso
on my notebook at home as well as another host which is not related to SUSE. DimStar could reproduce it depending on the host.
Fails since (at least) Build 22.189 (current job)
Expected result¶
Last good: 22.188 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by okurz about 2 years ago
- Tracker changed from action to tickets
- Project changed from openQA Tests (public) to openSUSE admin
- Subject changed from [admin] Downloading of GNOME_Next.x86_64-43.1-Build22.189.iso differs, expected 1.4 GiB but downloaded 74 MiB, aborts prematurely often to Downloading of GNOME_Next.x86_64-43.1-Build22.189.iso differs, expected 1.4 GiB but downloaded 74 MiB, aborts prematurely often
- Category deleted (
Bugs in existing tests)
Updated by favogt about 2 years ago
Wireshark shows the connection was cleanly closed by the server (FIN+ACK, FIN+ACK, ACK). It happens with and without TLS, with HTTP/1 as well as HTTP/2. How much data is downloaded changes on every try.
Updated by andriinikitin about 2 years ago
Since download.o.o doesn't actually serve big files - it is important to note to which actual url did redirect happen. Is it possible to increase verbosity of log in openQA?
(I tried the same from heroes network: first to check headers and was redirected to downloadcontent2.o.o (which happens when no mirrors are available), but then started download and was redirected to ftp.gwdg.de and download successfully completed in 15 sec.)
Updated by favogt about 2 years ago
andriinikitin wrote:
Since download.o.o doesn't actually serve big files - it is important to note to which actual url did redirect happen. Is it possible to increase verbosity of log in openQA?
(I tried the same from heroes network: first to check headers and was redirected to downloadcontent2.o.o (which happens when no mirrors are available), but then started download and was redirected to ftp.gwdg.de and download successfully completed in 15 sec.)
In all cases here the actual download was via http://downloadcontent2.opensuse.org/repositories/GNOME:/Medias/images/iso/GNOME_Next.x86_64-43.1-Build22.189.iso.
Updated by bmwiedemann about 2 years ago
It might be that the varnish cache there has trouble with such large files. Is there a way for MirrorCache to still redirect these to downloadcontent.o.o ?
Updated by bmwiedemann about 2 years ago
I'm now redirecting .iso, .raw.xz, .qcow2, etc files to downloadcontent.o.o via varnish
= https://github.com/bmwiedemann/varnishcontainer/commit/a32a6c002ee
Updated by favogt about 2 years ago
http://lists.varnish-cache.org/pipermail/varnish-misc/2016-April/024903.html
Apparently varnish might decide not to cache the file while it's being streamed and then just closes the connection shrug
Updated by bmwiedemann about 2 years ago
- Status changed from New to Resolved
- Assignee set to bmwiedemann
- % Done changed from 0 to 80
Let's count it as solved unless someone finds another problem.
Updated by okurz almost 2 years ago
- Related to action #123175: o3 fails to download images resulting in zero sized disk images/isos added