kernel-4.18.0-0.rc7.git0.1.fc29 landed in Rawhide in the Fedora-Rawhide-20180731.n.0 compose. In that compose, many openQA tests broke. The breakage takes two main forms. Tests that try to switch to a console during the install process (to check something) fail because the console displays corrupted and incomplete as a rectangle overlaying the installer hub: https://openqa.fedoraproject.org/tests/262066#step/_check_install_source/5 Tests which don't do this fail on post-install boot to a console because the font is different from expected. Looking at the screenshots we can also see that the graphics *mode* is not as expected. Compare the login screen from a failed 20180731.n.0 test: https://openqa.fedoraproject.org/tests/262129#step/_console_wait_login/4 with that from a passed 20180730.n.0 test: https://openqa.fedoraproject.org/tests/261775#step/_console_wait_login/3 it's immediately apparent that the 20180730.n.0 is running at native resolution (1024x768 for these VMs), the 20180731.n.0 console does not appear to be. These failures all affect BIOS tests. The corresponding UEFI tests pass, indicating this problem is not affecting UEFI boots. It looks to me like, with this new kernel, console output is never actually handed off from the firmware to the kernel at all. I think that's the root cause of both the observed problems. I think this may perhaps be caused by the patches backported by Hans and mentioned in the package changelog: - Add patches queued in -next to make efifb / fbcon retain the vendor logo (ACPI BRGT boot graphics) until the first text is output to the console so I'll CC Hans. I have reproduced these issues manually, locally, also, in virt-manager. With the same graphics config as openQA (qxl adapter / VNC), things are exactly the same. With other adapter / output protocol combos, things are much the same, though switching to a console during the install process seems to just leave the installer hub showing on the screen (but not usable), rather than displaying the corrupted black rectangle as with qxl / VNC. This TTY switching problem also doesn't seem limited to the installer - it seems like *any* attempt to switch to a TTY from a graphical environment runs into it, which is obviously a significant problem.
Yes this is caused by my patches. I think I know what the problem is and this problem also exists in the -next kernels, so it is great that this has been caught now. I'll make fixing this my highest priority, hopefully I will have this fixed by the end of today.
This should be fixed in 4.18.0-0.rc7.git1.1 which is now building, thank you for catching this.
Fix looks good in testing so far, I'm going to do an openQA run on a test image just to be sure. Thanks.
*** Bug 1610688 has been marked as a duplicate of this bug. ***