Created attachment 498408 [details] /var/log/Xorg.0.log from the default 15 Final RC1 i386 DVD install Description of problem: After successfully completing a 15 Final RC1 default DVD install (either i386 or x86_64) in VirtualBox 4.0.6, and completing firstboot, X fails to start. I can switch to VT2 and confirm that the ordinary user account was created, at least. I have no idea what the correct Component is, and don't know yet if using VirtualBox is responsible. However, this would be a F15 Blocker even if it was limited to the VESA driver. Version-Release number of selected component (if applicable): 15 Final RC1 How reproducible: always Steps to Reproduce: 1. Do a default 15 Final RC1 DVD install (either i386 or x86_64). 2. Reboot, complete firstboot successfully. Actual results: X makes several unsuccessful attempts to start. Can log in via VT. Expected results: X should start automatically.
Behavior is similar using KVM (cirrus) with the 15 Final RC1 i386 DVD, although it seems to just keep trying and failing to start X (so I can't get to a VT), instead of giving up after a few tries as happened in VirtualBox (vesa). So it seems to be basically independent of both video card and arch.
Created attachment 498417 [details] /var/log/Xorg.0.log from the default 15 Final RC1 i386 DVD install using KVM this time
Installed with the Netinstall.iso using VMWare Player installs and firstbook run then on the reboot X crashes repeatedly confirming comment 1
Confirmed in KVM with vmvga driver also.
f15 DVD RC1 Install to USB external Disk from DVD custom /boot ext4 500 / ext4 balance of disk -1000 swap 1000 gnome and sugar Desktop selected 3 repos selected: DVD f15 f15 updates testing Boots to firstboot, time, user, gdm login gnome starts gnome3-shell 3.0.1 on ACER ASPIRE ONE N450 Logout login gdm to sugar sugar 15 0.92.1 Jabber is connected (probably because I downloaded the 2 repos) this meant initializing eth0 wireless will not connect due to NetworkManager mismatch Will now try just DVD gnome install to same HD
I see this with a Spice-backed virt-manager VM too, using the DVD with no other repos. +1 blocker. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
DVD install to USB HD: confirmed with just DVD repo and gnome selected X makes several unsuccessful attempts to start can log in from alt f5 to new user and su works to get root terminal reboot ends: Started SYSV: enable monthly update of smolt.....monitor..ABRT dump directories for each oops....resses. It must be running on 5 minutes hung here...... failed. will retry with repos enabled
Updating dconf from the installed 0.7.4-1 to the 0.7.5-1 updates-testing version seems to fix this. Strangely, the problem is gone even if dconf is then downgraded to 0.7.4-1 again. https://admin.fedoraproject.org/updates/dconf-0.7.5-1 refers to fixing a problem when the user has no database yet, but doesn't say what it is or give a bug number, and I don't see anything obvious in Bugzilla.
I also see the failure if install from f15 repo only is used (DVD is not selected) will test next with f15 and f15 updates testing selected
f15 DVD RC1 Install to USB external Disk from DVD custom /boot ext4 500 / ext4 balance of disk -1000 swap 1000 gnome 2 repos selected: f15 f15 updates testing Boots to firstboot, time, user, gdm login gnome starts gnome3-shell 3.0.1 on ACER ASPIRE ONE N450 Updates testing repo fixed boot problem
This issue happened both in KVM and bare metal with DVD graphical default install. After a fully update enabling updates-testing, X could start. +1 blocker.
Workaround: 1) yum --enablerepo=updates-testing update dconf (from a VT or runlevel 3) 2) Boot into now working X 3) yum downgrade dconf (don't even have to log in, can do this from a VT) 4) X continues to work
(In reply to comment #12) > Workaround: > > 1) yum --enablerepo=updates-testing update dconf (from a VT or runlevel 3) This should have installed dconf-0.7.5-1 > 2) Boot into now working X > > 3) yum downgrade dconf (don't even have to log in, can do this from a VT) This should have downgraded to dconf-0.7.3-2 > 4) X continues to work So I take it that means dconf-0.7.4-1 is causing the issues?
I think it's rather than 0.7.5-1 does a one-time thing that 0.7.4-1 doesn't do, and from then on, any dconf will work. From dconf NEWS: Changes in dconf 0.7.5 ====================== This release corrects a serious flaw in the previous release: crashing if the database did not already exist. See comment #8: I think what happens is 0.7.4 crashes since there's no database. If you upgrade to 0.7.5 it runs and creates the database; then after that, 0.7.4 will work because there is now a database. Shipping 0.7.3 or 0.7.5 would fix this, I think, as the NEWS file reads like the bug was introduced in 0.7.4. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #14) > I think it's rather than 0.7.5-1 does a one-time thing that 0.7.4-1 doesn't do, > and from then on, any dconf will work. Good catch. I'm +1 blocker as this seems to affect the following F15 Alpha release criteria [1] "Following on from the previous criterion, after firstboot is completed and on subsequent boots, 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 a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied " [1] https://fedoraproject.org/wiki/Fedora_15_Alpha_Release_Criteria
we actually have a pre-existing bug for this... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** This bug has been marked as a duplicate of bug 702963 ***