Bug 694290

Summary:	xorg session starts and hides firstboot at hardware profile page
Product:	[Fedora] Fedora	Reporter:	Need Real Name <karlcz>
Component:	ntp	Assignee:	Miroslav Lichvar <mlichvar>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	15	CC:	bcl, lpoetter, mgracik, mlichvar, nphilipp, pertusus
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-04-07 15:23:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Need Real Name 2011-04-06 21:08:02 UTC

Description of problem:

I'm not sure if this should be assigned to firstboot or systemd...

During graphical firstboot, after enabling NTP and synchronizing the clock, a new X server w/ GDM starts and becomes the active console.  You have to know that firstboot is not done, and manually switch console back with ctl-alt-F1 in order to see the hardware profile screen and complete the firstboot session.

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

firstboot-1.117-2.fc15.x86_64
systemd-22-1.fc15.x86_64


How reproducible:

Not sure

Steps to Reproduce:
1. boot using the pxeboot kernel and initrd.img installer
2. install a default graphics workstation, using the network
3. reboot into firstboot
4. advance and click to enable NTP
5. advance and it shows a modal dialog about synchronizing the clock
  
Actual results:

firstboot disappears before completing, as described above.

Expected results:

firstboot continues, and user completes tasks before GDM becomes visible

Additional info:

This was from a fresh network install today, using pxeboot installer via GRUB (on a laptop without a CD drive).

I also enabled the "encrypt system" option. I don't know if that affects the firstboot sequence in any significant way.

Comment 1 Martin Gracik 2011-04-07 08:03:36 UTC

Yes, I found about this myself yesterday, so I did already some investigations.

The gdm is run during the execution of code in scdMainWindow.py apply() method from system-config-date. I don't know which part exactly causes systemd to run gdm, even though firstboot is not finished yet.

Comment 2 Nils Philippsen 2011-04-07 09:04:49 UTC

Obviously s-c-date doesn't do anything with gdm, I imagine that gdm is started as a side-effect of starting or stopping ntpd in the apply() method. Here are the relevant parts, I've added comments describing the resulting /sbin/service or /sbin/chkconfig calls:

class scdMainWindow(object):
    [...]
    def apply (self):
        [...]
        if ntpEnabled == False:
            # We're not using ntp, so stop the service
            self.dateBackend.stopNtpService ()
            # --> /sbin/service ntpd stop
            [...]
            self.dateBackend.chkconfigOff ()
            # --> /sbin/chkconfig --level 2345 ntpd off

        elif ntpEnabled == True:
            # We want to use NTP
            [...]
            pid = os.fork ()

            if pid == 0:
                [...]
                retval = self.dateBackend.startNtpService (None)
                # --> /sbin/service ntpd (re)start
                [...]
                os._exit (0)
            [...]
            self.dateBackend.chkconfigOn ()
            # --> /sbin/chkconfig --level 2345 ntpd on

        [...]

I'll change the component to ntp for further examination and add Lennart to Cc. Lennart, do you have an idea how starting/stopping ntpd this way can cause gdm to start prematurely?

Comment 3 Lennart Poettering 2011-04-07 15:23:52 UTC

It's a bug in systemd. Nothing wrong in firstboot.

*** This bug has been marked as a duplicate of bug 694079 ***