libvirt-bin doesn't regenerate apparmor cache in postinst

Bug #1707400 reported by Bob Pickett on 2017-07-29
142
This bug affects 61 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Medium
Unassigned
Trusty
Low
Andreas Hasenack
Xenial
Medium
Andreas Hasenack

Bug Description

[Impact]
TL;DR
libvirt-bin stops working after a release upgrade from Trusty to Xenial. Other scenarios possible.

Workaround after it breaks:
sudo touch /etc/apparmor.d/{usr.lib.libvirt.virt-aa-helper,usr.sbin.libvirtd}
sudo apt install --reinstall libvirt-bin

The libvirt-bin package in Trusty and Xenial reloads the apparmor profile in postinst, but without taking into account possible apparmor caches. It uses this call:

apparmor_parser -r <profile> || true

instead of what dh_apparmor and every other package is using nowadays, and is also recommended in the apparmor_parser manpage:

apparmor_parser -r -T -W <profile> || true

Where:
-T: skip reading any existing cache
-W: write out the cache

The apparmor_parser(8) manpage has this to say about how the apparmor cache is considered:

"""
By default, if a profile's cache is found in the location specified by --cache-loc and the timestamp is newer than the profile, it will be loaded from the cache.
"""

That is reasonable behaviour. After all, the cache is generated from the profile file. If someone wants to change the profile, it will be edited and thus have a more recent timestamp than the cache.

Furthermore, since the libvirt-bin packages in Trusty and Xenial do not specify -W, that is, they do not write out a cache file, then using just "-r" to load a profile is consistent.

But if something outside the libvirt-bin package decides to generate apparmor caches, then we might have a problem.

One such scenario is an Ubuntu release upgrade from Trusty to Xenial. Here is what was observed during such an upgrade (here is a pastebin: http://pastebin.ubuntu.com/25222966/. It shows libvirt apparently restarting successfully at the end, but it didn't):
- new libvirt-bin is unpacked
- new apparmor is unpacked
- new apparmor is set up. This sets up new abstractions, and also generates an apparmor cache for all profiles. This is new behaviour: the trusty apparmor package does not generate caches. Crucial: at this time, the old libvirt-bin apparmor profiles are installed still.
- new libvirt-bin is setup. This installs the new apparmor profile for this version of libvirt-bin. Crucial: the profile timestamp is not $(now), but whatever timestamp the file has inside the debian package. Which is *older* than the cache generated above
- libvirt-bin reloads the apparmor profile with -r. apparmor picks the cached profile because its timestamp is newer than the profile
- libvirt-bin fails to start

The fix is to call apparmor_parser with -T and -W in postinst. That will always invalidate the apparmor cache and generate a new one based on the current contents of the profile file.

Another fix would be do use dh_apparmor to install the two profiles libvirt-bin uses. In fact, debian/rules even have those calls, but they are commented. We believe that doing that is a more invasive fix, and that just adding the -T and -W options to the existing apparmor_parser call has the same effect and is less invasive, being more in the spirit of an SRU to an LTS release.

In Yakkety and Zesty, dh_apparmor is used, but the call with just "-r" remains in postinst. That was only removed in artful, where we finally only rely on dh_apparmor for this.

[Test Case]

 * install libvirt-bin
 * check it's working. This command should work and return an empty list of virtual machines:
   - sudo virsh list
 * break the apparmor profile /etc/apparmor.d/usr.sbin.libvirtd by editing it and commenting the line "network inet stream," like this:
   #network inet stream,
 * generate a cache file for it:
   - sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.libvirtd
 * purge libvirt-bin:
    - sudo apt purge libvirt-bin
 * install libvirt-bin back. It will fail to start the service:
    - sudo apt install libvirt-bin
 * verify that virsh list fails to connect to libvirt:
    - sudo virsh list
 * verify that service status shows the servicce being down:
    - sudo service libvirt-bin status

If you repeat that last step with the fixed package, either after having encountered the error, or by running all steps again and skipping installing the broken package, the service will start correctly.

[Regression Potential]
In a nutshell, this fix does introduce a change in behaviour. But it's a change that other packages have already adopted (just grep for apparmor_parser in /var/lib/dpkg/info/*.postinst), and shouldn't be user visible. I also believe it's a less surprising behaviour than what we currently have.

I took the option of fixing one specific apparmor_parser call instead of introducing dh_apparmor in d/rules, which would have been a much bigger change, even though that's what we have in Yakkety and later.

Cache corruption seems to be dealt with by the tool correctly, although I haven't experimented with it. The documentation says:
"""
The default behaviour of the parser is to check if a cached version of a profile exists and if it does it attempt (sic) to load it into the kernel. If that load is rejected, then the parser will attempt to rebuild the cache file, and load again.
"""

[Other Info]
This bug affects Trusty too, but we haven't had a report about it yet. The only case so far is this release upgrade to Xenial.

Only administrators using Trusty who for one reason or another decide to use apparmor caches for libvirt *could* be affected, depending on the sequence of events. The test case shows such a possible scenario.

Since the change is simple, I included it for Trusty as well and will leave it up to the SRU team to decide if it's worth fixing there or not. I would perfectly understand if it is deemed not worthy for Trusty at this time.

Related branches

Bob Pickett (bpick) wrote :
tags: removed: need-duplicate-check
Andreas Hasenack (ahasenack) wrote :

I see apparmor DENIED messages:
[132257.005761] audit: type=1400 audit(1501333532.752:74): apparmor="DENIED" operation="create" profile="/usr/sbin/libvirtd" pid=32586 comm="libvirtd" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create"

And errors from libvirt trying to connect which match the refusals from apparmor:
Jul 29 09:05:14 hostname libvirtd[32055]: cannot connect to netlink socket with protocol 0: Permission denied

I tried reproducing this issue on a fresh xenial VM, but libvirt with apparmor worked just fine. I tried the original version from xenial, and the update. The profile is in enforcing mode, and all I get are STATUS messages in syslog.

Have you modified any apparmor file in /etc/apparmor.d by any chance?

One last thing to try is to upgrade from trusty to xenial, and then install libvirt-bin.

Changed in libvirt (Ubuntu):
status: New → Incomplete
Andreas Hasenack (ahasenack) wrote :

Ok, I reproduced the problem with the following steps:

- install trusty
- install libvirt-bin
- remove (not purge!) libvirt-bin, so that the two libvirt apparmor profiles remain in /etc/apparmor.d/
- upgrade to xenial
- install libvirt-bin. It fails (see attached apt-install-libvirt-bin.txt)

Andreas Hasenack (ahasenack) wrote :

"apt install libvirt-bin" output

Andreas Hasenack (ahasenack) wrote :

dmesg output. I cleared dmesg (dmesg -c) just before the apt install libvirt-bin command.

Andreas Hasenack (ahasenack) wrote :

Full /var/log/syslog. It will also contain logs from before the upgrade to xenial.

Andreas Hasenack (ahasenack) wrote :

/etc/apparmor.d/usr.sbin.libvirtd from when the machine was on trusty

Andreas Hasenack (ahasenack) wrote :

/etc/apparmor.d/usr.lib.libvirt.virt-aa-helper from when the machine was on trusty

Andreas Hasenack (ahasenack) wrote :

Xenial's usr.lib.libvirt.virt-aa-helper

Andreas Hasenack (ahasenack) wrote :

Xenial's usr.sbin.libvirtd

Andreas Hasenack (ahasenack) wrote :

Debugging note: just replacing the apparmor profiles with the xenial ones didn't fix it, something else is going on.

I have two xenial systems now: one is called "15-89", and the other is "22-96".

15-89 was deployed with trusty, and later upgraded to xenial. It's showing this bug.
22-96 was fresh installed as xenial, and is not showing this bug.

Both have libvirt 1.3.1-1ubuntu10.11

Changed in libvirt (Ubuntu):
status: Incomplete → Confirmed
Andreas Hasenack (ahasenack) wrote :

Hello @bpick,

could you please run the following commands and see if they fix your system:

sudo apparmor_parser -T -W -r /etc/apparmor.d/usr.sbin.libvirtd
sudo apparmor_parser -T -W -r /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
sudo apt -f install

They did fix my trusty-upgraded-to-xenial system.

Thanks

Andreas Hasenack (ahasenack) wrote :

The bug is here in libvirt's postinst:
    for p in usr.sbin.libvirtd usr.lib.libvirt.virt-aa-helper ; do
        profile="/etc/apparmor.d/$p"
        if [ -f "$profile" ] && aa-status --enabled 2>/dev/null; then
            apparmor_parser -r "$profile" || true
        fi
    done

It should call apparmor_parser with -T and -W to a) avoid; and b) regenerate the apparmor cache.
For instance, that's how all the other profiles I have installed on this box are reloaded in postinst:
isc-dhcp-client.postinst: apparmor_parser -r -T -W "$APP_PROFILE" || true
libvirt-bin.postinst: apparmor_parser -r "$profile" || true
lxc-common.postinst: apparmor_parser -r -T -W "$APP_PROFILE" || true
lxd.postinst: apparmor_parser -r -T -W "$APP_PROFILE" || true
rsyslog.postinst: apparmor_parser -r -T -W "$APP_PROFILE" || true
snapd.postinst: apparmor_parser -r -T -W "$APP_PROFILE" || true
tcpdump.postinst: apparmor_parser -r -T -W "$APP_PROFILE" || true

Andreas Hasenack (ahasenack) wrote :

Yakkety onwards is fixed, because it uses dh_apparmor which calls apparmor_parser with the correct extra parameters in the postinst script. Xenial still has the bug.

Andreas Hasenack (ahasenack) wrote :

Debian bug about starting to use the dh_apparmor helper: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792426

tags: added: server-next
Bob Pickett (bpick) wrote :

This is the response I received when I ran the commands:

user@user1:~$ sudo apparmor_parser -T -W -r /etc/apparmor.d/usr.sbin.libvirtd
user@user1:~$ sudo apparmor_parser -T -W -r /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
user@user1:~$ sudo apt -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  akonadi-backend-mysql akonadi-server gccgo gccgo-6 gstreamer0.10-gconf
  gstreamer0.10-plugins-good gstreamer0.10-pulseaudio gstreamer0.10-x
  kde-config-mailtransport kdepim-runtime kdepimlibs-data
  kdepimlibs-kio-plugins libakonadi-calendar4 libakonadi-contact4
  libakonadi-kde4 libakonadi-kmime4 libakonadiprotocolinternals1 libavcodec56
  libavresample2 libavutil54 libcdaudio1 libdevmapper-event1.02.1 libenca0
  libgo5 libgo9 libgrantlee-templates5 libgrantlee-textdocument5 libkabc4
  libkcalcore4 libkcalutils4 libkf5akonadiagentbase5 libkf5akonadicalendar5
  libkf5akonadicontact5 libkf5akonadicore-bin libkf5akonadicore5
  libkf5akonadimime5 libkf5akonadinotes5 libkf5akonadiprivate5
  libkf5akonadiwidgets5 libkf5alarmcalendar5 libkf5calendarcore5
  libkf5calendarutils5 libkf5contacts-data libkf5contacts5 libkf5emoticons-bin
  libkf5emoticons-data libkf5emoticons5 libkf5gapi-data libkf5gapicalendar5
  libkf5gapicontacts5 libkf5gapicore5 libkf5gapitasks5 libkf5holidays-data
  libkf5holidays5 libkf5identitymanagement5 libkf5imap5 libkf5itemmodels5
  libkf5ldap5 libkf5mailtransport-data libkf5mailtransport5 libkf5mbox5
  libkf5mime5 libkf5pimtextedit5 libkholidays4 libkidletime4 libkldap4
  libkmime4 libkolab1 libkolabxml1v5 libkpimidentities4 libkpimtextedit4
  libkpimutils4 libkresources4 libkunitconversion4 libllvm3.8 libllvm3.8:i386
  liblvm2app2.2 libmailtransport4 libmicroblog4 libopenjpeg2 libprison0
  libqjson0 libslv2-9 libsoprano4 libswscale3 libsyndication4 libvirtodbc0
  libx264-142 libxerces-c3.1 linux-headers-4.4.0-34
  linux-headers-4.4.0-34-generic mysql-client-core-5.7 mysql-server-core-5.7
  pmount python-aptdaemon python-aptdaemon.gtk3widgets python-debian
  python-defer python-slowaes soprano-daemon streamripper virtuoso-minimal
  virtuoso-opensource-6.1-bin virtuoso-opensource-6.1-common
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up libvirt-bin (1.3.1-1ubuntu10.11) ...
Setting up libvirt-bin dnsmasq configuration.
N: Ignoring file '50unattended-upgrades.ucf-dist' in directory '/etc/apt/apt.conf.d/' as it has an invalid filename extension

Andreas Hasenack (ahasenack) wrote :

Good, libvirt-bin installed fully now. Thanks for getting back to us, we will try to get a fix out to the affected ubuntu releases.

Changed in libvirt (Ubuntu):
importance: Undecided → Medium
description: updated
summary: - package libvirt-bin 1.3.1-1ubuntu10.11 failed to install/upgrade:
- subprocess installed post-installation script returned error exit status
- 1
+ libvirt-bin doesn't regenerate apparmor cache in postinst
Changed in libvirt (Ubuntu):
status: Confirmed → Fix Released
description: updated
description: updated
description: updated
description: updated
Changed in libvirt (Ubuntu Trusty):
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in libvirt (Ubuntu Xenial):
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in libvirt (Ubuntu Trusty):
status: New → In Progress
Changed in libvirt (Ubuntu Xenial):
status: New → In Progress
Changed in libvirt (Ubuntu Trusty):
importance: Undecided → Low
Changed in libvirt (Ubuntu Xenial):
importance: Undecided → Medium
description: updated
description: updated
ChristianEhrhardt (paelzer) wrote :

Thanks Andreas for working on this while I was away.
I'm now reviewing the changes that you proposed and would move them to the right repo (libvirt packaging is in a git repo of its own).

FWIW - not only did we start to use dh_apparmor in yakkety, in artful we also dropped a lot more of the custom code around these now fully relying on dh_apparmor which should help to behave the same way across packages.

Also I think I've seen the issue reported for things after trusty, like vivid and such but they always timed out not reproducible. Even more I'm happy that you tracked it down this time.
I agree that there are not so much upgraders "to trusty" but even upgrades in trusty could trigger it - so I think the SRU there is worth it.

I'll search for the old bugs and dup them here for better overall tracking.

ChristianEhrhardt (paelzer) wrote :

Reviewed and Approved.
I sponsored the uploads into [TX]-unapproved.
You already had a sufficient SRU Template.
So now this is ready for the SRU Team to evaluate it.

Robie Basak (racb) wrote :

Excellent work in tracking this down!

> Since the change is simple, I included it for Trusty as well and will leave it up to the SRU team to decide if it's worth fixing there or not. I would perfectly understand if it is deemed not worthy for Trusty at this time.

Seems to me that if a security update needs to introduce an apparmor profile change, then this fix is important even for Trusty.

Hello Bob, or anyone else affected,

Accepted libvirt into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/1.3.1-1ubuntu10.13 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in libvirt (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-xenial
Changed in libvirt (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed-trusty
Robie Basak (racb) wrote :

Hello Bob, or anyone else affected,

Accepted libvirt into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/1.2.2-0ubuntu13.1.21 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Bob Pickett (bpick) wrote :

During ./configure, this is how it ended:

checking for yajl_parse_complete in -lyajl... no
checking for yajl_tree_parse in -lyajl... no
configure: error: You must install the libyajl library & headers to compile libvirt
user@user1:~/Desktop/libvirt-1.2.2$

If this helps.

Andreas Hasenack (ahasenack) wrote :

@bpick, any particular reason you tried to build from source? You should grab the binary package that's in the proposed repository. Or at least the source package and build that: it would have told you which dependencies are needed to perform a build.

Bob Pickett (bpick) wrote :

I followed the instructions in #22 above. I followed the INSTALL directions from the package.

I am not a super Ubuntu user. I'm just following directions.

Andreas Hasenack (ahasenack) wrote :

Detailed instructions on how to use -proposed are here: https://wiki.ubuntu.com/Testing/EnableProposed

To help testing, you could follow the [test case] from the bug in the first comment, confirm the error, and then repeat it fresh but using the package from proposed, and confirm it's fixed.

So, just before the step where it says "install libvirt-bin", you would enable the proposed repository and run "sudo apt update" followed by "sudo apt install libvirt-bin"

A simple way to enable proposed is to just add this line to /etc/apt/sources.list:

deb http://archive.ubuntu.com/ubuntu/ xenial-proposed restricted main multiverse universe

(replace "xenial" with trusty if you are testing on trusty). Then run "sudo apt update". Just DO NOT run "apt upgrade" or "apt dist-upgrade", or accept upgrades offered by your desktop, because the proposed repository contains many other packages that are under testing, not just libvirt.

I suggest to perform the test in a LXD container or virtual machine, so you don't "pollute" your main machine with it.

ChristianEhrhardt (paelzer) wrote :
Download full text (29.3 KiB)

Tested trusty:
TL;DR working as it should now - properly regenerating "over" the cache and thereby working correctly.

$ lxc launch ubuntu-daily:t trusty-bug-1707400 --profile default --profile kvm
Creating trusty-bug-1707400
Starting trusty-bug-1707400
[✓]─[paelzer@lap:~]──[60423]──[19:09 Mi Aug 09]──
$ lxc exec trusty-bug-1707400 bash
root@trusty-bug-1707400:~# apt update
Get:1 http://security.ubuntu.com trusty-security InRelease [65.9 kB]
Ign http://archive.ubuntu.com trusty InRelease
Get:2 http://archive.ubuntu.com trusty-updates InRelease [65.9 kB]
Hit http://archive.ubuntu.com trusty-backports InRelease
Hit http://archive.ubuntu.com trusty Release.gpg
Hit http://archive.ubuntu.com trusty Release
Get:3 http://security.ubuntu.com trusty-security/main Sources [139 kB]
Get:4 http://security.ubuntu.com trusty-security/universe Sources [61.0 kB]
Get:5 http://archive.ubuntu.com trusty-updates/main Sources [402 kB]
Get:6 http://security.ubuntu.com trusty-security/main amd64 Packages [648 kB]
Get:7 http://security.ubuntu.com trusty-security/universe amd64 Packages [179 kB]
Get:8 http://security.ubuntu.com trusty-security/main Translation-en [347 kB]
Get:9 http://archive.ubuntu.com trusty-updates/restricted Sources [6331 B]
Get:10 http://archive.ubuntu.com trusty-updates/universe Sources [187 kB]
Get:11 http://security.ubuntu.com trusty-security/universe Translation-en [103 kB]
Get:12 http://archive.ubuntu.com trusty-updates/multiverse Sources [7768 B]
Get:13 http://archive.ubuntu.com trusty-updates/main amd64 Packages [1004 kB]
Get:14 http://archive.ubuntu.com trusty-updates/restricted amd64 Packages [17.1 kB]
Get:15 http://archive.ubuntu.com trusty-updates/universe amd64 Packages [419 kB]
Get:16 http://archive.ubuntu.com trusty-updates/multiverse amd64 Packages [14.3 kB]
Get:17 http://archive.ubuntu.com trusty-updates/main Translation-en [492 kB]
Get:18 http://archive.ubuntu.com trusty-updates/multiverse Translation-en [7430 B]
Get:19 http://archive.ubuntu.com trusty-updates/restricted Translation-en [3978 B]
Get:20 http://archive.ubuntu.com trusty-updates/universe Translation-en [225 kB]
Get:21 http://archive.ubuntu.com trusty-backports/main Sources [9712 B]
Get:22 http://archive.ubuntu.com trusty-backports/restricted Sources [28 B]
Get:23 http://archive.ubuntu.com trusty-backports/universe Sources [35.3 kB]
Get:24 http://archive.ubuntu.com trusty-backports/multiverse Sources [1898 B]
Hit http://archive.ubuntu.com trusty-backports/main amd64 Packages
Hit http://archive.ubuntu.com trusty-backports/restricted amd64 Packages
Hit http://archive.ubuntu.com trusty-backports/universe amd64 Packages
Hit http://archive.ubuntu.com trusty-backports/multiverse amd64 Packages
Hit http://archive.ubuntu.com trusty-backports/main Translation-en
Hit http://archive.ubuntu.com trusty-backports/multiverse Translation-en
Hit http://archive.ubuntu.com trusty-backports/restricted Translation-en
Hit http://archive.ubuntu.com trusty-backports/universe Translation-en
Get:25 http://archive.ubuntu.com trusty/main Sources [1064 kB]
Get:26 http:...

ChristianEhrhardt (paelzer) wrote :
Download full text (30.8 KiB)

Tested xenial:
TL;DR working as it should now - properly regenerating "over" the cache and thereby working correctly.

$ lxc launch ubuntu-daily:x xenial-bug-1707400 --profile default --profile kvm
Creating xenial-bug-1707400
Starting xenial-bug-1707400
[✓]─[paelzer@lap:~]──[60422]──[19:10 Mi Aug 09]──
$ lxc exec xenial-bug-1707400 bash
root@xenial-bug-1707400:~# apt update
Hit:1 http://archive.ubuntu.com/ubuntu xenial InRelease
Get:2 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]
Get:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]
Get:4 http://archive.ubuntu.com/ubuntu xenial-backports InRelease [102 kB]
Get:5 http://security.ubuntu.com/ubuntu xenial-security/main Sources [85.8 kB]
Get:6 http://archive.ubuntu.com/ubuntu xenial/main Sources [868 kB]
Get:7 http://security.ubuntu.com/ubuntu xenial-security/restricted Sources [2604 B]
Get:8 http://security.ubuntu.com/ubuntu xenial-security/universe Sources [37.8 kB]
Get:9 http://security.ubuntu.com/ubuntu xenial-security/multiverse Sources [1144 B]
Get:10 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages [334 kB]
Get:11 http://security.ubuntu.com/ubuntu xenial-security/main Translation-en [141 kB]
Get:12 http://security.ubuntu.com/ubuntu xenial-security/universe amd64 Packages [152 kB]
Get:13 http://security.ubuntu.com/ubuntu xenial-security/universe Translation-en [78.2 kB]
Get:14 http://security.ubuntu.com/ubuntu xenial-security/multiverse amd64 Packages [2752 B]
Get:15 http://security.ubuntu.com/ubuntu xenial-security/multiverse Translation-en [1232 B]
Get:16 http://archive.ubuntu.com/ubuntu xenial/restricted Sources [4808 B]
Get:17 http://archive.ubuntu.com/ubuntu xenial/universe Sources [7728 kB]
Get:18 http://archive.ubuntu.com/ubuntu xenial/multiverse Sources [179 kB]
Get:19 http://archive.ubuntu.com/ubuntu xenial/universe amd64 Packages [7532 kB]
Get:20 http://archive.ubuntu.com/ubuntu xenial/universe Translation-en [4354 kB]
Get:21 http://archive.ubuntu.com/ubuntu xenial/multiverse amd64 Packages [144 kB]
Get:22 http://archive.ubuntu.com/ubuntu xenial/multiverse Translation-en [106 kB]
Get:23 http://archive.ubuntu.com/ubuntu xenial-updates/main Sources [267 kB]
Get:24 http://archive.ubuntu.com/ubuntu xenial-updates/restricted Sources [3012 B]
Get:25 http://archive.ubuntu.com/ubuntu xenial-updates/universe Sources [167 kB]
Get:26 http://archive.ubuntu.com/ubuntu xenial-updates/multiverse Sources [7232 B]
Get:27 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [608 kB]
Get:28 http://archive.ubuntu.com/ubu...

ChristianEhrhardt (paelzer) wrote :

I attached the full logs for further confidence.
Trusty as well as Xenial correctly exposed the bug with the testcase (to be sure to actually verify the fix) and with the solution from -proposed the reinstall worked correctly.

Setting verification tags accordingly.
Still any further testing is welcome - that is the reason things stay in proposed for a while.

tags: added: verification-done verification-done-trusty verification-done-xenial
removed: verification-needed verification-needed-trusty verification-needed-xenial
Bob Pickett (bpick) wrote :

I have followed what steps I can follow, and when I tried to install libvert, it was already at current release:

user@user1:~/Desktop/libvirt-1.2.2$ sudo apt install libvirt-bin
Reading package lists... Done
Building dependency tree
Reading state information... Done
libvirt-bin is already the newest version (1.3.1-1ubuntu10.12).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
user@user1:~/Desktop/libvirt-1.2.2$

Andreas Hasenack (ahasenack) wrote :

Hi @bpick

the verification was done already, but if you want to continue (and you are welcome to!), what you missed above is enabling the proposed repository, as 1.3.1-1ubuntu10.12 is the version currently in xenial-updates. Maybe you just missed an "sudo apt update" call?

Check what "apt-cache policy libvirt" shows. If it lists proposed, then you just missed an apt update call. If proposed is not listed, then you didn't add the proposed line to /etc/apt/sources.list.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.