tickets #120067
closed
Downloading of GNOME_Next.x86_64-43.1-Build22.189.iso differs, expected 1.4 GiB but downloaded 74 MiB, aborts prematurely often
Added by okurz over 1 year ago.
Updated over 1 year ago.
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
Related issues
1 (1 open — 0 closed)
- Tracker changed from action to tickets
- Project changed from openQA Tests 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)
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.
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.)
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.
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 ?
- 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.
- Related to action #123175: o3 fails to download images resulting in zero sized disk images/isos added
Also available in: Atom
PDF