console-conf crashes on UC22 with latest snaps in edge

Might be related to python transition to 3.10: https://stackoverflow.com/questions/70344884/pyaudio-write-systemerror-py-ssize-t-clean-macro-must-be-defined-for-format

Between a mix of the instructions here and https://ubuntu.com/core/docs/testing-with-qemu, I was able to get a test running.

I wasn't able to see the listed problem, things sort of got stuck mid way. See attached log.

Any further tips for debugging, or thoughts on why the image I built may have had different results? Maybe share a qemu command line, perhaps there is a difference there? My qemu invocation is from the testing-with-qemu doc above + the swtpm-mvo from the edge channel.

@Dan not sure why qemu is not working for you, but probably you do not need secure boot for this bug. I usually run the image with:

$ qemu-system-x86_64 -enable-kvm -smp 2 -m 4096 \
    -bios /usr/share/OVMF/OVMF_CODE.fd \
    -netdev user,id=net0,hostfwd=tcp::8022-:22,hostfwd=tcp::31111-:31111 \
    -device virtio-net-pci,netdev=net0 \
    -drive if=virtio,file="$img",format=raw \
    -serial mon:stdio

But I cannot reproduce this way, only in an Intel NUC. I think that the key for reproducing is having a wifi device, as the trace I attached in comment #1 has a reference to an _nl80211.listener object. If you have some x86 device with wifi where to test, that could help.

I googled a bit about emulating wifi on qemu, but I did not see a straighforward way. An option we can try if that helps is to insmod mac80211_hwsim from the initramfs so a wlan device is seen later by console-conf.

I reproduced a different crash - https://github.com/canonical/subiquity/pull/1218
Will continue investigating.

I have a straightforward reproduction case for the original ssize problem:

* jammy
* physical hardware with wifi
* console-conf dryrun

https://github.com/canonical/probert/pull/112 opened. When accepted, this must be merged to subiquity.

The presumed fix for this, which works in my above reproduction case, has been merged to subiquity main. It looks like uc22 pulls from subiquity main. Would you rebuild and retry?

I am still seeing the error in core22 revision 142, that I triggered a couple of hours ago. It looks like the files have not updated, what I see inside the snap:

$ ls -l ./usr/lib/python3/dist-packages/probert
total 173
-rw-r--r-- 1 root root 731 may 22 2020 __init__.py
-rw-r--r-- 1 root root 1473 may 22 2020 log.py
-rw-r--r-- 1 root root 28020 may 22 2020 network.py
-rw-r--r-- 1 root root 27624 oct 16 21:59 _nl80211.cpython-310-x86_64-linux-gnu.so
-rw-r--r-- 1 root root 27624 oct 16 21:59 _nl80211.cpython-39-x86_64-linux-gnu.so
-rw-r--r-- 1 root root 18506 may 22 2020 _nl80211module.c
-rw-r--r-- 1 root root 1242 may 22 2020 prober.py
drwxr-xr-x 2 root root 164 mar 16 09:29 __pycache__
-rw-r--r-- 1 root root 23432 oct 16 21:59 _rtnetlink.cpython-310-x86_64-linux-gnu.so
-rw-r--r-- 1 root root 23432 oct 16 21:59 _rtnetlink.cpython-39-x86_64-linux-gnu.so
-rw-r--r-- 1 root root 13315 may 22 2020 _rtnetlinkmodule.c
drwxr-xr-x 4 root root 229 mar 16 09:29 tests
-rw-r--r-- 1 root root 9001 may 22 2020 utils.py

Maybe the issue is that what is updated in subiquity is the snapcraft recipe [1]? The core22 snapcraft.yaml pulls from main, but then it runs dpkg-buildpackage.

[1] https://github.com/canonical/subiquity/commit/4379f1b8d475d3fc6efe5f96a60726e8bcfaa66e

https://github.com/snapcore/core-base/pull/36 opened, which builds a deb for probert from git instead of pulling it from the archive.

I have locally tested this on my NUC with wifi (base built from https://github.com/snapcore/core-base/pull/36), successfully.

I suppose this is now fixed, right?

Yes, it is.