Bug 704042 - X fails to start after firstboot in 15 Final RC1 - dconf-0.7.5-1 from updates-testing appears to fix it
Summary: X fails to start after firstboot in 15 Final RC1 - dconf-0.7.5-1 from updates...
Keywords:
Status: CLOSED DUPLICATE of bug 702963
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 15
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Bill Nottingham
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F15Blocker, F15FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2011-05-11 22:54 UTC by Andre Robatino
Modified: 2014-03-17 03:27 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-12 17:05:58 UTC
Type: ---


Attachments (Terms of Use)
/var/log/Xorg.0.log from the default 15 Final RC1 i386 DVD install (55.29 KB, text/plain)
2011-05-11 22:54 UTC, Andre Robatino
no flags Details
/var/log/Xorg.0.log from the default 15 Final RC1 i386 DVD install using KVM this time (27.01 KB, text/plain)
2011-05-12 00:32 UTC, Andre Robatino
no flags Details

Description Andre Robatino 2011-05-11 22:54:41 UTC
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.

Comment 1 Andre Robatino 2011-05-12 00:21:56 UTC
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.

Comment 2 Andre Robatino 2011-05-12 00:32:35 UTC
Created attachment 498417 [details]
/var/log/Xorg.0.log from the default 15 Final RC1 i386 DVD install using KVM this time

Comment 3 Ben Williams 2011-05-12 00:57:56 UTC
Installed with the Netinstall.iso using VMWare Player
installs and firstbook run then on the reboot X crashes repeatedly

confirming comment 1

Comment 4 Stephen John Smoogen 2011-05-12 01:04:30 UTC
Confirmed in KVM with vmvga driver also.

Comment 5 satellitgo 2011-05-12 03:25:58 UTC
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

Comment 6 Adam Williamson 2011-05-12 03:57:06 UTC
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

Comment 7 satellitgo 2011-05-12 04:48:10 UTC
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

Comment 8 Andre Robatino 2011-05-12 05:49:09 UTC
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.

Comment 9 satellitgo 2011-05-12 06:07:33 UTC
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

Comment 10 satellitgo 2011-05-12 08:30:57 UTC
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

Comment 11 He Rui 2011-05-12 09:00:12 UTC
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.

Comment 12 Andre Robatino 2011-05-12 11:04:29 UTC
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

Comment 13 James Laska 2011-05-12 11:50:11 UTC
(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?

Comment 14 Adam Williamson 2011-05-12 14:43:21 UTC
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

Comment 15 James Laska 2011-05-12 15:19:02 UTC
(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

Comment 16 Adam Williamson 2011-05-12 17:05:58 UTC
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 ***


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