Created attachment 1321218 [details] Image showing Partial white logo in hung VM, with CPU, Host CPU and Memory graphs. Description of problem: For each software update since installing F26 the following issues have been seen: 1. Physical machines are not affected by this. 2. Virtual machines off line update has not progressed as expected, no progress and just hanging with the white logo half loaded, no percent or progress. System stays on until many hours later I get fed up and kill it. 3. Even without a completed update the new kernel image shows up in the boot menu. 4. The new kernel is not always able to boot the machine, in most cases I have to go back to previous kernels. On one system I have just completed the 3rd update and the last working kernel (F25 kernel) has been pushed off the list so the system no longer functions at all. Version-Release number of selected component (if applicable): All Fedora 26 running under KVM/QEMU on Fedora 26. How reproducible: Slightly random. but more often fails than works. Steps to Reproduce: 1. Install Fedora 26 as Guest OS on Fedora 26 Host 2. Perform system update by selecting install updates before shutting down or restarting. 3. Mostly system goes into update boot and just stays there with white logo half filled until forced reset, no keys work and VM reboot is not enough, needs force off or reset. 4. If after reboot there is a new kernel in the list it is not always able to get past the half fill white logo. Actual results: System hangs on boot most often Expected results: System boots as expected. Additional info: This is experienced on 2 physical systems running 3 VMs each. of the 6 total VMs I have had one clean update and reboot. All the others require previous kernels to be selected. Memory and processor use are minimal in this state. Clicking in the VM in this state kills the mouse stealing so that you can not see the mouse anywhere near the window of the related host apps, either boxes or Virtmanager has to be closed before the mouse operates normally with the application. Runing rpm -Va on the system once booted with previous kernel does not show any differences to the physical machines which seem to be not affected. These systems are not resource constrained, there is plenty of memory and processor for the light work load.
It's interesting that this does not work for you, because installing updates is a common task. I wonder what could be special about your system(s). Are the hosts and the guests all x86_64? Add "plymouth.enable=0 systemd.show_status=1" to the kernel command line to disable the graphical logo and hopefully see more information about what's going from systemd's point of view. Also try "journalctl -b -1" after booting with a working kernel right after a failed attempt to boot with a non-working one. Useful information may have been logged.
Tried those commands, it claims error no file found "plymouth.enable" press any key to continue then panics, so I did a bit of looking for ways to stop GUI. I found a list saying remove rhgb from command line, which I did and all kernels boot fine when I remove rhgb. Something in the rhgb GUI bit is stopping boot for these newer kernels, and only on machines that are running QXL spice graphics cards.
(In reply to cslee-redhat from comment #2) > only on machines that are running QXL spice graphics cards. OK, this is the key piece of information. After switching my VM to QXL (from 'virtio') I reproduced the bug. "journalctl -b -1" shows a kernel BUG was recorded in the journal and it is identical to the trace reported in bug 1465148. *** This bug has been marked as a duplicate of bug 1465148 ***