Fixes for iteration #3: - the leading and trailing _ was for Bionic as 2.11 stored the version differently (added in v.25), since we will test if it actually loads old modules we will have an extra check if it works that way once all other things are resolved. - Fixed Bionic start (missed postinst; Focal finds and acts on .mount file ind debian/* so it doesn't need the same) - Focal still has the "deb-systemd-invoke stop" section even without us calling dh_*systemd in d/rules. It automatically picks up the unit and decides that it is good to act on it :-/ Now trying --no-start - Focal did actually copy the content as planned, but afterwards prerm stopped the mount unit and then a new start had new empty content. Hopefully the --no-enable --no-start will make dh leave it alone for our handling as intended
** Description changed: + [Impact] + + * An infrequent but annoying issue is QEMUs problem to not be able to + hot-add capabilities IF since starting the instance qemu has been + upgraded. This is due to qemu modules only working with exactly the + same build. + + * TBD this particular change + + [Test Case] + + I: + * $ apt install uvtool-libvirt + $ uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=bionic + $ uvt-kvm create --password ubuntu lateload arch=amd64 release=bionic label=daily + + cat > curldisk.xml << EOF + <disk type='network' device='disk'> + <driver name='qemu' type='raw'/> + <source protocol="http" name="ubuntu/dists/bionic-updates/main/installer-amd64/current/images/netboot/mini.iso"> + <host name="archive.ubuntu.com" port="80"/> + </source> + <target dev='vdc' bus='virtio'/> + <readonly/> + </disk> + EOF + + # Here up or downgrade the installed packages, even a minor + # version or a rebuild of the same version + # Instead if you prefer (easier) you can run + $ apt install --reinstall qemu-* + + Next check if they appeared (action of the maintainer scripts) + in the /var/run/qemu/<version> directory + + # And then rm/mv the original .so files of qemu-block-extra + # Trying to load a .so now would after an upgrade fail as the old qemu can't load the build id + + $ virsh attach-device lateload curldisk.xml + Reported issue happens on attach: + root@b:~# virsh attach-device lateload cdrom-curl.xml + error: Failed to attach device from cdrom-curl.xml + error: internal error: unable to execute QEMU command 'device_add': Property 'virtio-blk-device.drive' can't find value 'drive-virtio-disk2' + + In the log we can see: + Failed to initialize module: /usr/lib/x86_64-linux-gnu/qemu/block-curl.so + + One can also check files mapped into a process and we should see the + /var/run/.. path being used now. + + II: + * As it had issues in the first iteration of the fix worth a + try is also the use of an environment var for an extra path: + $ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64 -cdrom localhost::/foo + + [Regression Potential] + + TBD + + [Other Info] + + TBD + + --- + + This is a continuation of bug 1847361. Since that is in Ubuntu and Debian we are: - correctly saving the modules to those paths in /var/run/qemu. - qemu tries to load from that path as fallback - that works fine in containers running qemu/kvm But there is an issue on non-container systems as /run usually is like this: - tmpfs on /run type tmpfs + tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3274920k,mode=755) The important bit here is the "noexec" which is intentional (for security reasons), but prevents the loading of shared objects from that path. The path is good for many reasons (it is auto-cleaned, upstream and Distros agreed to this one path, ...). Moving it to other places also quite likely might have unpredictable options. In a discussion between Victor (thanks for all the pushign and inpot on this) and Marc (security POV) we have come to a solution that will make just the subpath that is owned by qemu to not have noexec set. This bug shall track preparing this fix for Debian / Ubuntu and the latter SRu considerations on the same. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1913421 Title: Load of pre-upgrade qemu modules needs to avoid noexec To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1913421/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
