Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1487828 - Rebooting VM results in hang unless previous kernel chosen
Summary: Rebooting VM results in hang unless previous kernel chosen
Keywords:
Status: CLOSED DUPLICATE of bug 1465148
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 26
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-02 10:04 UTC by cslee-redhat
Modified: 2017-09-07 14:29 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-07 14:29:15 UTC
Type: Bug


Attachments (Terms of Use)
Image showing Partial white logo in hung VM, with CPU, Host CPU and Memory graphs. (2.93 KB, image/png)
2017-09-02 10:04 UTC, cslee-redhat
no flags Details

Description cslee-redhat 2017-09-02 10:04:25 UTC
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.

Comment 1 Michal Schmidt 2017-09-04 11:56:42 UTC
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.

Comment 2 cslee-redhat 2017-09-07 13:05:22 UTC
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.

Comment 3 Michal Schmidt 2017-09-07 14:29:15 UTC
(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 ***


Note You need to log in before you can comment on or make changes to this bug.