Comment 2 for bug 1912706

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Von,
thanks for the report!

I used to have this in the past:
$ qemu-system-x86_64 -machine ubuntu,vmport=off -cpu host -accel kvm -smp 2 -m 1G -device virtio-mouse -device virtio-keyboard -device virtio-vga,virgl=on -display gtk,gl=on -usb -nodefaults -monitor vc ...

That worked with the 4.2 in Focal and the 5.0 in groovy.
It can be run without a disk image just to see it qemu would start up properly, but needs a local Desktop env (not a remote X11 through e.g. ssh).

The stack for Groovy->Hirsute for virgl isn't too different:
  virgl: 0.8.2-4 -> 0.8.2-5
(no functional change between those)
Qemu did jump 5.0 -> 5.2 thou
  1:5.0-5ubuntu9.2 -> 1:5.2+dfsg-3ubuntu1

For me my command above is starting on Hirsute just as much as on the former releases.

On searching for the issue I found various:
- https://patches.openembedded.org/patch/166423/
- https://github.com/anholt/libepoxy/issues/163
- https://github.com/flathub/ca._0ldsk00l.Nestopia/issues/1

The pattern there is that the particular error messages seem to be in any sort of SW if the GTK/X stack fails to initialize.

But OTOH I guess you'd have noticed if no UI at all would be present anymore :-)
So I wonder if the new builds need some feature that is now missing - e.g. I think of the various acceleration features.

The fail itself (in all such cases) is in libepoxy.
But that is on the same version/build throughout Focal->Hirsute.
 libepoxy0 | 1.5.4-1 | focal | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 libepoxy0 | 1.5.4-1 | groovy | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
 libepoxy0 | 1.5.4-1 | hirsute | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x

Since it works for me on the same qemu and the theory is that we need to hunt for something in your UI stack that changes I'll mark qemu incomplete until we have found more.
At the same time I'll add a libepoxy task to bring in people knowing what all it would check.

@Vun - there are two angles we can IMHO attack this:
1) check if qemu changed (even if working for me). To check that you might enable the groovy repositories and downgrade qemu to 1:5.0-5ubuntu9.3 (a bit hacky but good for a try). Try to change nothing else - if any libs will be installed as dependency please report. Let me know if you manage to get an "all else is unchanging but qemu 5.0 works whie 5.2 fails" situation

2. check the glx/egl status on old vs new environment (Kernel / X stack). I'd think of e.g.
$ glxinfo
$ for i in $(gegl --list-all); do gegl -v --info $i; done
$ git clone https://github.com/KDAB/eglinfo.git
$ cd eglinfo
$ apt install qtchooser qt5-default build-essential
$ qmake -o Makefile eglinfo.pro
$ make
$ ./eglinfo
Compare those outputs between old&new env is anything missing that might explain why it failed to initialize it?