Bug 1111724

Summary: UI only renders in a small area of the screen, with much of it invisible, on dedicated installer images
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: loraxAssignee: Brian Lane <bcl>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: rawhideCC: bcl, g.kaviyarasu, jonathan, robatino, satellitgo, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: lorax-21.12-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-25 02:07:26 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:
Bug Depends On:    
Bug Blocks: 1043119    
Attachments:
Description Flags
screenshot illustrating the issue (in a VM) none

Description Adam Williamson 2014-06-20 20:20:52 UTC 
With recent Rawhide dedicated install images (not lives), the installer GUI seems to only appear in a corner of the screen, with the rest of the screen blank. A lot of the UI is not visible. I've seen this on bare metal and in a VM, satellit has also seen it, and so has clumens. Screenshot of the 20140619 Rawhide boot.iso's hub screen attached.

Nominating as an Alpha blocker, let's say https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Installation_interfaces "When using the dedicated installer images, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." - it's basically impossible to 'complete an installation' in this way.
Comment 1 Adam Williamson 2014-06-20 20:24:58 UTC 
Created attachment 910889 [details]
screenshot illustrating the issue (in a VM)
Comment 2 Adam Williamson 2014-06-21 00:57:54 UTC 
comparing a 2014-05-12 boot.iso (which is my current 'known good' one) and one that shows this issue, I note that right after "Starting window manager, pid XXXX" in anaconda.log, there is:

Problems running the window manager: [Errno 0] SIGCHLD caught when trying to start the X server.

in the bugged case. That's not there in the working case.

In the bugged case, the pid listed in the "Starting window manager, pid XXXX" message does not show up in 'ps aux' output. In the working case, the pid listed in that message is the pid of the anaconda process itself (the actual window manager, metacity, has a higher pid). In the bugged case, there is an anaconda process running, but with a different pid - in the test I just ran, the message referred to 'pid 1085', while the anaconda process has pid 1001.
Comment 3 Chris Lumens 2014-06-24 19:09:37 UTC 
Yeah, metacity's not starting because there's no libcanberra-gtk3.so.0, which I think is because this needs to be applied:

diff --git a/share/runtime-cleanup.tmpl b/share/runtime-cleanup.tmpl
index c7d345e..5150172 100644
--- a/share/runtime-cleanup.tmpl
+++ b/share/runtime-cleanup.tmpl
@@ -224,7 +224,7 @@ removefrom libbonobo /usr/${libdir}/bonobo/monikers/*
 removefrom libbonobo /usr/${libdir}/orbit-2.0/Bonobo_module.so
 removefrom libcanberra /usr/${libdir}/libcanberra-*
 removefrom libcanberra-gtk2 /usr/${libdir}/gtk-2.0/*
-removefrom libcanberra-gtk3 /usr/bin/* /usr/${libdir}/*
+removefrom libcanberra-gtk3 /usr/bin/*
 removefrom libcap /usr/sbin/*
 removefrom libconfig /usr/${libdir}/libconfig++*
 removefrom libcroco /usr/bin/*
Comment 4 Chris Lumens 2014-06-24 19:10:00 UTC 
At least, running scripts/makeupdates -a ~/libcanberra-gtk3-0.30-6.fc21.x86_64.rpm results in an updates.img that makes my boot.iso work.
Comment 5 Adam Williamson 2014-06-25 02:07:26 UTC 
I believe http://koji.fedoraproject.org/koji/buildinfo?buildID=539896 fixes this: closing (can re-open if it's not resolved in the nightlies, once that util-linux bug is fixed too).