| 2024-01-24 17:30:31 |
Christian Ehrhardt |
bug |
|
|
added bug |
| 2024-01-24 17:30:39 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Mantic |
|
| 2024-01-24 17:30:39 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Mantic) |
|
| 2024-01-24 17:30:39 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Focal |
|
| 2024-01-24 17:30:39 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Focal) |
|
| 2024-01-24 17:30:39 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Jammy |
|
| 2024-01-24 17:30:39 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Jammy) |
|
| 2024-01-24 17:30:39 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Noble |
|
| 2024-01-24 17:30:39 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Noble) |
|
| 2024-01-24 17:30:49 |
Christian Ehrhardt |
qemu (Ubuntu Focal): status |
New |
Invalid |
|
| 2024-01-24 17:30:51 |
Christian Ehrhardt |
qemu (Ubuntu Mantic): status |
New |
Invalid |
|
| 2024-01-24 17:30:53 |
Christian Ehrhardt |
qemu (Ubuntu Noble): status |
New |
Invalid |
|
| 2024-01-24 17:30:55 |
Christian Ehrhardt |
qemu (Ubuntu Jammy): status |
New |
Confirmed |
|
| 2024-01-25 11:07:58 |
Christian Ehrhardt |
qemu (Ubuntu Jammy): status |
Confirmed |
In Progress |
|
| 2024-01-29 13:28:18 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/459588 |
|
| 2024-01-29 16:02:27 |
Christian Ehrhardt |
description |
This has gone through some iterations, and it seems something has broken the variant in Jammy.
Background in bug 1847361
What this does as TL;DR:
- on package upgrade it saves the modules you might later hot-attach in a temporary path
- if a guest was started before upgrade and still runs, it can not load the .so of the current qemu in /usr
- instead it falls back to load them from that temporary path, allowing "guests started before upgrade" to still be able to load drivers
- up to Focal that is tmpfs
- later this changed to a systemd mount unit
- where it is a systemd unit, we use --no-restart-on-upgrade to keep it active
- in both cases the prerm saves the files
- the postrm in remove/purge case cleans
- otherwise it stays until reboot as it is a temporary directory
Now the problem is, it seems on Jammy --no-restart-on-upgrade is ignored.
Focal (no unit yet):
$ apt install -y --reinstall qemu-block-extra
$ ll /var/run/qemu/
total 4
drwxr-xr-x 3 root root 80 Jan 24 17:18 ./
drwxr-xr-x 31 root root 880 Jan 24 17:18 ../
drwxr-xr-x 2 root root 120 Jan 24 17:18 Debian_1_4.2-3ubuntu6.28/
-rw-r--r-- 1 root root 145 Jan 24 17:18 README
=> all good here
Jammy (mount unit, but restarted which it should not be)
root@j-vm:~# apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 68.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 qemu-block-extra amd64 1:6.2+dfsg-2ubuntu6.16 [68.1 kB]
Fetched 68.1 kB in 0s (565 kB/s)
(Reading database ... 72988 files and directories currently installed.)
Preparing to unpack .../qemu-block-extra_1%3a6.2+dfsg-2ubuntu6.16_amd64.deb ...
Unpacking qemu-block-extra (1:6.2+dfsg-2ubuntu6.16) over (1:6.2+dfsg-2ubuntu6.16) ...
Setting up qemu-block-extra (1:6.2+dfsg-2ubuntu6.16) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
● run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there
Loaded: loaded (/proc/self/mountinfo; enabled; vendor preset: enabled)
Active: active (mounted) since Wed 2024-01-24 17:18:51 UTC; 2s ago
Where: /run/qemu
What: tmpfs
Tasks: 0 (limit: 1171)
Memory: 8.0K
CPU: 1ms
CGroup: /system.slice/run-qemu.mount
Jan 24 17:18:51 j-vm systemd[1]: run-qemu.mount: Deactivated successfully.
Jan 24 17:18:51 j-vm systemd[1]: Unmounted Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
Jan 24 17:18:51 j-vm systemd[1]: Mounting Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there...
Jan 24 17:18:51 j-vm systemd[1]: Mounted Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
total 0
drwxr-xr-x 2 root root 40 Jan 24 17:18 ./
drwxr-xr-x 29 root root 840 Jan 24 17:13 ../
=> Broken
Mantic (mount unit, behaving as it should)
root@m-vm:~# apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 113 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu mantic-updates/main amd64 qemu-block-extra amd64 1:8.0.4+dfsg-1ubuntu3.23.10.2 [113 kB]
Fetched 113 kB in 0s (774 kB/s)
(Reading database ... 67919 files and directories currently installed.)
Preparing to unpack .../qemu-block-extra_1%3a8.0.4+dfsg-1ubuntu3.23.10.2_amd64.deb ...
Unpacking qemu-block-extra (1:8.0.4+dfsg-1ubuntu3.23.10.2) over (1:8.0.4+dfsg-1ubuntu3.23.10.2) ...
Setting up qemu-block-extra (1:8.0.4+dfsg-1ubuntu3.23.10.2) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
● run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there
Loaded: loaded (/lib/systemd/system/run-qemu.mount; enabled; preset: enabled)
Active: active (mounted) since Wed 2024-01-24 17:12:40 UTC; 6min ago
Where: /run/qemu
What: tmpfs
Tasks: 0 (limit: 1095)
Memory: 8.0K
CPU: 2ms
CGroup: /system.slice/run-qemu.mount
Jan 24 17:12:40 m-vm systemd[1]: Mounting run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there...
Jan 24 17:12:40 m-vm systemd[1]: Mounted run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
total 0
drwxr-xr-x 3 root root 60 Jan 24 17:18 ./
drwxr-xr-x 32 root root 900 Jan 24 17:12 ../
drwxr-xr-x 2 root root 180 Jan 24 17:18 Debian_1_8.0.4+dfsg-1ubuntu3.23.10.2/
=> Good
---
reproducing the issue is easy, just run:
$ apt install -y --reinstall qemu-block-extra
The unit should stay as-is and the modules should be saved in the dir as shown above.
Task: find why this unit is restarted despite --no-restart-on-upgrade and prevent that. |
[ Impact ]
* Due to dh_installsystemd handling mount units not correctly
in jammy one is restarted on updates
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
* bad case, just restarted, empty dir
* good case, unit still up from before, content in the path
[ Where problems could occur ]
* This exclusively changes the mount unit handling which currently is useless by being restarted, no chance to regress that
* The other chance is to replace other lines by accident, which would be seen in services not starting (diff of postinst looked good in regard to that not happening)
[ Other Info ]
* We could try to backport changes to dh, but that is way more complex, and would impose much bigger regression risk impacting many other packages as they are rebuilt. Hence I'd avoid that post-release and fix them one by one as proposed here-
----
This has gone through some iterations, and it seems something has broken the variant in Jammy.
Background in bug 1847361
What this does as TL;DR:
- on package upgrade it saves the modules you might later hot-attach in a temporary path
- if a guest was started before upgrade and still runs, it can not load the .so of the current qemu in /usr
- instead it falls back to load them from that temporary path, allowing "guests started before upgrade" to still be able to load drivers
- up to Focal that is tmpfs
- later this changed to a systemd mount unit
- where it is a systemd unit, we use --no-restart-on-upgrade to keep it active
- in both cases the prerm saves the files
- the postrm in remove/purge case cleans
- otherwise it stays until reboot as it is a temporary directory
Now the problem is, it seems on Jammy --no-restart-on-upgrade is ignored.
Focal (no unit yet):
$ apt install -y --reinstall qemu-block-extra
$ ll /var/run/qemu/
total 4
drwxr-xr-x 3 root root 80 Jan 24 17:18 ./
drwxr-xr-x 31 root root 880 Jan 24 17:18 ../
drwxr-xr-x 2 root root 120 Jan 24 17:18 Debian_1_4.2-3ubuntu6.28/
-rw-r--r-- 1 root root 145 Jan 24 17:18 README
=> all good here
Jammy (mount unit, but restarted which it should not be)
root@j-vm:~# apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 68.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 qemu-block-extra amd64 1:6.2+dfsg-2ubuntu6.16 [68.1 kB]
Fetched 68.1 kB in 0s (565 kB/s)
(Reading database ... 72988 files and directories currently installed.)
Preparing to unpack .../qemu-block-extra_1%3a6.2+dfsg-2ubuntu6.16_amd64.deb ...
Unpacking qemu-block-extra (1:6.2+dfsg-2ubuntu6.16) over (1:6.2+dfsg-2ubuntu6.16) ...
Setting up qemu-block-extra (1:6.2+dfsg-2ubuntu6.16) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
● run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there
Loaded: loaded (/proc/self/mountinfo; enabled; vendor preset: enabled)
Active: active (mounted) since Wed 2024-01-24 17:18:51 UTC; 2s ago
Where: /run/qemu
What: tmpfs
Tasks: 0 (limit: 1171)
Memory: 8.0K
CPU: 1ms
CGroup: /system.slice/run-qemu.mount
Jan 24 17:18:51 j-vm systemd[1]: run-qemu.mount: Deactivated successfully.
Jan 24 17:18:51 j-vm systemd[1]: Unmounted Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
Jan 24 17:18:51 j-vm systemd[1]: Mounting Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there...
Jan 24 17:18:51 j-vm systemd[1]: Mounted Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
total 0
drwxr-xr-x 2 root root 40 Jan 24 17:18 ./
drwxr-xr-x 29 root root 840 Jan 24 17:13 ../
=> Broken
Mantic (mount unit, behaving as it should)
root@m-vm:~# apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 113 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu mantic-updates/main amd64 qemu-block-extra amd64 1:8.0.4+dfsg-1ubuntu3.23.10.2 [113 kB]
Fetched 113 kB in 0s (774 kB/s)
(Reading database ... 67919 files and directories currently installed.)
Preparing to unpack .../qemu-block-extra_1%3a8.0.4+dfsg-1ubuntu3.23.10.2_amd64.deb ...
Unpacking qemu-block-extra (1:8.0.4+dfsg-1ubuntu3.23.10.2) over (1:8.0.4+dfsg-1ubuntu3.23.10.2) ...
Setting up qemu-block-extra (1:8.0.4+dfsg-1ubuntu3.23.10.2) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
● run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there
Loaded: loaded (/lib/systemd/system/run-qemu.mount; enabled; preset: enabled)
Active: active (mounted) since Wed 2024-01-24 17:12:40 UTC; 6min ago
Where: /run/qemu
What: tmpfs
Tasks: 0 (limit: 1095)
Memory: 8.0K
CPU: 2ms
CGroup: /system.slice/run-qemu.mount
Jan 24 17:12:40 m-vm systemd[1]: Mounting run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there...
Jan 24 17:12:40 m-vm systemd[1]: Mounted run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
total 0
drwxr-xr-x 3 root root 60 Jan 24 17:18 ./
drwxr-xr-x 32 root root 900 Jan 24 17:12 ../
drwxr-xr-x 2 root root 180 Jan 24 17:18 Debian_1_8.0.4+dfsg-1ubuntu3.23.10.2/
=> Good
---
reproducing the issue is easy, just run:
$ apt install -y --reinstall qemu-block-extra
The unit should stay as-is and the modules should be saved in the dir as shown above.
Task: find why this unit is restarted despite --no-restart-on-upgrade and prevent that. |
|
| 2024-01-29 17:26:24 |
Christian Ehrhardt |
description |
[ Impact ]
* Due to dh_installsystemd handling mount units not correctly
in jammy one is restarted on updates
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[ Test Plan ]
* apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
* bad case, just restarted, empty dir
* good case, unit still up from before, content in the path
[ Where problems could occur ]
* This exclusively changes the mount unit handling which currently is useless by being restarted, no chance to regress that
* The other chance is to replace other lines by accident, which would be seen in services not starting (diff of postinst looked good in regard to that not happening)
[ Other Info ]
* We could try to backport changes to dh, but that is way more complex, and would impose much bigger regression risk impacting many other packages as they are rebuilt. Hence I'd avoid that post-release and fix them one by one as proposed here-
----
This has gone through some iterations, and it seems something has broken the variant in Jammy.
Background in bug 1847361
What this does as TL;DR:
- on package upgrade it saves the modules you might later hot-attach in a temporary path
- if a guest was started before upgrade and still runs, it can not load the .so of the current qemu in /usr
- instead it falls back to load them from that temporary path, allowing "guests started before upgrade" to still be able to load drivers
- up to Focal that is tmpfs
- later this changed to a systemd mount unit
- where it is a systemd unit, we use --no-restart-on-upgrade to keep it active
- in both cases the prerm saves the files
- the postrm in remove/purge case cleans
- otherwise it stays until reboot as it is a temporary directory
Now the problem is, it seems on Jammy --no-restart-on-upgrade is ignored.
Focal (no unit yet):
$ apt install -y --reinstall qemu-block-extra
$ ll /var/run/qemu/
total 4
drwxr-xr-x 3 root root 80 Jan 24 17:18 ./
drwxr-xr-x 31 root root 880 Jan 24 17:18 ../
drwxr-xr-x 2 root root 120 Jan 24 17:18 Debian_1_4.2-3ubuntu6.28/
-rw-r--r-- 1 root root 145 Jan 24 17:18 README
=> all good here
Jammy (mount unit, but restarted which it should not be)
root@j-vm:~# apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 68.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 qemu-block-extra amd64 1:6.2+dfsg-2ubuntu6.16 [68.1 kB]
Fetched 68.1 kB in 0s (565 kB/s)
(Reading database ... 72988 files and directories currently installed.)
Preparing to unpack .../qemu-block-extra_1%3a6.2+dfsg-2ubuntu6.16_amd64.deb ...
Unpacking qemu-block-extra (1:6.2+dfsg-2ubuntu6.16) over (1:6.2+dfsg-2ubuntu6.16) ...
Setting up qemu-block-extra (1:6.2+dfsg-2ubuntu6.16) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
● run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there
Loaded: loaded (/proc/self/mountinfo; enabled; vendor preset: enabled)
Active: active (mounted) since Wed 2024-01-24 17:18:51 UTC; 2s ago
Where: /run/qemu
What: tmpfs
Tasks: 0 (limit: 1171)
Memory: 8.0K
CPU: 1ms
CGroup: /system.slice/run-qemu.mount
Jan 24 17:18:51 j-vm systemd[1]: run-qemu.mount: Deactivated successfully.
Jan 24 17:18:51 j-vm systemd[1]: Unmounted Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
Jan 24 17:18:51 j-vm systemd[1]: Mounting Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there...
Jan 24 17:18:51 j-vm systemd[1]: Mounted Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
total 0
drwxr-xr-x 2 root root 40 Jan 24 17:18 ./
drwxr-xr-x 29 root root 840 Jan 24 17:13 ../
=> Broken
Mantic (mount unit, behaving as it should)
root@m-vm:~# apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 113 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu mantic-updates/main amd64 qemu-block-extra amd64 1:8.0.4+dfsg-1ubuntu3.23.10.2 [113 kB]
Fetched 113 kB in 0s (774 kB/s)
(Reading database ... 67919 files and directories currently installed.)
Preparing to unpack .../qemu-block-extra_1%3a8.0.4+dfsg-1ubuntu3.23.10.2_amd64.deb ...
Unpacking qemu-block-extra (1:8.0.4+dfsg-1ubuntu3.23.10.2) over (1:8.0.4+dfsg-1ubuntu3.23.10.2) ...
Setting up qemu-block-extra (1:8.0.4+dfsg-1ubuntu3.23.10.2) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
● run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there
Loaded: loaded (/lib/systemd/system/run-qemu.mount; enabled; preset: enabled)
Active: active (mounted) since Wed 2024-01-24 17:12:40 UTC; 6min ago
Where: /run/qemu
What: tmpfs
Tasks: 0 (limit: 1095)
Memory: 8.0K
CPU: 2ms
CGroup: /system.slice/run-qemu.mount
Jan 24 17:12:40 m-vm systemd[1]: Mounting run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there...
Jan 24 17:12:40 m-vm systemd[1]: Mounted run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
total 0
drwxr-xr-x 3 root root 60 Jan 24 17:18 ./
drwxr-xr-x 32 root root 900 Jan 24 17:12 ../
drwxr-xr-x 2 root root 180 Jan 24 17:18 Debian_1_8.0.4+dfsg-1ubuntu3.23.10.2/
=> Good
---
reproducing the issue is easy, just run:
$ apt install -y --reinstall qemu-block-extra
The unit should stay as-is and the modules should be saved in the dir as shown above.
Task: find why this unit is restarted despite --no-restart-on-upgrade and prevent that. |
[ Impact ]
* Due to dh_installsystemd handling mount units not correctly
in jammy one is restarted on updates breaking the use case
and potentially crashing binaries with shared objects loaded
from that path
* The fix removed the offending restart (in a minimal fashion) as we handle enable+start ourselves already anyway. We could remove more, but this is the smallest change and therefore more reviewable and maintainable.
[ Test Plan ]
* apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
* bad case, mount unit got restarted, empty dir
* good case, unit still up from before, content in the path
Example of the good case:
● run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there
Loaded: loaded (/proc/self/mountinfo; enabled; vendor preset: enabled)
Active: active (mounted) since Fri 2024-01-26 13:30:56 UTC; 2 days ago
Where: /run/qemu
What: tmpfs
Tasks: 0 (limit: 1171)
Memory: 8.0K
CPU: 2ms
CGroup: /system.slice/run-qemu.mount
Jan 26 13:30:56 j-vm systemd[1]: Mounting Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there...
Jan 26 13:30:56 j-vm systemd[1]: Mounted Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
total 0
drwxr-xr-x 3 root root 60 Jan 29 13:27 ./
drwxr-xr-x 29 root root 920 Jan 29 07:00 ../
drwxr-xr-x 2 root root 140 Jan 29 13:27 Debian_1_6.2+dfsg-2ubuntu6.17~jammyppa3/
[ Where problems could occur ]
* This exclusively changes the mount unit handling which currently is useless by being restarted, no chance to regress that
* The other chance is to replace other lines by accident, which would be seen in services not starting (diff of postinst looked good in regard to that not happening)
[ Other Info ]
* We could try to backport changes to dh, but that is way more complex, and would impose much bigger regression risk impacting many other packages as they are rebuilt. Hence I'd avoid that post-release and fix them one by one as proposed here-
----
This has gone through some iterations, and it seems something has broken the variant in Jammy.
Background in bug 1847361
What this does as TL;DR:
- on package upgrade it saves the modules you might later hot-attach in a temporary path
- if a guest was started before upgrade and still runs, it can not load the .so of the current qemu in /usr
- instead it falls back to load them from that temporary path, allowing "guests started before upgrade" to still be able to load drivers
- up to Focal that is tmpfs
- later this changed to a systemd mount unit
- where it is a systemd unit, we use --no-restart-on-upgrade to keep it active
- in both cases the prerm saves the files
- the postrm in remove/purge case cleans
- otherwise it stays until reboot as it is a temporary directory
Now the problem is, it seems on Jammy --no-restart-on-upgrade is ignored.
Focal (no unit yet):
$ apt install -y --reinstall qemu-block-extra
$ ll /var/run/qemu/
total 4
drwxr-xr-x 3 root root 80 Jan 24 17:18 ./
drwxr-xr-x 31 root root 880 Jan 24 17:18 ../
drwxr-xr-x 2 root root 120 Jan 24 17:18 Debian_1_4.2-3ubuntu6.28/
-rw-r--r-- 1 root root 145 Jan 24 17:18 README
=> all good here
Jammy (mount unit, but restarted which it should not be)
root@j-vm:~# apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 68.1 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 qemu-block-extra amd64 1:6.2+dfsg-2ubuntu6.16 [68.1 kB]
Fetched 68.1 kB in 0s (565 kB/s)
(Reading database ... 72988 files and directories currently installed.)
Preparing to unpack .../qemu-block-extra_1%3a6.2+dfsg-2ubuntu6.16_amd64.deb ...
Unpacking qemu-block-extra (1:6.2+dfsg-2ubuntu6.16) over (1:6.2+dfsg-2ubuntu6.16) ...
Setting up qemu-block-extra (1:6.2+dfsg-2ubuntu6.16) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
● run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there
Loaded: loaded (/proc/self/mountinfo; enabled; vendor preset: enabled)
Active: active (mounted) since Wed 2024-01-24 17:18:51 UTC; 2s ago
Where: /run/qemu
What: tmpfs
Tasks: 0 (limit: 1171)
Memory: 8.0K
CPU: 1ms
CGroup: /system.slice/run-qemu.mount
Jan 24 17:18:51 j-vm systemd[1]: run-qemu.mount: Deactivated successfully.
Jan 24 17:18:51 j-vm systemd[1]: Unmounted Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
Jan 24 17:18:51 j-vm systemd[1]: Mounting Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there...
Jan 24 17:18:51 j-vm systemd[1]: Mounted Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
total 0
drwxr-xr-x 2 root root 40 Jan 24 17:18 ./
drwxr-xr-x 29 root root 840 Jan 24 17:13 ../
=> Broken
Mantic (mount unit, behaving as it should)
root@m-vm:~# apt install -y --reinstall qemu-block-extra; systemctl status run-qemu.mount; ls -laF /run/qemu/
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 113 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu mantic-updates/main amd64 qemu-block-extra amd64 1:8.0.4+dfsg-1ubuntu3.23.10.2 [113 kB]
Fetched 113 kB in 0s (774 kB/s)
(Reading database ... 67919 files and directories currently installed.)
Preparing to unpack .../qemu-block-extra_1%3a8.0.4+dfsg-1ubuntu3.23.10.2_amd64.deb ...
Unpacking qemu-block-extra (1:8.0.4+dfsg-1ubuntu3.23.10.2) over (1:8.0.4+dfsg-1ubuntu3.23.10.2) ...
Setting up qemu-block-extra (1:8.0.4+dfsg-1ubuntu3.23.10.2) ...
Scanning processes...
Scanning linux images...
Running kernel seems to be up-to-date.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
No VM guests are running outdated hypervisor (qemu) binaries on this host.
● run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there
Loaded: loaded (/lib/systemd/system/run-qemu.mount; enabled; preset: enabled)
Active: active (mounted) since Wed 2024-01-24 17:12:40 UTC; 6min ago
Where: /run/qemu
What: tmpfs
Tasks: 0 (limit: 1095)
Memory: 8.0K
CPU: 2ms
CGroup: /system.slice/run-qemu.mount
Jan 24 17:12:40 m-vm systemd[1]: Mounting run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there...
Jan 24 17:12:40 m-vm systemd[1]: Mounted run-qemu.mount - Prepare /run/qemu to allow still running qemu binaries of former builds (after package upgrades) to fallback-load modules from there.
total 0
drwxr-xr-x 3 root root 60 Jan 24 17:18 ./
drwxr-xr-x 32 root root 900 Jan 24 17:12 ../
drwxr-xr-x 2 root root 180 Jan 24 17:18 Debian_1_8.0.4+dfsg-1ubuntu3.23.10.2/
=> Good
---
reproducing the issue is easy, just run:
$ apt install -y --reinstall qemu-block-extra
The unit should stay as-is and the modules should be saved in the dir as shown above.
Task: find why this unit is restarted despite --no-restart-on-upgrade and prevent that. |
|
| 2024-01-30 14:51:49 |
Christian Ehrhardt |
tags |
|
server-todo |
|
| 2024-01-30 14:52:01 |
Christian Ehrhardt |
bug |
|
|
added subscriber Canonical Server |
| 2024-01-30 14:52:40 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2024-01-30 14:52:42 |
Christian Ehrhardt |
removed subscriber Canonical Server |
|
|
|
| 2024-01-30 14:52:52 |
Christian Ehrhardt |
qemu (Ubuntu Jammy): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2024-02-02 10:24:25 |
Timo Aaltonen |
qemu (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2024-02-02 10:24:26 |
Timo Aaltonen |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-02-02 10:24:27 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2024-02-02 10:24:29 |
Timo Aaltonen |
tags |
server-todo |
server-todo verification-needed verification-needed-jammy |
|
| 2024-02-05 10:45:56 |
Christian Ehrhardt |
tags |
server-todo verification-needed verification-needed-jammy |
server-todo verification-done verification-done-jammy |
|
| 2024-02-15 19:40:02 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-02-15 19:40:23 |
Launchpad Janitor |
qemu (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
