Bug 1111724 - UI only renders in a small area of the screen, with much of it invisible, on dedicated installer images
UI only renders in a small area of the screen, with much of it invisible, on ...
Product: Fedora
Classification: Fedora
Component: lorax (Show other bugs)
All All
unspecified Severity urgent
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
Depends On:
Blocks: F21AlphaBlocker
  Show dependency treegraph
Reported: 2014-06-20 16:20 EDT by Adam Williamson
Modified: 2014-06-25 11:34 EDT (History)
6 users (show)

See Also:
Fixed In Version: lorax-21.12-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-24 22:07:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screenshot illustrating the issue (in a VM) (46.27 KB, image/png)
2014-06-20 16:24 EDT, Adam Williamson
no flags Details

  None (edit)
Description Adam Williamson 2014-06-20 16:20:52 EDT
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 16:24:58 EDT
Created attachment 910889 [details]
screenshot illustrating the issue (in a VM)
Comment 2 Adam Williamson 2014-06-20 20:57:54 EDT
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 15:09:37 EDT
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 15:10:00 EDT
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-24 22:07:26 EDT
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).

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