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
- d/qe
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 po
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)
- d
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
verifica
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 qemu-system-x86
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 file
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 suc
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 InRelea
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 noti
** 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 tha
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
http
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
/var/run/qemu/Debian_1_5.2+dfsg-
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 Ub
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 chec
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 becaus
** 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 tha
** 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 t
** 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 particula
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 gu
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 s
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 i
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, wh
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
im
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 U
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 h
>> 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:
Loa
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 op
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 wo
** 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:
https://code.launchpad.net/~paelzer/ubuntu/+sou
** 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 particula
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:
Lo
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 o
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
/run/
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 ann
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.
https://bugs.launchpad.net/bugs/19
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 postin
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)
- B
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 ser
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 qemu-block-extr
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 Ubunt
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
ins
> 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.
https://bugs.launchpad.
>> 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 t
> 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 nee
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 behavio
** 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 noexec
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; urgency
Hi Markus,
yeah the intention is to pick one once we agree with Debian which one to not go
back&forth 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.
https:
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
Bu
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.
ht
@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
Tit
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 disc
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 fd
> 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 ha
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 and
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 need
[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 pre-upgra
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 restart
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 to
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:
/var/lib/dpkg/info/qemu-system-common.post
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 rec
** 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 mo
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
