This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu7.38
---
qemu (1:2.11+dfsg-1ubuntu7.38) bionic; urgency=medium
* enhance loading of old modules post upgrade (LP: #1913421)
- d/qemu-block-extra.prerm.in: clear all (current and former) modules
on purge
-
This bug was fixed in the package qemu - 1:5.2+dfsg-9ubuntu3.2
---
qemu (1:5.2+dfsg-9ubuntu3.2) hirsute; urgency=medium
* d/rules fix microvm default machine type for a new build system
(LP: #1936894) - Thanks to Michael Tokarev for the fix.
* enhance loading of old modules
This bug was fixed in the package qemu - 1:4.2-3ubuntu6.18
---
qemu (1:4.2-3ubuntu6.18) focal; urgency=medium
* enhance loading of old modules post upgrade (LP: #1913421)
- d/rules: d/qemu-system-gui.{prerm,postrm}.in: do not save gui modules
(can't be loaded late)
-
All explicit tests for this completed successfully
The same builds (but in PPA) were not showing in general regression-
tests before so I have not re-tested that again.
Overall I consider this verified and update the tags.
** Tags removed: verification-needed verification-needed-bionic
Test II
Bionic
- does not apply
Focal
ubuntu@qemu-module-focal:~$ QEMU_MODULE_DIR="/tmp/" qemu-system-x86_64
-nographic -cdrom
https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/impish-live-server-amd64.iso
&
[1] 41811
ubuntu@qemu-module-focal:~$ sudo cat /proc/$(pidof
Test III:
no extra MP and no MP stacking if already executable
Bionic
ubuntu@qemu-module-bionic:~$ sudo umount /var/run/qemu/; sudo rm -rf
/var/run/qemu; sudo mount -o remount,exec /run
ubuntu@qemu-module-bionic:~$ find /var/run/qemu/; findmnt -T /var/run/qemu
find: ‘/var/run/qemu/’: No such
Test I
Bionic
ubuntu@qemu-module-bionic:~$ virsh start lateload
Domain lateload started
ubuntu@qemu-module-bionic:~$ sudo mv
/usr/lib/x86_64-linux-gnu/qemu/block-curl.so /root/block-curl.so.notherightplace
ubuntu@qemu-module-bionic:~$ virsh attach-device lateload curldisk.xml
Device attached
Testing - Upgrade from the former version
Bionic
ubuntu@qemu-module-bionic:~$ sudo apt update; sudo apt upgrade -y
Hit:1 http://security.ubuntu.com/ubuntu bionic-security InRelease
Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:3 http://archive.ubuntu.com/ubuntu bionic-updates
FYI the test issues were just flaky tests and are resolved by now.
--
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
** 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.
* The problem is
Hello Christian, or anyone else affected,
Accepted qemu into hirsute-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/qemu/1:5.2+dfsg-9ubuntu3.2 in a few
hours, and then in the -proposed repository.
Please help us by testing this new package. See
We found a further small issue in review and I fixed it up.
Thanks Robie for spotting them!
Test:
In normal/default environments after an upgrade:
$ find /var/run/qemu/; findmnt -T /var/run/qemu
/var/run/qemu/
/var/run/qemu/Debian_1_5.2+dfsg-9ubuntu3.2~hirsuteppa7
Ok, this finally should have been through enough verification, reviews and
discussions.
Ready for consideration by the SRU Team and thereby uploaded to Bionic-,Focal-
and Hirsute-unapproved.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
An update on test #2 adding it to the description.
This sub-test is only in Focal and Hirsute, was not present in Bionic.
This should have preference over the other dirs (usual load as well as fallback
path), therefore we do NOT remove the usual paths and check if it works, we
keep them but
FYI Retests with all the feedback by SRU and my Team are in the code and PPAs
right now.
All looks good for the initial tests, I need to prep the environment to check
if QEMU_MODULE_DIR works fine, if it does it should be ready to go to
-unapproved.
--
You received this bug notification
** 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.
* The problem is
** Changed in: qemu (Ubuntu Focal)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** Changed in: qemu (Ubuntu Hirsute)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Changed in: qemu (Ubuntu Bionic)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
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
** 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
Retest
1. install (no files, no mount)
2. upgrade/reinstall (modules saved, mount)
3. upgrade/reinstall (modules saved, mount - no double mount or errors)
4. moving files away still late loadable into running guest
5. on remove current modules are removed, others might stay behind
6. purge while
I have implemented the SRU now as discussed.
Retest LGTM
1. install (no files, no mount)
2. upgrade/reinstall (modules saved, mount)
3. upgrade/reinstall (modules saved, mount - no double mount or errors)
4. moving files away still late loadable
5. on remove current modules stay behind, the rest
One thought. From a quick test, it looks like I can mount a directory
tmpfs over and over again, building up the list of mounts. So if there's
some other reason the script can't execute in /run/qemu, every time the
postinst runs, we'd mount over it again. So maybe we should additionally
not mount
Oh and as Robie expressed in the discussion, he likes the "test the fact"
better than the "look for the config" approach for the SRUs.
So do not be puzzled by the former snippets of "findmnt --noheadings --target
/run/qemu/ | grep -vq noexec" being replaced by the new "run from path"
approach.
Thanks for summarizing the outcome of our discussion and "alternative B
detail brainstorming". And also thanks for being our tie-breaker on this
- I appreciate that and will go through revamping the MPs and retests.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I discussed this in realtime with Christian earlier, from an SRU review
perspective.
My opinion on what we should do follows. I'd like to be clear though
that this isn't necessarily a final decision. If there's a flaw in this
plan, please point it out so that we can reconsider. And if there are
Thank you for chiming in Markus - in cases like this it mostly is better
to have more POVs. I'm waiting for a pre-review by the SRU team now as
they will have the final decision in this anyway.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
As this has bitten us more than once in the past, we had to find a solution
that would work for us while this issue was discussed. Adding a mount unit
without noexec for /run/qemu was the obvious and most straightforward solution.
We have on average at least one qemu update between reboots, so
>> I knew and can understand that you like the tmpfiles.d approach more
> to clarify, that isn't the approach i suggested in comment 41
Indeed, but I thought my full answer also covered why:
"... throw in a check for 'noexec' in the postinst and actually do a quick
manual tmpfs
mount without
> I knew and can understand that you like the tmpfiles.d approach more
to clarify, that isn't the approach i suggested in comment 41
--
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:
Hi Dan,
> Ok, so I know I should have complained (more) in the Debian bug, earlier.
> It's been merged already. This is just about backporting.
...
> Maybe I'm just making the backporting more difficult by complaining about it
> being more complex than should be needed for the relatively simple
Ok, so I know I should have complained (more) in the Debian bug,
earlier. It's been merged already. This is just about backporting.
However, reading the merge requests just makes me...itchy.
First, let me recap what the point of all this is:
When qemu is upgraded from version X to version Y, the
All three planned SRUs (and Impish to be sure) passed all my intended tests in
regard to the maintscript behavior that I outlined above.
Then I was running the actual intended use-case that is outlined as test in the
SRU template - works as well.
I'm opening merge proposals for those SRUs and
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/407764
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/407765
** Merge proposal linked:
** 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
The remaining Focal issues stopping the unit on prerm should be resolved now.
The new version is building for the next round of tests.
--
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:
Focals dh* tools seemd to be rather unimpressed whatever we do for for
-name=run-qemu.mount :-/
- not calling dh* for it
- calling dh* with --no-start --no-enable
- calling dh* with --no-restart-on-upgrade
All achieve the same which is NOT what we want.
They all do:
- stop on purge (ok)
- mask
Bionic is now properly enabled - loading works
With original file available:
7fd0bd2d1000-7fd0bd2d5000 r-xp fc:01 258155
/usr/lib/x86_64-linux-gnu/qemu/block-curl.so
Without it available:
7f5ba74d1000-7f5ba74d5000 r-xp 00:32 8
From debugging it seems Bionic didn't have CONFIG_MODULE_UPGRADES set correctly.
(gdb) p dirs
$1 = {0x0, 0x0, 0x0}
Is the latter of:
168 #ifdef CONFIG_MODULE_UPGRADES
169 char *version_dir;
** 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.
+ * An infrequent but
I copied over the test case from the last SRU, but for Bionic that
actually needs to be modified as it fails even with the original module
being around.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
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
The stop issue should be Fixed as well.
New iteration building in PPA.
BTW the PPA is at:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4653
Iteration #2 findings that need to be addressed:
- Bionic doesn't enable/start the mount unit (I'll do that manually for further
tests)
-
Updates already added for a new iteration:
- Fixed the version comparisons in the postinst (worked, but was wrong and
could cause issues in later cross upgrades)
- Fixed the missing negation in the check if the target is no-exec (prevented
saving of modules)
Info:
- the F/B postrm does purge
Iteration I:
- Bionic's and Focal's systemd do not know "ReadWriteOnly".
That is not super-important to have, dropped from those backports
(done)
- default mount options slightly differ >=Hirsute vs <=Focal, but nothing
that affects the use-case
(no action needed)
- Removing
Oh and yes, thinking about it more time while backporting I think having
the mount unit default enabled (and therefore the post upgrade module
loads working by default) is the right way to go. So ddstreet and I
agree on this.
--
You received this bug notification because you are a member of
With this going into Impish and that now being in feature freeze without
any panic-bugs on this for a while I've started to backport the mount
unit, and established a test plan which is around this.
(most reasonable in monospace)
Bionic FocalHirsuteImpish
> Thanks, so you think even if we can't convince the SRU team of
default-on then having the mount unit would be better than having
nothing and letting everyone deal with it on their own then - right?
i think we really need to figure out some way to actually ensure this is
fixed for older releases
The Groovy Gorilla has reached end of life, so this bug will not be
fixed for that release
** Changed in: qemu (Ubuntu Groovy)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
>> Either as an opt-in or default-on feature.
>> Both approaches have arguments that speak for them
> sorry, could you actually list those arguments? Just for clarification
To be clear I'm on the "let us enable it" side of things.
But I see the two SRU questions:
a) but that changes behavior of
> Either as an opt-in or default-on feature.
> Both approaches have arguments that speak for them
sorry, could you actually list those arguments? Just for clarification
> 3. open discussion with the SRU team what the default should be
> 3b. If the discussion ends with default off, do we even
Finally - Now that we have settled on a way how to resolve the noexec issue and
have it in 21.10 we consider how to SRU this. Either as an opt-in or default-on
feature.
Both approaches have arguments that speak for them, but first we need to prep
the changes which can have various slight
** Also affects: qemu (Ubuntu Hirsute)
Importance: Undecided
Status: New
--
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
This bug was fixed in the package qemu - 1:6.0+dfsg-1~ubuntu3
---
qemu (1:6.0+dfsg-1~ubuntu3) impish; urgency=medium
* d/p/u/lp-1935617-target-ppc-Fix-load-endianness-for-lxvwsx-lxvdsx.patch:
fix TCG emulation for ppc64 (LP: #1935617)
qemu (1:6.0+dfsg-1~ubuntu2) impish;
Hi Markus,
yeah the intention is to pick one once we agree with Debian which one to not go
back too often. That was discussion was stuck for a while but recently
unblocked.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Are there any plans to go forward with any of the above mentioned solutions?
Currently I either have to migrate off all guests before a qemu upgrade or set
up a tmpfs mount with exec on /run/qemu.
Happy to help testing.
--
You received this bug notification because you are a member of Ubuntu
Yes Dan, I'd include those as they'd ride a change that makes the upload
qualify for an SRU.
But first we need to agree/complete it and also another set of CVE uploads
needs to pass.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@paelzer when you sru for this bug, can you include the patches from bug
1887535 and bug 1887823 also? I have MR for them linked from the bugs
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1913421
On Thu, Feb 11, 2021 at 2:45 PM Dan Streetman
<1913...@bugs.launchpad.net> wrote:
>
> Another completely different alternative approach might be for us to see
> if upstream qemu is willing to simply open all the module files when
> qemu starts, and leave the fd open until exit.
We've had that
Another completely different alternative approach might be for us to see
if upstream qemu is willing to simply open all the module files when
qemu starts, and leave the fd open until exit.
That way even if the module files are removed, any still-running qemu
process(es) would still have an open
> the opt-in we want anyway
major nak from me. this can't be opt-in. Can you explain the concern?
> from the discussion we had the outcome was that tmpfiles can only create
> directories
> and set ownership
that's not true
> apparmor confinement no symlink magic will help
I'm not thinking of
@Dan - from the discussion we had the outcome was that tmpfiles can only create
directories and set ownership. At the same time the path is set (per upstream
agreement cross distros) and also due to apparmor confinement no symlink magic
will help. But the issue we ahve here is that we need to
Hi Dan,
the opt-in we want anyway - nothing of that is tied to the question of .mount
vs tmpfiles
We had identified some drawback in tmpfiles that made us chose .mount,
but maybe that changed given the recent discussions/insights. I'll re-
read out old discussion why we dis-qualified tmpfiles
This sounds very complicated. Are you *sure* using a simple tmpfiles.d
approach wouldn't be better?
--
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
[1]: is debian-devel of this morning which seems ot have no public logs
:-/
Not sure if I'm supposed to post them then
--
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
LOL+ I had to major breakthroughs on this:
1. I found the right way in d/rules to get the .mount unit started
2. I had a great discussion about "the other POV" on this [1] and I must say
that I agree.
As much as this can be a comfort function it can also be
a) less reasons to finally
Loaded: loaded (/lib/systemd/system/run-vmblock\x2dfuse.mount;
enabled; vendor preset: enabled)
--
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
Here how open-vm-tools looks like:
/var/lib/dpkg/info/open-vm-tools-desktop.postinst: deb-systemd-helper
unmask 'run-vmblock\x2dfuse.mount' >/dev/null || true
/var/lib/dpkg/info/open-vm-tools-desktop.postinst: if deb-systemd-helper
--quiet was-enabled 'run-vmblock\x2dfuse.mount'; then
This is as open-vm-tools, there it works :-/
--restart-after-upgrade --no-stop-on-upgrade
But no matter if I use either of the following for dh_installsystemd:
"--restart-after-upgrade --no-stop-on-upgrade"
"--no-stop-on-upgrade"
""
I always end up with:
open-vm-tools-desktop
dh_installsystemd -popen-vm-tools-desktop --restart-after-upgrade
--no-stop-on-upgrade run-vmblock
=> Maintscripts
# Automatically added by dh_installsystemd/13.3.1ubuntu1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" =
Build in PPA complete, testing ...
$ ll /var/run/qemu/
ls: cannot access '/var/run/qemu/': No such file or directory
$ sudo apt install --reinstall qemu-block-extra
$ ls -laFd /var/run/qemu; ls -laF /var/run/qemu; ls -laF /var/run/qemu/*
drwxr-xr-x 3 root root 60 Jan 27 20:02 /var/run/qemu/
total
Test PPA at:
https://launchpad.net/~paelzer/+archive/ubuntu/lp-1913421-qemu-module-noexec
(preliminary) MP:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/397008
** Changed in: qemu (Ubuntu)
Status: Confirmed => In Progress
** Tags added: server-next
--
You
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/397008
--
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
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: qemu (Ubuntu Groovy)
Status: New => Confirmed
--
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:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: qemu (Ubuntu Focal)
Status: New => Confirmed
--
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:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: qemu (Ubuntu)
Status: New => Confirmed
--
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
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: qemu (Ubuntu Bionic)
Status: New => Confirmed
--
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:
76 matches
Mail list logo
