Git rev: master/5f6945f5031e1a4ca116cc1eccf4c2f9dc228547 This issue only happens on Fedora 26 x86_64 and i686. Host: Fedora 26 with latest update $ uname -a Linux pek-usp-7 4.12.8-300.fc26.x86_64 #1 SMP Thu Aug 17 15:30:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Steps: 1. bitbake core-image-sato 2. runqemu qemux86-64 Error log: ###################################### $ runqemu qemux86-64 runqemu - INFO - Running MACHINE=qemux86-64 bitbake -e... runqemu - INFO - Continuing with the following parameters: KERNEL: [tmp/deploy/images/qemux86-64/bzImage--4.12.7+git0+edb42d4805_d09f2ce584-r0-qemux86-64-20170828033016.bin] MACHINE: [qemux86-64] FSTYPE: [ext4] ROOTFS: [tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64-20170828033016.rootfs.ext4] CONFFILE: [/buildarea/poky/build/tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64-20170828033016.qemuboot.conf] runqemu - INFO - Setting up tap interface under sudo runqemu - INFO - Network configuration: 192.168.7.2::192.168.7.1:255.255.255.0 runqemu - INFO - Running tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -drive file=tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64-20170828033016.rootfs.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -device usb-tablet -device virtio-rng-pci -cpu core2duo -m 256 -serial mon:vc -serial null -kernel tmp/deploy/images/qemux86-64/bzImage--4.12.7+git0+edb42d4805_d09f2ce584-r0-qemux86-64-20170828033016.bin -append 'root=/dev/vda rw highres=off mem=256M ip=192.168.7.2::192.168.7.1:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 ' runqemu - ERROR - Failed to run qemu: libEGL warning: DRI2: failed to authenticate X Error: BadRequest Request Major code 153 () Request Minor code 1 Error Serial #162 Current Serial #162 Cleanup Set 'tap0' nonpersistent runqemu - INFO - Releasing lockfile for tap device 'tap0' ############################## With nographic option, it works well.
What GPU does this machine have?
(In reply to comment #1) > What GPU does this machine have? $ lspci | grep VGA 05:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] ES1000 (rev 02) With radeon dirver: $ dmesg |grep radeon [ 3.655891] [drm] radeon kernel modesetting enabled. [ 3.656392] radeon 0000:05:05.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (32M used) [ 3.656396] radeon 0000:05:05.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF [ 3.656563] [drm] radeon: 32M of VRAM memory ready [ 3.656564] [drm] radeon: 512M of GTT memory ready. [ 3.677518] radeon 0000:05:05.0: WB disabled [ 3.677521] radeon 0000:05:05.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xf6be3000 [ 3.677534] [drm] radeon: irq initialized. [ 3.677760] [drm] radeon: ring at 0x00000000B0001000 [ 3.687985] fbcon: radeondrmfb (fb0) is primary device [ 3.857265] radeon 0000:05:05.0: fb0: radeondrmfb frame buffer device [ 3.863417] [drm] Initialized radeon 2.50.0 20080528 for 0000:05:05.0 on minor 0
The ES1000 is decade-old server-grade GPU with minimal actual features. I suspect you're actually running a Wayland session and as qemu is an X application it needs to run under xwayland which requires DRI3. However your GPU is minimal and the driver is ancient, so the odds are good that it doesn't support DRI3. Please try logging into a traditional X session instead of Wayland. If that solves it then I think Fedora should blacklist this GPU for Wayland sessions.
Moving to NEEDINFO.
(In reply to comment #3) > The ES1000 is decade-old server-grade GPU with minimal actual features. I > suspect you're actually running a Wayland session and as qemu is an X > application it needs to run under xwayland which requires DRI3. However > your GPU is minimal and the driver is ancient, so the odds are good that it > doesn't support DRI3. > > Please try logging into a traditional X session instead of Wayland. If that > solves it then I think Fedora should blacklist this GPU for Wayland sessions. Both for Wayland and Xorg, if I open a terminal on host and launch the qemu, it works without problem. If I use ssh -X or -Y to connect the host and launch the qemu, the above error occurs.
How are you configuring qemu-native for a UI (as out of the box it is headless)?
(In reply to comment #6) > How are you configuring qemu-native for a UI (as out of the box it is > headless)? I don't change anything, just use the default setting.
Presumably this is Poky, so SDL is enabled and GTK+ isn't.
I have a Fedora26 laptop and a Fedora26 headless workstation, if I ssh to the workstation from the laptop with X forwarding I observe the following: * with the pyro branch I am able to use runqemu to start a QEMU VM which displays on my laptop * with the master branch trying the same results in the error Yi reported: "runqemu - ERROR - Failed to run qemu: Could not initialize SDL(No available video device) - exiting"
I've now got a NUC running Fedora 26 with Xwayland. I can ssh into it from a Debian machine and graphical runqemu works. I can ssh from it into a Debian machine and graphical runqemu works. Sorry but I can't replicate.
Reassigning to Yi Zhao. Can you dig further? - Verify Josh's statement that Pyro works on F26 - Try using master + pyro's libsdl.bb - Try using master + pyro's qemu.bb
(In reply to comment #11) > Reassigning to Yi Zhao. > > Can you dig further? I retested with the following methods: > > - Verify Josh's statement that Pyro works on F26 Yes, it works. > - Try using master + pyro's libsdl.bb It doesn't work. > - Try using master + pyro's qemu.bb It works. Thanks, Yi
So we blame the new qemu.
Fedora 26 is no longer supported. Re open if this applies to a newer Fedora distro.