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:
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...
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
Do you have 2 monitors connected?
Yes, but as I mentioned I hit this when installing in kvm.
Could you try the Gnome Live with the same setup and let me know if you encounter the same problem?
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.
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
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.)
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
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.
That's good to hear :)
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.
Hmm, can't reproduce it with TC5 (installed several times today...).
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.
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).
(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?
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.
Created attachment 584694 [details] dialog over firstboot It is interesting that a confirmation dialog appears in the center of the screen correctly.
Created attachment 584695 [details] rpm -qa output
Created attachment 584698 [details] messages This is /var/log/messages after _one further reboot_, but firstboot messages are easy to find there.
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
Created attachment 584700 [details] Xorg log This is an Xorg log retrieved after finishing corrupted firsboot and logging in into KDE session.
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
(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.
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
Created attachment 584823 [details] X log (this one is correct)
Created attachment 584824 [details] xwininfo for the firstboot window.
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
...of course, the first reboot after I posted that comment, it breaks again. siiiigh. so that's not it.
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.
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)
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
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.
Well, yes. But I can't reproduce in TC6 even without metacity installed. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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.
Created attachment 584941 [details] messages (tc6)
I also reproduced it with TC6 DVD x86_64, same as Petr. qxl+spice.
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?
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.
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
> 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).
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.
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
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
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
Created attachment 585074 [details] More correct code, checks for XFixesSetSelectionOwnerNotify subtype
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
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.
Martin, do you see any alternative solution though?
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
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...
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.
If it can't be done in python, I will rather put in the sleep thing...
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
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).
+1, sleep() is a bad solution.
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.
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.
(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.
(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.
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.
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
IIRC, Xfce uses xfwm, LXDE uses Metacity for firstboot because openbox doesn't understand the parameters firstboot passes.
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
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.
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
firstboot-17.3-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/firstboot-17.3-1.fc17
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).
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.???
> 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.
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
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
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
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.
I can confirm this is fixed in F17 RC2.