Bug 821077 - Firstboot window does not fit the screen after install from F17 TC4 Final KDE Live
Summary: Firstboot window does not fit the screen after install from F17 TC4 Final KDE...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: firstboot
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Gracik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F17Blocker, F17FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2012-05-11 19:03 UTC by Martin Krizek
Modified: 2013-07-04 13:02 UTC (History)
16 users (show)

Fixed In Version: firstboot-17.3-1.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-19 07:12:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
screenshot (80.84 KB, image/png)
2012-05-11 19:03 UTC, Martin Krizek
no flags Details
dialog over firstboot (108.15 KB, image/png)
2012-05-15 15:29 UTC, Kamil Páral
no flags Details
rpm -qa output (46.52 KB, text/plain)
2012-05-15 15:31 UTC, Kamil Páral
no flags Details
messages (314.14 KB, text/plain)
2012-05-15 15:37 UTC, Kamil Páral
no flags Details
Xorg log (64.34 KB, text/plain)
2012-05-15 15:45 UTC, Kamil Páral
no flags Details
X log (this one is correct) (58.36 KB, text/plain)
2012-05-16 01:07 UTC, Adam Williamson
no flags Details
xwininfo for the firstboot window. (706 bytes, text/plain)
2012-05-16 01:12 UTC, Adam Williamson
no flags Details
messages (tc6) (556.52 KB, application/octet-stream)
2012-05-16 11:42 UTC, Petr Schindler
no flags Details
kwin-wait c code listing (786 bytes, text/plain)
2012-05-16 23:04 UTC, Jaroslav Reznik
no flags Details
More correct code, checks for XFixesSetSelectionOwnerNotify subtype (952 bytes, text/plain)
2012-05-16 23:29 UTC, Jaroslav Reznik
no flags Details
reproducer and fix (1.43 KB, patch)
2012-05-17 17:31 UTC, Brian Lane
no flags Details | Diff

Description Martin Krizek 2012-05-11 19:03:45 UTC
Created attachment 583909 [details]
screenshot

Description of problem:
After installing from KDE Live, F17 TC4 Final, firstboot window appears but does not fit the screen, see attached screenshot. Installed in virt-manager, kvm, libvirt.

Version-Release number of selected component (if applicable):
firstboot 17.2-1

How reproducible:
Always

Steps to Reproduce:
1. Install F17 Final TC4 from KDE Live
2. Reboot
3.
  
Actual results:
firstboot window does not fit the screen

Expected results:
firstboot window fits the screen

Additional info:

Comment 1 Martin Krizek 2012-05-11 19:11:39 UTC
Proposing as Fedora 17 Final blocker per (Alpha) criterion: "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention, unless the user explicitly chooses to boot in non-graphical mode. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The firstboot utility must be able to create a working user account".

Though workaround would be filling user account data in "blindly" as it works but (random) part of the window is not displayed...

Comment 2 Adam Williamson 2012-05-12 01:27:53 UTC
Discussed at the 2012-05-11 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-11/f17-final-blocker-review-meeting-5.2012-05-11-17.04.html . Accepted as a blocker per criterion cited in comment #1.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 Martin Gracik 2012-05-14 06:26:40 UTC
Do you have 2 monitors connected?

Comment 4 Martin Krizek 2012-05-14 07:27:15 UTC
Yes, but as I mentioned I hit this when installing in kvm.

Comment 5 Martin Gracik 2012-05-14 07:34:49 UTC
Could you try the Gnome Live with the same setup and let me know if you encounter the same problem?

Comment 6 Tim Flink 2012-05-14 20:34:23 UTC
Assuming that I understand how to reproduce the issue (install from live in VM), I didn't hit this with an install using the TC5 x86_64 desktop or KDE live.

I'm going to try the i686 lives to see if I can reproduce the issue.

Comment 7 Adam Williamson 2012-05-14 20:56:57 UTC
Wasn't able to reproduce this with the RC4 KDE x86-64 live image in a 17-on-17 KVM, no matter what combination of graphics driver (cirrus/qxl) and viewer (VNC/Spice) I used. I'm inclined to re-vote -1, but I'd like to figure out what causes the problem...



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 8 Kevin Kofler 2012-05-14 21:13:15 UTC
There's a subtle difference in that firstboot will use the window manager provided on the spin, which is KWin on the KDE spin. (We do things this way because otherwise we'd have to carry metacity with all its dependencies just for firstboot to use, and normally firstboot works fine with KWin.)

Comment 9 Adam Williamson 2012-05-14 23:23:19 UTC
Kevin: yes, I know. I tested with the KDE live image. I couldn't reproduce this.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 10 Tim Flink 2012-05-15 01:05:35 UTC
I've now tried with all 4 lives (gnome and kde, x86_64, i686) in qemu/KVM VMs on F16 and have not been able to reproduce this bug once.

I tried a whole bunch of driver combos with the kde-i686 live install but all of them were able to display firstboot without issue.

For the record, my virt host is also a multi-monitor system.

Comment 11 Martin Gracik 2012-05-15 06:15:05 UTC
That's good to hear :)

Comment 12 Kamil Páral 2012-05-15 11:18:08 UTC
I wasn't able to reproduce this with TC5 (both architectures tested). I used qxl+spice.

But Petr Schindler saw something similar with his custom-made TC6. So I recommend to re-test this with official TC6 before we close this.

Comment 13 Jaroslav Reznik 2012-05-15 12:43:04 UTC
Hmm, can't reproduce it with TC5 (installed several times today...).

Comment 14 Kamil Páral 2012-05-15 12:53:01 UTC
Petr Schindler has just reproduced it once out of two attempts. He used official TC5, cirrus+VNC, and he has F17 host. Martin also has F17 host I believe.

Petr is now performing more installations to get better statistics.

Comment 15 Petr Schindler 2012-05-15 13:25:20 UTC
I reproduced this with TC5-x86_64-DVD.iso. I installed system only with KDE
package collection and first boot didn't fit screen.

I used vm with cirrus/VNC and qxl/spice.

I have f17 host. I reproduced it three times (of 4 attempts).

Comment 16 Jaroslav Reznik 2012-05-15 14:32:03 UTC
(In reply to comment #15)
> I reproduced this with TC5-x86_64-DVD.iso. I installed system only with KDE
> package collection and first boot didn't fit screen.
> 
> I used vm with cirrus/VNC and qxl/spice.
> 
> I have f17 host. I reproduced it three times (of 4 attempts).

I used the same image you provided me, with selected KDE collection but still no luck to reproduce it... Could you share the installed package list?

Comment 17 Kamil Páral 2012-05-15 15:26:56 UTC
OK, I reproduced it as well. It did not happen with LiveCDs to me, but when I used TC5 DVD x86_64, unselected GNOME collection and selected KDE collection, I reproduced it in 2 out of 2 attempts.

First a white square appears on the screen, then firstboot is shown in the lower right corner, and then it moves to the right half of the screen. The screen flickers several times.
http://imgur.com/a/WVmIp

I hard rebooted the VM several times at that point and firstboot always appeared corrupted after reboot.

Comment 18 Kamil Páral 2012-05-15 15:29:25 UTC
Created attachment 584694 [details]
dialog over firstboot

It is interesting that a confirmation dialog appears in the center of the screen correctly.

Comment 19 Kamil Páral 2012-05-15 15:31:31 UTC
Created attachment 584695 [details]
rpm -qa output

Comment 20 Kamil Páral 2012-05-15 15:37:36 UTC
Created attachment 584698 [details]
messages

This is /var/log/messages after _one further reboot_, but firstboot messages are easy to find there.

Comment 21 Adam Williamson 2012-05-15 15:42:31 UTC
May 15 11:17:02 localhost firstboot[569]: kdeinit4: Aborting. $HOME not set!kwin(698): OpenGL Software Rasterizer detected. Falling back to XRender.
May 15 11:17:02 localhost firstboot[569]: kwin(698): Failed to initialize compositing, compositing disabled
May 15 11:17:02 localhost firstboot[569]: kwin(698): Consult http://techbase.kde.org/Projects/KWin/4.0-release-notes#Setting_up
May 15 11:17:03 localhost firstboot[569]: kdeinit4: Aborting. $HOME not set!kwin(698): Couldn't start kglobalaccel from kglobalaccel.desktop:  "KLauncher could not be reached via D-Bus. Error when calli



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 22 Kamil Páral 2012-05-15 15:45:32 UTC
Created attachment 584700 [details]
Xorg log

This is an Xorg log retrieved after finishing corrupted firsboot and logging in into KDE session.

Comment 23 Adam Williamson 2012-05-15 16:02:55 UTC
You probably want Xorg.0.log.old , I think, as once firstboot is finished, X gets restarted.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 24 Kamil Páral 2012-05-15 16:53:22 UTC
(In reply to comment #23)
> You probably want Xorg.0.log.old , I think, as once firstboot is finished, X
> gets restarted.

When looking at last-modified date I didn't have that feeling, but I could be wrong. If needed I can re-introduce the bug (make firstboot start again is sufficient) and post new logs.

Comment 25 Adam Williamson 2012-05-16 01:06:37 UTC
The relevant X log is Xorg.9.log, as firstboot runs on an X server on display :9. Attaching mine. I reproduced this on second attempt with a DVD install selecting KDE and de-selecting GNOME - on the first boot firstboot rendered correctly, on the second it was shifted to the right and down. Expanding the virt-manager window does not reveal more of firstboot. DISPLAY=:9 xrandr from a console says it is using mode 1024x768. The cursor is a pointer when moving around the area of the display where firstboot is rendered, but the old X 'black x' when moving around the black area; further, it flickers when being moved around this area (but stays solid when sitting still).



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 26 Adam Williamson 2012-05-16 01:07:47 UTC
Created attachment 584823 [details]
X log (this one is correct)

Comment 27 Adam Williamson 2012-05-16 01:12:27 UTC
Created attachment 584824 [details]
xwininfo for the firstboot window.

Comment 28 Adam Williamson 2012-05-16 01:37:18 UTC
So, I just made firstboot run correctly seven times in a row by commenting out line 95 of /usr/sbin/firstboot:

         frontend.merge_xres()

this runs 'xrdb -merge'. interestingly, it was broken for some time - it ran 'xrdb --merge', which produced a usage error in the logs. This was filed as https://bugzilla.redhat.com/show_bug.cgi?id=808919 and 'fixed' in firstboot-17.2-1.fc17, which went stable on 2012-05-04. So that would tally with the error showing up around 2012-05-08 (which is the earliest report we have of it so far, from a nightly of that date).

I have no idea why firstboot needs to / bothers running xrdb at all. Commenting out that line produces no obvious ill effects, and it was obviously broken for some time without anyone noticing any problems caused by it. Perhaps we should take it out?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 29 Adam Williamson 2012-05-16 01:38:10 UTC
...of course, the first reboot after I posted that comment, it breaks again. siiiigh. so that's not it.

Comment 30 Rex Dieter 2012-05-16 02:05:44 UTC
reproduced on my first try on bare metal (an oldish laptop, may be exposing some other kind of race).  I'll try a few more reboots.

Comment 31 Rex Dieter 2012-05-16 03:36:00 UTC
So, after about 30 more reboots, I think I've found what may be a pattern:

* with no /root/.gtkrc-2.0 , I was able to reproduce this about 1/3 of the time (5 out of 15 iirc)

* with a /root/.gtkrc-2.0 specifying oxygen-gtk style, (per recent spin-kickstarts commit:
https://fedorahosted.org/spin-kickstarts/changeset/97615d0fc8d052cbc88c2056ddb40935f37a2496/fedora-live-kde-base.ks

I was no longer able to reproduce in 15 tries.


For those of you experiencing this, I'd invite you to test the same:

cat > /root/.gtkrc-2.0 << EOF 
include "/usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc" 
include "/etc/gtk-2.0/gtkrc" 
gtk-theme-name="oxygen-gtk" 
EOF

and see if adding this helps you too.  (of course, this doesn't help DVD installs)

Comment 32 Adam Williamson 2012-05-16 05:59:38 UTC
So. Um. This is odd. I installed TC6 from DVD (not live!) and just can't reproduce this any more. But AFAICS TC6 doesn't have any 'fix' for this wrt the DVD. The change Rex mentions relates to the live image only. There is no /root/.gtkrc-2.0 file after install. But still, I just can't reproduce the bug.

It's not kde-settings either, as that seems to be 4.8-10.fc17 in both TC5 and TC6.

So I'm somewhat confused, now. Still, can people please test if they can reproduce this with TC6? Thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 33 Martin Gracik 2012-05-16 06:28:39 UTC
So from what the reproducers are saying, if GNOME is installed, firstboot uses metacity and it works. Metacity has priority over kwin, if both are installed. So this only happens when firstboot uses kwin as the window manager.

Comment 34 Adam Williamson 2012-05-16 06:49:22 UTC
Well, yes. But I can't reproduce in TC6 even without metacity installed.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 35 Petr Schindler 2012-05-16 11:40:10 UTC
I reproduced it again with TC6.

INFO: f17 guest, virt-manager, x86_64, cirrus/VNC.

I tried to reboot several times and it happens almost every time.

Comment 36 Petr Schindler 2012-05-16 11:42:10 UTC
Created attachment 584941 [details]
messages (tc6)

Comment 37 Kamil Páral 2012-05-16 11:46:24 UTC
I also reproduced it with TC6 DVD x86_64, same as Petr. qxl+spice.

Comment 38 Tom "spot" Callaway 2012-05-16 15:44:16 UTC
Just a shot in the dark here, but if kwin is the culprit here, perhaps a workaround would be to specify a position for firstboot in a kwinrulesrc?

Comment 39 Martin Gracik 2012-05-16 15:55:26 UTC
I don't specify absolute position in firstboot. The window is placed in the center with

self.win.set_position(gtk.WIN_POS_CENTER)

and then resized to the monitor dimensions, then made fullscreen.

So maybe in kwin the resize works a bit differently and the top left corner does not get moved after the resize?

I'm thinking this should be reassigned to kwin. Metacity works as expected.

Comment 40 satellitgo 2012-05-16 17:56:30 UTC
Just used dd of KDE live RC1 x86_64 to install to external USB HD on 10" Acer Aspire One N450 netbook. Firstboot screen looks fine here I can see (forward) in bottom right corner  logs in fine from HD

Comment 41 Kamil Páral 2012-05-16 19:29:53 UTC
> For those of you experiencing this, I'd invite you to test the same:
> 
> cat > /root/.gtkrc-2.0 << EOF 
> include "/usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc" 
> include "/etc/gtk-2.0/gtkrc" 
> gtk-theme-name="oxygen-gtk" 
> EOF
> 
> and see if adding this helps you too.  (of course, this doesn't help DVD
> installs)

This does not help in my case (see comment 37). DVD install. Even after creating .gtkrc-2.0 firstboot is sometimes ill-placed (sometimes not).

Comment 42 Kamil Páral 2012-05-16 20:36:48 UTC
I have edited firstboot script and placed "time.sleep(10)" directly under frontend.start_wm(). It fixed the problem for me, I have now 10 successful boots in a row (which is a success rate I've never had before). There's probably some race condition between firstboot and the window manager.

Comment 43 Adam Williamson 2012-05-16 20:46:45 UTC
ajax believes this is a race between kwin startup and startup of firstboot itself. if firstboot's interface initializes before kwin is actually ready, the problem occurs.

he has an idea for a better fix than just sticking an arbitrary timeout in firstboot, and is working on it now.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 44 Jaroslav Reznik 2012-05-16 23:04:06 UTC
Created attachment 585072 [details]
kwin-wait c code listing

Based on ajax proposal - this should wait until WM is available. I'm no X guy, so... Just quick hack.

gcc kwin-xwait.c -o kwin-xwait -lX11 -lXfixes

Comment 45 Adam Williamson 2012-05-16 23:12:34 UTC
ajax, airlied - could one of you please review jaro's code? thanks! we really need a fix for this ASAP.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 46 Jaroslav Reznik 2012-05-16 23:29:03 UTC
Created attachment 585074 [details]
More correct code, checks for XFixesSetSelectionOwnerNotify subtype

Comment 47 Adam Williamson 2012-05-16 23:39:32 UTC
What the hell, CCing clumens. we really need this reviewed and packaged, guys. so close to RC2.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 48 Martin Gracik 2012-05-17 07:20:23 UTC
That's not an acceptable fix for me. I'm not gonna put that in firstboot and maintain it. Firstboot is not a place for some X hacks.

Comment 49 Michal Schmidt 2012-05-17 07:31:09 UTC
Martin, do you see any alternative solution though?

Comment 50 Adam Williamson 2012-05-17 07:31:20 UTC
You need to propose an alternative, then. Why is it not firstboot's responsibility to ensure the WM is ready before it starts running?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 51 Jaroslav Reznik 2012-05-17 07:59:51 UTC
From my understanding it's common way (and probably the only one) to check if WM is running and it's used in all WMs. Firstboot has to ensure that WM is running, it can theoretically affect Metacity too. There's still the question why it hit KWin right now, startup changes (optimalization) should be in 4.9...

Comment 52 Michal Schmidt 2012-05-17 08:43:58 UTC
For better understanding of the proposed fix, here is what ajax said on #fedora-devel yesterday:

<ajax>  mini-wm had code to tell the launching process after it had actually set up as a window manager
<ajax>  and anamaconda would wait until that actually happened before creating the UI window
<ajax>  firstboot does not appear to have this property, so there's a race: you fork off the window manager, and that succeeds, and then you go
 off and make your UI, and that might get created _before_ kwin is actually being a window manager
<ajax>  ie that you'd map the window without a wm running, and then when the wm starts it repositions according to god knows what, that bit never works right.
...
<ajax>  adamw: well, okay, so the way you'd fix this in C is: before you launch the window manager, launch a little X application that does XFixesSelectSelectionInput(dpy, w, WM_S0, SetSelectionOwner), waits for the event, and then exits.  WM_S%d is the name pattern for the X selection that means "there is a window manager on screen %d", which is how the --replace trick works since selections have owners.
<ajax>  and then you'd make firstboot launch that, then launch the wm, then wait for the helper to exit, then carry on.

Comment 53 Martin Gracik 2012-05-17 10:29:14 UTC
If it can't be done in python, I will rather put in the sleep thing...

Comment 54 Adam Williamson 2012-05-17 10:47:24 UTC
The problem with a sleep is it's pretty arbitrary. How long should we sleep for? Who knows? How long is a piece of string? It's a clear bodge. What it ought to do is wait for the WM to be ready.

Why is it any worse to call a little 'wait-for-wm' helper written in C than it is to call a window manager written in C?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 55 Kamil Páral 2012-05-17 11:21:40 UTC
If we decide to put sleep() in there, I have tested a few numbers. Without sleep, I have about 50% success rate. With 1 or 2 second sleep, the success rate was higher, but it was still ill-placed sometimes. Only with 3 second sleep I achieved 100% success rate (10 attempts). To be fully sure no one hits this firstboot must contain 4 or 5 second sleep.

Of course, this is a very dirty solution and having the C helper included should be much cleaner (and faster and safer).

Comment 56 Kevin Kofler 2012-05-17 11:57:32 UTC
+1, sleep() is a bad solution.

Comment 57 Chris Lumens 2012-05-17 14:09:24 UTC
The obvious problem with a sleep is that it's going to have to be a different amount of time depending on harware specs, work load (how much other stuff is starting up in the background while the machine boots), etc.  Definitely don't want to do it.

Comment 58 Martin Gracik 2012-05-17 14:43:02 UTC
The problem with that C code is that I don't want to have it in firstboot. Why can't the "wait-for-wm" helper be in some other package? I can call it then from firstboot. And maybe it will be useful to someone else too.

Comment 59 Jaroslav Reznik 2012-05-17 15:11:16 UTC
(In reply to comment #58)
> The problem with that C code is that I don't want to have it in firstboot. Why
> can't the "wait-for-wm" helper be in some other package? I can call it then
> from firstboot. And maybe it will be useful to someone else too.

It could be in a different package but I'm not sure it makes sense for such small helper.

There's XFixes support in Python XLib but only in trunk, not packaged in Fedora...

So from Python maybe something like?
display = Display()
selection_atom = display.intern_atom("WM_S0")
window = display.get_selection_owner(selection_atom)
and then check if window is not None?

But
[17:05] <ajax> you probably want not to use both python-xlib and pygtk in the same process
[17:05] <ajax> they each use their own display connection.  the event loop would be tortured to handle both.

Comment 60 Tom "spot" Callaway 2012-05-17 17:18:36 UTC
(In reply to comment #46)
> Created attachment 585074 [details]
> More correct code, checks for XFixesSetSelectionOwnerNotify subtype

Jaroslav, if you can tell me what the license is on this file, I will package it.

Comment 61 Brian Lane 2012-05-17 17:31:30 UTC
Created attachment 585280 [details]
reproducer and fix

I think I have a solution for this. Instead of setting the window position to WIN_POS_CENTER set it to WIN_POS_NONE, this lets the WM put the window wherever it wants once it comes up. It also needs to set the main window size to match the screen.

This patch also include a 10s sleep BEFORE launching the WM, this should reliably reproduce the problem and demonstrate that the fix works. You can see the original behavior by changing WIN_POS_NONE back to WIN_POS_CENTER

I have tested with KDE live and will test with Desktop live as well as GNOME DVD install.

Comment 62 Adam Williamson 2012-05-17 17:38:42 UTC
We'd also want to test with at least Xfce and LXDE lives; one or other of 'em uses openbox, I think.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 63 Kevin Kofler 2012-05-17 18:01:44 UTC
IIRC, Xfce uses xfwm, LXDE uses Metacity for firstboot because openbox doesn't understand the parameters firstboot passes.

Comment 64 Adam Williamson 2012-05-17 18:10:42 UTC
I think that got patched. openbox is in firstboot's list of Acceptable Window Managers, anyhow.

/usr/lib/python2.7/site-packages/firstboot/constants.py-WMS = ('metacity',
/usr/lib/python2.7/site-packages/firstboot/constants.py-       'kwin',
/usr/lib/python2.7/site-packages/firstboot/constants.py-       'xfwm4',
/usr/lib/python2.7/site-packages/firstboot/constants.py:       'openbox')

so those would be the ones to test. Someone remind me why we thought this was such a great idea? Sigh.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 65 Brian Lane 2012-05-17 18:51:30 UTC
metacity and kde work fine. I need to fix or work around 750002 before I can try xfwm4 on XFCE since it is currently failing to install for me.

I've tested Live-Desktop, KDE and LXDE in a virt and KDE with 2 monitors.

Comment 66 Adam Williamson 2012-05-17 19:39:47 UTC
I tried it with Xfce spin, it works fine. But Xfce spin seems to use metacity for firstboot, as it gets pulled into the spin via gdm (which Xfce uses for login). So that's no surprise. :)

I'd say go ahead and do a build/update with this fix (obviously without the sleep). We can test it. Thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 67 Fedora Update System 2012-05-17 20:07:36 UTC
firstboot-17.3-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/firstboot-17.3-1.fc17

Comment 68 Fedora Update System 2012-05-17 22:58:53 UTC
Package firstboot-17.3-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing firstboot-17.3-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-7992/firstboot-17.3-1.fc17
then log in and leave karma (feedback).

Comment 69 satellitgo 2012-05-18 01:43:07 UTC
I have seen this on a new RC1 KDE x86_64 HD install. 
firstboot screen was on bottom right corner with (foreward) button not visible. I hit power button and rebooted and second time firstboot screen was centered and the right size. Hit power button and rebooted and on 3rd try firstboot screen was again correct. Is this a quick and dirty fix? (power off and restart to get firstboot to work)? 

Repeated 4th time and it was misplaced again right and down.On 5th time It was again correct.???

Comment 70 Kevin Kofler 2012-05-18 04:29:07 UTC
> openbox is in firstboot's list of Acceptable Window Managers, anyhow.

It's in the list, and openbox also "Provides: firstboot(windowmanager)", but to the best of my knowledge, it never actually worked. The problem was "fixed" by dragging in metacity from the LXDE live kickstart (because the problem was noticed in a release's deep freeze and this avoided having to push an updated openbox to drop the Provides) and the "fix" stuck.

Comment 71 Adam Williamson 2012-05-18 09:00:02 UTC
sat: yeah, just rebooting is a reasonable way to workaround the problem if you hit it.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 72 satellitgo 2012-05-18 12:04:56 UTC
firstboot 17.3-1.fc17
HD install of DVD (l-i-t-d-USB of RC1 x86_64 with http://repos.fedorapeople.org/repos/tflink/f17preRC2/fedora-17/x86_64/ tested firstboot 3 x (power off before completion-reboot) always centered on ACER ASPIRE ONE N450 IGD graphics
bodhi - 2012-05-18 05:02:10
This update has reached the stable karma threshold and will be pushed to the stable updates repository

Comment 73 Tim Flink 2012-05-18 21:17:39 UTC
Discussed in the 2012-05-18 blocker bug review meeting. The update from comment #67 was included in Fedora 17 final RC2 - this needs testing to determin whether or not this bug can be closed

Comment 74 Fedora Update System 2012-05-19 07:12:13 UTC
firstboot-17.3-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 75 Kamil Páral 2012-05-21 11:53:56 UTC
I can confirm this is fixed in F17 RC2.


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