Bug 704042

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 ***