-
-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: debug black screen at desktop #8
Comments
It looks like the VM is still left running sometimes at the end. We need a better way to brutally kill off the VM. |
This happened to me the first time I tried to run one of the Ubuntu tests. I noticed that the mouse cursor is the default X11 "X" that you see when mousing over the root window. It's a fallback X session and no windows are opening? |
While trying to debug #30 I managed to get a few black screens. I was able to use the qemu monitor to poke some keypresses and get the screen to draw. I tried switching between various VT terminals, with
then:
However, nothing appeared, other than the default X11 "X" as you noticed @ali1234 . I did manage to get back to the GUI, and the screen redrew partially - only the installer window, and then the title bar when the clock changed - so I expect some kind of xdamage screen refresh optimisation. I sent an ALT+F4 to close the installer, upon which the display redrew completely. I got the journal. Not sure if it's useful for debugging this or if there's other logs I need. By way of comparison, a subsequent run ran fine, and here's the journal from that. |
Just ran every test I have, twice on my decently specced ThinkPad Z13. It shows failure only for the Ubuntu Daily Live (24.10).
In all three cases, it's booting to a black screen. Just some extra data points. |
Minor update. I added some debugging code that detects a black screen multiple screenshots in a row, and triggers a 'remedy' routine. In that I tried CTRL+ALT+F1 to switch to the first TTY via the Qemu monitor. On one occasion this caused the login screen to appear - as one would expect, but switching back via CTRL+ALT+F2 didn't reload the desktop. Something is certainly wrong here, but I'm not sure if it's inside Qemu or in GNOME/Mutter/Wayland/kernel. |
Probably a combination of both and also the viewer in use (sdl, spice etc), similar to quickemu-project/quickemu#454 |
We can likely eliminate the viewer. I have been running the tests recently with the display set to none, so no viewer is involved. But that still leaves all of Qemu and the hardware emulation, and all of the Ubuntu stack. I mostly see the black screens only on Ubuntu 24.04 and daily-live though. I will more aggressively test the others in a loop over the coming day or so, to see if I can trigger it elsewhere. This is my silly 'run it till it fails' script. #!/bin/bash
while true; do
export QT_OPEN_RESULTS=false
export QUICKEMU_DISPLAY=none
export QT_KEEP_SCREENSHOTS=true
export QT_KEEP_TESSERACT_TEXT=true
if ! ./quicktest test_install_entire_disk_with_defaults ubuntu 24.04; then
exit 99
fi
rm machines/ubuntu-24.04/disk.qcow2
done |
Bah! I don't understand why it works fine and then suddenly doesn't, with no changes to anything.
Feels like some kind of race when the system boots. Next step is to try with no network connected. |
This would be a lot easier to debug if quickemu could expose an OOB debug shell somewhere, so we can get into the system to see what is happening without having to go through the (broken) UI. |
I just caught it being black-screen for a while, and added a 'bodge' to jump into the monitor and press ctrl-alt-f1 then enter (which presses 'login') on the gdm3 style 'lock' screen in the live session. This did something, as it went back to the desktop and did that xdamage thing I mentioned. Note in this image only portions of the screen are updated. This was all done with display set to 'none' so no spice viewer. What does this? Is it mutter perhaps? This suggests it might be. Maybe this is only confined to Ubuntu proper with GNOME 3? Anyway, it continued through the install (and failed for another reason I need to debug). On the plus side this rules out network too, because this black screen happened when there was no network. @ali1234 I think there is a serial terminal, but not sure how much use it is. I ran quickemu does enable a fair amount of connectivity like copy/paste between host and guest, ssh, webdav and all that. But none of those things are enabled by default in the live environment. My policy of not changing the iso holds, because I don't want to affect the tests (either way). But you're right, we do need some better way to debug this. One option would be to pause the entire test suite as soon as a succession of black screenshots are taken. So we can then maybe inject I currently test for that in a local branch where |
You have to enable the serial console at the grub menu. Let me see if I can script that up... |
Okay I got the console working, but only manually. Scripting it does not work for some reason: #38 In order for the kernel to output anything you also have to delete "quiet" from the command line. Ubuntu will then log stuff to the serial port and you can interact with socat. Unfortunately Ubuntu does not start a getty on the console at the end of boot, so you can only read the kernel log. It might still be useful. Alpine does start a getty on the tty, but it only waits for 1 second at the grub menu, which is difficult to catch manually and impossible with the current scripting facilities. We need a way to hold down the shift key to stop the timeout... |
I also noticed that the Ubuntu live image is pointlessly spamming:
a few times per second to the console. I doubt this is related to the black screen since it does it even when the desktop does load up. Kind of funny/annoying though because it fills your scrollback very quickly. |
Meanwhile, the kubuntu calamares install test I left running in a loop last night ran a lot more times before failing, and didn't fail for the same reason (it wasn't a blank screen). Making me think this is very much a GNOME stack issue.
|
Expected behavior
Booting 10 times in a row, the same Ubuntu 24.04 ISO image, I expect 10 out of 10 or 0 out of 0 to boot successfully.
Actual behavior
Sometimes, Qemu will boot to Grub, then fail to show the Ubuntu desktop. The desktop is running, we know this because we can hear the chimes which play after the installer has begun. However, it seems impossible to get the GUI to appear. Just a black screen
Steps to reproduce the behavior
for f in {1..100}; do QT_KEEP_SCREENSHOTS=true QT_KEEP_TESSERACT_TEXT=true QUICKEMU_OPTS=--status-quo ./quicktest test_boot_to_welcome_screen ubuntu 24.04 && sleep 10 && kill -9 ${cat machines/ubuntu-24.04/ubuntu-24.04.pid}; done
It doesn't take long to fail:
Additional context
test_boot_to_welcome_screen.zip
The text was updated successfully, but these errors were encountered: