[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1848556] Autopkgtest regression report (qemu/1:4.0+dfsg-0ubuntu9.2)
From: |
Ubuntu SRU Bot |
Subject: |
[Bug 1848556] Autopkgtest regression report (qemu/1:4.0+dfsg-0ubuntu9.2) |
Date: |
Fri, 22 Nov 2019 14:56:30 -0000 |
All autopkgtests for the newly accepted qemu (1:4.0+dfsg-0ubuntu9.2) for eoan
have finished running.
The following regressions have been reported in tests triggered by the package:
ganeti/2.16.0-5ubuntu1 (ppc64el)
Please visit the excuses page listed below and investigate the failures,
proceeding afterwards as per the StableReleaseUpdates policy regarding
autopkgtest regressions [1].
https://people.canonical.com/~ubuntu-archive/proposed-
migration/eoan/update_excuses.html#qemu
[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions
Thank you!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1848556
Title:
qemu-img check failing on remote image in Eoan
Status in QEMU:
Fix Released
Status in qemu package in Ubuntu:
Fix Released
Status in qemu source package in Eoan:
Fix Committed
Status in qemu source package in Focal:
Fix Released
Bug description:
Ubuntu SRU Template:
[Impact]
* There is fallout due to changes in libcurl that affect qemu and might
lead to a hang.
* Fix by backporting the upstream fix
[Test Case]
* If you have network just run
$ qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
* Without network, install apache2, and get a complex qemu file (like a
cloud image) onto the system. Then access the file via apache http but
not localhost (that would work)
[Regression Potential]
* The change is local to the libcurl usage of qemu, so that could be
affected. But then this is what has been found to not work here, so I'd
expect not too much trouble. But if so then in the curl usage (which
means disks on http)
[Other Info]
* n/a
---
The "qemu-img check" function is failing on remote (HTTP-hosted)
images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
version 1:3.1+dfsg-2ubuntu3.5, the following worked:
$ /usr/bin/qemu-img check
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
No errors were found on the image.
19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
Image end offset: 514064384
The 10.193.37.117 server holds an Apache server that hosts the cloud
images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
0ubuntu9, the same command never returns. (I've left it for up to an
hour with no change.) I'm able to wget the image from the same server
and installation on which qemu-img check fails. I've tried several
.img files on the server, ranging from Bionic to Eoan, with the same
results with all of them.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1848556/+subscriptions
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug 1848556] Autopkgtest regression report (qemu/1:4.0+dfsg-0ubuntu9.2),
Ubuntu SRU Bot <=