[Pkg-libvirt-maintainers] Bug#981435: libvirt: stops on upgrade: internal error: Failed to load module 'libvirt_driver_qemu.so': libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not found (required by libvirt_driver_qemu.so)

Andrea Bolognani eof at kiyuko.org
Sun Jan 31 15:36:21 GMT 2021


On Sun, Jan 31, 2021 at 11:04:13PM +0800, Paul Wise wrote:
> On Sun, 2021-01-31 at 15:34 +0100, Andrea Bolognani wrote:
> > As I've never used unattended-upgrades myself, I'm not familiar with
> > it. Is there any chance you could provide some quick tips on how to
> > set up a reproducer environment? Specifically how to set up the same
> > upgrade strategy you're using, and whether it's possible to manually
> > trigger an unattended-upgrades run? That would help a lot!
> 
> You can probably also reproduce it without unattended-upgrades by just
> upgrading libvirt-daemon itself using apt but with unattended-upgrades
> the key is to enable the minimal steps option, but do this overall:
> 
> Install a Debian system that has the old libvirt using the Debian
> wayback machine (snapshot.debian.org), install unattended-upgrades and
> add something like the following in /etc/apt/apt.conf.d/99override-u-u.conf
> and then run this command: systemctl start apt-daily{,-upgrade}.service
> 
>    APT::Periodic::Update-Package-Lists "always";
>    APT::Periodic::Download-Upgradeable-Packages "always";
>    APT::Periodic::AutocleanInterval "always";
>    APT::Periodic::Unattended-Upgrade "always";
>    Unattended-Upgrade::Origins-Pattern { "origin=Debian"; };
>    Unattended-Upgrade::MinimalSteps "true";
>    Unattended-Upgrade::Mail "root";
>    Unattended-Upgrade::Remove-Unused-Dependencies "true";
>    Unattended-Upgrade::Automatic-Reboot "false";
>    // Temporary options for debugging
>    //Unattended-Upgrade::Verbose "true";
>    //Unattended-Upgrade::Debug "true";

Thanks, I'll try this.

> > As for the issue itself, I think it's caused by some of the
> > dependencies not being strict enough
> 
> I'm not sure but I think the issue is caused by the libvirt0 symbol
> file generating incorrect dependencies for the private symbols,
> probably it should be much more restrictive for those.
> 
> The missing symbols are pretty concerning, those look like broken ABI?

The exact error is

  Failed to load module '/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so': /usr/lib/x86_64-linux-gnu/libvirt.so.0: version `LIBVIRT_PRIVATE_6.9.0' not found (required by /usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_qemu.so)

Note how it's talking about LIBVIRT_PRIVATE_x.y.z rather than
LIBVIRT_x.y.z: the latter contains the public API, while the former
is used for internal symbols that are not exposed publicly and are
only needed by other libvirt components, such as utility functions
that are provided by libvirt.so for use in the various drivers.

This is part of the reason why we want upgrades to happen in
lockstep: for any given version of libvirt, its various components
are really only meant to work with other components when these come
from the very same build.

I've opened

  https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/98

with the proposed patch, and I'm going to use the information you
provided above to give it some testing now.

-- 
Andrea Bolognani <eof at kiyuko.org>
Resistance is futile, you will be garbage collected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-libvirt-maintainers/attachments/20210131/9fb9abc0/attachment.sig>


More information about the Pkg-libvirt-maintainers mailing list