| 2021-03-29 02:43:07 |
Tommy Thorn |
bug |
|
|
added bug |
| 2021-03-30 11:50:55 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
Incomplete |
|
| 2021-04-02 01:08:14 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2021-04-02 01:45:14 |
Tommy Thorn |
qemu (Ubuntu): status |
Incomplete |
New |
|
| 2021-04-05 13:44:00 |
Utkarsh Gupta |
bug |
|
|
added subscriber Christian Ehrhardt |
| 2021-04-07 07:08:24 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
Incomplete |
|
| 2021-04-08 00:17:40 |
Tommy Thorn |
qemu (Ubuntu): status |
Incomplete |
New |
|
| 2021-04-08 13:20:17 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
Confirmed |
|
| 2021-04-12 12:56:10 |
Christian Ehrhardt |
cve linked |
|
2021-20181 |
|
| 2021-04-12 12:56:10 |
Christian Ehrhardt |
cve linked |
|
2021-20221 |
|
| 2021-04-12 12:56:10 |
Christian Ehrhardt |
cve linked |
|
2021-20257 |
|
| 2021-04-12 12:56:10 |
Christian Ehrhardt |
cve linked |
|
2021-20263 |
|
| 2021-04-12 18:40:34 |
Christian Ehrhardt |
bug task added |
|
binutils (Ubuntu) |
|
| 2021-04-12 18:40:49 |
Christian Ehrhardt |
bug task added |
|
glibc (Ubuntu) |
|
| 2021-04-12 18:40:59 |
Christian Ehrhardt |
bug task added |
|
gcc-10 (Ubuntu) |
|
| 2021-04-14 06:21:32 |
Christian Ehrhardt |
bug task deleted |
glibc (Ubuntu) |
|
|
| 2021-04-14 06:21:34 |
Christian Ehrhardt |
bug task deleted |
binutils (Ubuntu) |
|
|
| 2021-04-14 06:21:38 |
Christian Ehrhardt |
bug task deleted |
gcc-10 (Ubuntu) |
|
|
| 2021-04-14 06:25:10 |
Christian Ehrhardt |
summary |
Recent update broke qemu-system-riscv64 |
Coroutines are racy for risc64 emu on arm64 - crash on Assertion |
|
| 2021-04-14 06:25:37 |
Christian Ehrhardt |
description |
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2021-04-14 06:25:44 |
Christian Ehrhardt |
bug task added |
|
qemu |
|
| 2021-04-14 06:25:54 |
Christian Ehrhardt |
qemu (Ubuntu): importance |
Undecided |
Low |
|
| 2021-07-08 08:35:42 |
Florian Weimer |
bug |
|
|
added subscriber Florian Weimer |
| 2021-08-21 06:42:00 |
Thomas Huth |
qemu: status |
New |
Incomplete |
|
| 2021-08-21 06:42:33 |
Thomas Huth |
qemu (Ubuntu): status |
Confirmed |
Incomplete |
|
| 2021-10-24 04:17:31 |
Launchpad Janitor |
qemu (Ubuntu): status |
Incomplete |
Expired |
|
| 2021-10-24 04:17:33 |
Launchpad Janitor |
qemu: status |
Incomplete |
Expired |
|
| 2022-07-29 12:02:02 |
Paride Legovini |
qemu: status |
Expired |
Incomplete |
|
| 2022-07-29 12:02:06 |
Paride Legovini |
qemu (Ubuntu): status |
Expired |
Incomplete |
|
| 2022-07-29 13:14:20 |
Thomas Huth |
bug task deleted |
qemu |
|
|
| 2022-08-01 07:41:54 |
Paride Legovini |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1952483 |
|
| 2022-08-01 07:43:26 |
Paride Legovini |
bug task added |
|
qemu (Fedora) |
|
| 2022-08-01 07:43:41 |
Paride Legovini |
qemu (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2022-08-01 07:47:09 |
Paride Legovini |
qemu (Ubuntu): importance |
Low |
Medium |
|
| 2022-08-01 13:05:17 |
Paride Legovini |
bug |
|
|
added subscriber Paride Legovini |
| 2022-08-01 13:09:54 |
Paride Legovini |
tags |
apport-bug arm64 hirsute uec-images |
apport-bug arm64 hirsute lto server-todo uec-images |
|
| 2022-08-02 06:12:06 |
Christian Ehrhardt |
qemu (Ubuntu): assignee |
|
Paride Legovini (paride) |
|
| 2022-08-03 17:40:52 |
Paride Legovini |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-08-03 17:40:52 |
Paride Legovini |
bug task added |
|
qemu (Ubuntu Jammy) |
|
| 2022-08-03 17:41:00 |
Paride Legovini |
qemu (Ubuntu): status |
Confirmed |
Triaged |
|
| 2022-08-03 17:41:03 |
Paride Legovini |
qemu (Ubuntu Jammy): status |
New |
Triaged |
|
| 2022-08-03 17:41:05 |
Paride Legovini |
qemu (Ubuntu Jammy): assignee |
|
Paride Legovini (paride) |
|
| 2022-09-02 14:27:19 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paride/ubuntu/+source/qemu/+git/qemu/+merge/429375 |
|
| 2022-09-19 11:18:28 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/430100 |
|
| 2022-09-19 14:12:28 |
Dan Streetman |
removed subscriber Dan Streetman |
|
|
|
| 2022-09-21 00:53:40 |
Launchpad Janitor |
qemu (Ubuntu): status |
Triaged |
Fix Released |
|
| 2022-10-04 03:15:50 |
Bug Watch Updater |
qemu (Fedora): status |
Unknown |
In Progress |
|
| 2022-10-04 03:15:50 |
Bug Watch Updater |
qemu (Fedora): importance |
Unknown |
Medium |
|
| 2022-10-04 03:15:53 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1924014 |
|
| 2022-10-04 03:15:53 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1950192 |
|
| 2022-10-04 03:15:53 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1924974 |
|
| 2022-10-04 03:15:53 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1940132 |
|
| 2022-10-04 03:15:53 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=2000479 |
|
| 2022-10-04 03:15:53 |
Bug Watch Updater |
bug watch added |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1992968 |
|
| 2023-01-05 09:25:57 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/435185 |
|
| 2023-01-05 09:33:28 |
Christian Ehrhardt |
merge proposal unlinked |
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/435185 |
|
|
| 2023-01-05 09:35:25 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/435185 |
|
| 2023-01-17 12:46:04 |
Bug Watch Updater |
qemu (Fedora): status |
In Progress |
Confirmed |
|
| 2023-01-20 12:57:39 |
Paride Legovini |
qemu (Ubuntu Jammy): assignee |
Paride Legovini (paride) |
|
|
| 2023-01-20 12:57:52 |
Paride Legovini |
bug |
|
|
added subscriber Ubuntu Server |
| 2023-01-25 11:03:12 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/435185 |
|
|
| 2023-01-25 16:07:52 |
Michał Małoszewski |
qemu (Ubuntu Jammy): assignee |
|
Michał Małoszewski (michal-maloszewski99) |
|
| 2023-01-31 15:03:05 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~michal-maloszewski99/ubuntu/+source/qemu/+git/qemu/+merge/436614 |
|
| 2023-02-01 10:34:48 |
Paride Legovini |
summary |
Coroutines are racy for risc64 emu on arm64 - crash on Assertion |
QEMU coroutines fail with LTO on non-x86_64 architectures |
|
| 2023-02-28 19:48:46 |
Mauricio Faria de Oliveira |
bug |
|
|
added subscriber Mauricio Faria de Oliveira |
| 2023-03-01 15:33:59 |
Michał Małoszewski |
description |
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
Jammy (22.04) is affected.
Problem affects people using QEMU.
Problem when trying to install the Ubuntu arm64 ISO image in a VM.
Emulation of riscv64 on arm64 HW fails.
There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
-------------------original bug report--------------------------------
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-01 15:35:23 |
Michał Małoszewski |
description |
[Impact]
Jammy (22.04) is affected.
Problem affects people using QEMU.
Problem when trying to install the Ubuntu arm64 ISO image in a VM.
Emulation of riscv64 on arm64 HW fails.
There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
-------------------original bug report--------------------------------
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
-Jammy (22.04) is affected.
-Problem affects people using QEMU.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
-Emulation of riscv64 on arm64 HW fails.
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
-------------------original bug report--------------------------------
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-01 15:42:22 |
Michał Małoszewski |
description |
[Impact]
-Jammy (22.04) is affected.
-Problem affects people using QEMU.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
-Emulation of riscv64 on arm64 HW fails.
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
-------------------original bug report--------------------------------
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
-Jammy (22.04) is affected.
-Problem affects people using QEMU.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
-Emulation of riscv64 on arm64 HW fails.
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
-------------------original bug report--------------------------------
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-05 00:56:35 |
Mauricio Faria de Oliveira |
description |
[Impact]
-Jammy (22.04) is affected.
-Problem affects people using QEMU.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
-Emulation of riscv64 on arm64 HW fails.
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
-------------------original bug report--------------------------------
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies
This change has been in Kinetic since September, 2022 (~6 months).
-------------------original bug report--------------------------------
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-05 00:57:01 |
Mauricio Faria de Oliveira |
description |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies
This change has been in Kinetic since September, 2022 (~6 months).
-------------------original bug report--------------------------------
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-05 00:57:30 |
Mauricio Faria de Oliveira |
description |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies versions).
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-06 22:32:55 |
Mauricio Faria de Oliveira |
description |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies versions).
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
- Detailed tests steps on AWS in comment #87.
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies versions).
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-06 22:38:00 |
Mauricio Faria de Oliveira |
qemu (Ubuntu Jammy): status |
Triaged |
In Progress |
|
| 2023-03-07 22:59:51 |
Michał Małoszewski |
tags |
apport-bug arm64 hirsute lto server-todo uec-images |
apport-bug arm64 hirsute lto server-todo uec-images verification-needed |
|
| 2023-03-07 23:00:07 |
Michał Małoszewski |
tags |
apport-bug arm64 hirsute lto server-todo uec-images verification-needed |
apport-bug arm64 hirsute lto server-todo uec-images verification-needed verification-needed-jammy |
|
| 2023-03-08 09:59:46 |
Michał Małoszewski |
tags |
apport-bug arm64 hirsute lto server-todo uec-images verification-needed verification-needed-jammy |
apport-bug arm64 hirsute lto server-todo uec-images |
|
| 2023-03-10 23:17:34 |
Steve Langasek |
qemu (Ubuntu Jammy): status |
In Progress |
Incomplete |
|
| 2023-03-12 19:58:10 |
Mauricio Faria de Oliveira |
description |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
- Detailed tests steps on AWS in comment #87.
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies versions).
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64/arm64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
- Detailed tests steps on AWS in comment #87.
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies versions).
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-13 21:49:06 |
Mauricio Faria de Oliveira |
attachment added |
|
qemu-lto-jammy-snippets https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/+attachment/5654224/+files/qemu-lto-jammy-snippets |
|
| 2023-03-13 21:49:23 |
Mauricio Faria de Oliveira |
qemu (Ubuntu Jammy): status |
Incomplete |
Confirmed |
|
| 2023-03-13 21:51:06 |
Mauricio Faria de Oliveira |
description |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64/arm64 on arm64 HW fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
- Detailed tests steps on AWS in comment #87.
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies versions).
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 fails.
-Emulation of arm64/armhf on arm64, ppc64el, s390x fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
- Detailed tests steps on AWS in comment #87.
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies versions).
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-13 22:01:57 |
Tommy Thorn |
removed subscriber Tommy Thorn |
|
|
|
| 2023-03-23 20:25:28 |
Andreas Hasenack |
qemu (Ubuntu Jammy): status |
Confirmed |
Fix Committed |
|
| 2023-03-23 20:25:31 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-03-23 20:25:32 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
| 2023-03-23 20:25:37 |
Andreas Hasenack |
tags |
apport-bug arm64 hirsute lto server-todo uec-images |
apport-bug arm64 hirsute lto server-todo uec-images verification-needed verification-needed-jammy |
|
| 2023-03-27 15:59:45 |
Michał Małoszewski |
description |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 fails.
-Emulation of arm64/armhf on arm64, ppc64el, s390x fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
- Detailed tests steps on AWS in comment #87.
Make a container for testing:
$ lxc launch ubuntu-daily:jammy jammy-test
$ lxc shell jammy-test
Type in:
qemu-system-riscv64 \
-machine virt \
-nographic \
-smp 4 \
-m 4G \
-bios fw_payload.bin \
-device virtio-blk-device,drive=hd0 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-device,rng=rng0 \
-drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 \
-device virtio-net-device,netdev=usernet \
-netdev user,id=usernet,$ports
Nothing should fail in that particular scenario. The container has amd64 architecture.
Now, try to set up an arm64 VM.
Performing an Ubuntu install from ISO on an affected system will cause the crash. Sample command:
qemu-system-aarch64 -m 2048 -nographic -drive file=flash0.img,if=pflash,format=raw -drive file=flash1.img,if=pflash,format=raw -drive file=image.qcow2,if=virtio -cdrom jammy-live-server-arm64.iso
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies versions).
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
[Impact]
-QEMU on Jammy (22.04) is affected.
-Emulation of riscv64 on arm64 fails.
-Emulation of arm64/armhf on arm64, ppc64el, s390x fails.
-Problem when trying to install the Ubuntu arm64 ISO image in a VM.
[Fix]
-There is no entry in debian/rules, where if the Debian architecture of the host machine is not amd64, LTO should be disabled to prevent QEMU coroutines from failing and marked to be exported to all child processes created from that shell.
-Adding DEB_BUILD_MAINT_OPTIONS=optimize=-lto to prevent QEMU coroutines from failing.
[Test Plan]
** Reproduction **
- Detailed tests steps on AWS in comment #87.
arm64 on arm64, ubuntu cloud image
wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-arm64.img
sudo apt install --yes --no-install-recommends qemu-system-arm qemu-efi-aarch64 ipxe-qemu
cp /usr/share/AAVMF/AAVMF_CODE.fd flash0.img
cp /usr/share/AAVMF/AAVMF_VARS.fd flash1.img
qemu-system-aarch64 \
-machine virt -nographic \
-smp 4 -m 4G \
-cpu cortex-a57 \
-pflash flash0.img -pflash flash1.img \
-drive file=jammy-server-cloudimg-arm64.img,format=qcow2,id=drive0,if=none \
-device virtio-blk-device,drive=drive0
...
BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found
qemu-system-aarch64: GLib: g_source_ref: assertion 'source != NULL' failed
Segmentation fault (core dumped)
As mentioned this only happens on specific systems. Paride has a reliable reproducer (see comment 39), he will perform the SRU validation for arm64.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1921664/comments/39
[Where problems could occur]
Any code change might change the behavior of the package in a specific situation and cause other errors.
Possible, but rather unlikely regression source is the fact that the qemu will be rebuilt against newer versions of its build dependencies, on Jammy. There might also be some other warning in the code fixed in later versions not identified by us. It is unlikely, but there might be an architecture where the test plan will fail.
Some updates can also break the functionality of an introduced fix.
Anyway, the fix is quite not complex and problems can be detected easily.
[Other Info]
This change in itself does not change QEMU source code (ie, no functional change), but it does change its object code, since the compiler build options are now changed (in addition to build dependencies versions).
This change has been in Kinetic since September, 2022 (~6 months).
[Original Bug Description]
Note: this could as well be "riscv64 on arm64" for being slow@slow and affect
other architectures as well.
The following case triggers on a Raspberry Pi4 running with arm64 on
Ubuntu 21.04 [1][2]. It might trigger on other environments as well,
but that is what we have seen it so far.
$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh
(wait ~2 minutes)
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting udev Kernel Device Manager...
qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
This is often, but not 100% reproducible and the cases differ slightly we
see either of:
- qemu-system-riscv64: ../../util/qemu-coroutine-lock.c:57: qemu_co_queue_wait_impl: Assertion `qemu_in_coroutine()' failed.
- qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
Rebuilding working cases has shown to make them fail, as well as rebulding
(or even reinstalling) bad cases has made them work. Also the same builds on
different arm64 CPUs behave differently. TL;DR: The full list of conditions
influencing good/bad case here are not yet known.
[1]: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview
[2]: http://cdimage.ubuntu.com/daily-preinstalled/pending/hirsute-preinstalled-desktop-arm64+raspi.img.xz
--- --- original report --- ---
I regularly run a RISC-V (RV64GC) QEMU VM, but an update a few days ago broke it. Now when I launch it, it hits an assertion:
OpenSBI v0.6
____ _____ ____ _____
/ __ \ / ____| _ \_ _|
| | | |_ __ ___ _ __ | (___ | |_) || |
| | | | '_ \ / _ \ '_ \ \___ \| _ < | |
| |__| | |_) | __/ | | |____) | |_) || |_
\____/| .__/ \___|_| |_|_____/|____/_____|
| |
|_|
...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
618 bytes read in 2 ms (301.8 KiB/s)
RISC-V Qemu Boot Options
1: Linux kernel-5.5.0-dirty
2: Linux kernel-5.5.0-dirty (recovery mode)
Enter choice: 1: Linux kernel-5.5.0-dirty
Retrieving file: /boot/initrd.img-5.5.0-dirty
qemu-system-riscv64: ../../block/aio_task.c:64: aio_task_pool_wait_one: Assertion `qemu_coroutine_self() == pool->main_co' failed.
./run.sh: line 31: 1604 Aborted (core dumped) qemu-system-riscv64 -machine virt -nographic -smp 8 -m 8G -bios fw_payload.bin -device virtio-blk-devi
ce,drive=hd0 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-device,rng=rng0 -drive file=riscv64-UbuntuFocal-qemu.qcow2,format=qcow2,id=hd0 -devi
ce virtio-net-device,netdev=usernet -netdev user,id=usernet,$ports
Interestingly this doesn't happen on the AMD64 version of Ubuntu 21.04 (fully updated).
Think you have everything already, but just in case:
$ lsb_release -rd
Description: Ubuntu Hirsute Hippo (development branch)
Release: 21.04
$ uname -a
Linux minimacvm 5.11.0-11-generic #12-Ubuntu SMP Mon Mar 1 19:27:36 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
(note this is a VM running on macOS/M1)
$ apt-cache policy qemu
qemu:
Installed: 1:5.2+dfsg-9ubuntu1
Candidate: 1:5.2+dfsg-9ubuntu1
Version table:
*** 1:5.2+dfsg-9ubuntu1 500
500 http://ports.ubuntu.com/ubuntu-ports hirsute/universe arm64 Packages
100 /var/lib/dpkg/status
ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: qemu 1:5.2+dfsg-9ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-11.12-generic 5.11.0
Uname: Linux 5.11.0-11-generic aarch64
ApportVersion: 2.20.11-0ubuntu61
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDmesg:
Error: command ['pkexec', 'dmesg'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported.
Date: Mon Mar 29 02:33:25 2021
Dependencies:
KvmCmdLine: COMMAND STAT EUID RUID PID PPID %CPU COMMAND
Lspci-vt:
-[0000:00]-+-00.0 Apple Inc. Device f020
+-01.0 Red Hat, Inc. Virtio network device
+-05.0 Red Hat, Inc. Virtio console
+-06.0 Red Hat, Inc. Virtio block device
\-07.0 Red Hat, Inc. Virtio RNG
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:
Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
ProcEnviron:
TERM=screen
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=C.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: console=hvc0 root=/dev/vda
SourcePackage: qemu
UpgradeStatus: Upgraded to hirsute on 2020-12-30 (88 days ago)
acpidump:
Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] failed with exit code 127: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
Error executing command as another user: Not authorized
This incident has been reported. |
|
| 2023-03-27 19:36:02 |
Mauricio Faria de Oliveira |
tags |
apport-bug arm64 hirsute lto server-todo uec-images verification-needed verification-needed-jammy |
apport-bug arm64 hirsute lto server-todo uec-images verification-done-jammy verification-needed |
|
| 2023-03-27 19:36:10 |
Mauricio Faria de Oliveira |
tags |
apport-bug arm64 hirsute lto server-todo uec-images verification-done-jammy verification-needed |
apport-bug arm64 hirsute lto server-todo uec-images verification-done verification-done-jammy |
|
| 2023-04-06 19:09:24 |
Launchpad Janitor |
qemu (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2023-04-06 19:09:34 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
