Bug 1353170

Summary: Wayland causes Fedora to lock up on boot in Xen HVM
Product: [Fedora] Fedora Reporter: G Crowe <gcrhbug>
Component: waylandAssignee: Adam Jackson <ajax>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 25CC: ajax
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-12 10:33:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description G Crowe 2016-07-06 10:58:06 UTC
Description of problem:
On a fresh install of Fedora 24 (Workstation) in a Xen HVM (Host is Fedora 21 for my test) the guest will lock up during boot. Disabling Wayland in the guest fixes the problem. This problem has existed since at lease Fedora 22.

Version-Release number of selected component (if applicable):
Fedors 22 and Fedora 24, "everything" repository with nothing applied from the "updates" repository.

How reproducible:
Fails every time in these circumstances.

Steps to Reproduce:
1. Create HVM in Fedora 21 host (see config below)
2. Install Fedora 24 from the "everything" repository. In "Software Selection" during install, select "Fedora Workstation"
3. Boot up newly installed VM and observe that it fails to complete bootup.

Actual results:
Fails to boot up (leaves the Fedora logo on the screen)

Expected results:
Expecting to boot to a Gnome login screen

Additional info:
Refer to following URL for discussions and workaround...
https://ask.fedoraproject.org/en/question/70961/fedora-22-will-not-boot-after-installation-vm/

Workaround involves booting in runlevel 3 and editing /etc/gdm/custom.conf and removing the "#" to enable the line "WaylandEnable=false"


VM config as follows...

<domain type='xen' id='54'>
  <name>client2</name>
  <uuid>9a2f167d-999a-4454-abe5-463991bfdd75</uuid>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='xenfv'>hvm</type>
    <loader type='rom'>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='variable' adjustment='0' basis='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='block' device='disk'>
      <driver name='phy'/>
      <source dev='/dev/array1/client2_root'/>
      <backingStore/>
      <target dev='xvda' bus='xen'/>
    </disk>
    <interface type='bridge'>
      <mac address='02:00:00:05:00:00'/>
      <source bridge='br100'/>
      <script path='vif-bridge'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='1234' autoport='no' listen='1.2.3.4'>
      <listen type='address' address='1.2.3.4'/>
    </graphics>
    <video>
      <model type='cirrus' vram='9216' heads='1'/>
    </video>
  </devices>
</domain>

Comment 1 G Crowe 2017-03-06 10:23:39 UTC
This bug (or what appears to be this bug) still exists in Fedora 25, except that the workaround listed above does not work.

It boots up in the Xen hvm, and ends up on a grey screen with three small rectangles in the middle about 2/3 of the way down. Then it shows a few lines of bootup messages ending with "[  OK  ] Started User Manager for UID 42." and then hangs. I cannot get any response from the console (accessible via VNC because it is a Xen VM), but I am able to SSH to it without issue, even when the console appears to have hung.

If I add the number "3" to the grub bootup command then it boots into text mode successfully and the VNC console is perfectly usable in text mode.

I have tried it with the following video lines in the Xen XML config...
    <model type='cirrus' vram='9216' heads='1'/>
    <model type='vga' vram='9216' heads='1'/>
    <model type='qxl' ram='65536' vram='9216' heads='1'/>
and the symptoms have not changed.

I have edited /etc/gdm/custom.conf and uncomented the Waylanddisable line...
    WaylandEnable=false
but the problem remains.

Note that even with the line mentioned above uncommented, it still appears to run wayland, because when it has hung I have SSHed into it and found the following processes with "ps -aux"
#ps aux | grep -i wayland
gdm        924  0.0  0.5 449880 11004 tty1     Ssl+ 09:48   0:00 /usr/libexec/gdm-wayland-session gnome-session --autostart /usr/share/gdm/greeter/autostart
gdm       1020  0.0  1.4 211160 29504 tty1     Sl+  09:48   0:00 /usr/bin/Xwayland :1024 -rootless -noreset -listen 4 -listen 5 -displayfd 6
root      1313  0.0  0.0 119372   904 pts/0    S+   10:01   0:00 grep --color=auto -i wayland


The complete Xen XML config is as follows...
[root@host1 ~]# virsh dumpxml F25Test
<domain type='xen' id='17'>
  <name>F25Test</name>
  <uuid>526c8d27-72c4-4fef-9cd0-cb42707efaf4</uuid>
  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='xenfv'>hvm</type>
    <loader type='rom'>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='variable' adjustment='0' basis='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='block' device='disk'>
      <driver name='phy'/>
      <source dev='/dev/array1/LVF25Test'/>
      <backingStore/>
      <target dev='xvda' bus='xen'/>
    </disk>
    <interface type='bridge'>
      <mac address='02:00:00:16:00:00'/>
      <source bridge='br100'/>
      <script path='vif-bridge'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='5925' autoport='no' listen='192.168.131.5'>
      <listen type='address' address='192.168.131.5'/>
    </graphics>
    <video>
      <model type='qxl' ram='65536' vram='9216' heads='1'/>
    </video>
  </devices>
</domain>

Comment 2 Fedora End Of Life 2017-11-16 19:40:56 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 3 Fedora End Of Life 2017-12-12 10:33:21 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.