Bug 734993 - Today Fedora 15 installation with updating repo's (no testing) hangs at Date and Time
Summary: Today Fedora 15 installation with updating repo's (no testing) hangs at Date ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-date
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-01 06:16 UTC by Thies Thate
Modified: 2012-08-07 19:21 UTC (History)
12 users (show)

Fixed In Version: system-config-date-1.9.65-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 737882 (view as bug list)
Environment:
Last Closed: 2011-09-13 05:47:26 UTC


Attachments (Terms of Use)

Description Thies Thate 2011-09-01 06:16:12 UTC
Description of problem: 
I try to do a new installation of Fedora 15 with updating repo's (no testing) but installation hangs at entering Date and Time, just before The Hardware Profile.

After doing an other installation without using the update of repo's the installation gives no problem. 

So the problem has been caused by the update repo's part.

Comment 2 Sinan H 2011-09-05 13:43:34 UTC
I've hit the same issue. It just sits there after I click next on the date and time firstboot screen. Switching to VT2 and ps shows that smoltSendProfile is defunct. If i remember correctly, sending the profile is the next step after the date, so it probably comes from there. 
Is there a way to tell the firstboot to skip the smolt step ? Ive also tried "chkconfig firstboot off" but it doesnt stop it to come back on the next reboot :(

Comment 3 Mark Hayes 2011-09-05 22:43:06 UTC
I just ran into this exact same issue while installing Fedora 15 with updates. I rebooted into runlevel 3 and was able to log in, type 'startx' and get into the GUI. I rebooted and got straight in after that. I suppose the other counted as the first boot.

Comment 4 Jan "Tiaan" Kruger 2011-09-06 16:51:44 UTC
A workaround for now:

Switch to VT2, log in as root, then run:

 chkconfig firstboot off
 /bin/systemctl disable firstboot-graphical.service firstboot-text.service
 reboot

You should be prompted with standard login now.

Comment 5 Walter Francis 2011-09-07 14:56:54 UTC
We've seen at least three people in #fedora with this issue, all Fedora 15 installs with updates enabled.

Comment 6 Ben Williams 2011-09-07 14:59:55 UTC
started seeing this same issue on Saturday after creating updated dvd isos with pungi, so it does appear to be something in the updates

Comment 7 Ben Williams 2011-09-08 02:55:22 UTC
New Kernel arrived today, so I created an updated livecd and this problem exist there as well.


My 20110823 livecds do not have this problem, so the problem exists in an updates on or since then

Comment 8 Mads Kiilerich 2011-09-08 09:16:29 UTC
I have seen something similar when trying to generate smolt reports. The root cause turned out to be that the system call made in
  # stat /proc/sys/fs/binfmt_misc
were hanging. The same was seen for some other mount points.

I don't think it was smolt related - a systemd update was the primary suspect. I don't recall exactly where I saw it and I don't see it right now ...

Comment 9 Adam Williamson 2011-09-08 20:04:01 UTC
Ben thinks this is s-c-d, and firstboot does indeed call s-c-d to set the time/date.

Comment 10 Samuel Sieb 2011-09-08 22:12:33 UTC
Same as Bug 734906.

Comment 11 Samuel Sieb 2011-09-08 22:14:28 UTC
Oh, maybe not exactly the same, since Bug 734906 does not cause a hang, you just can't go to the next screen.

Comment 12 Ben Williams 2011-09-08 22:35:30 UTC
confirmed built updated livecd with system-config-date excluded from the updates repos and the problem issue is gone 

problem is with system-config-date-1.9.64-1.fc15.noarch.rpm


At this point this holding up alot of people who create updated spins in one form or another

Comment 13 Nils Philippsen 2011-09-09 12:29:44 UTC
(In reply to comment #2)
> Switching to VT2 and ps shows that smoltSendProfile is defunct. If i remember
> correctly, sending the profile is the next step after the date, so it probably
> comes from there.

(In reply to comment #12)
> problem is with system-config-date-1.9.64-1.fc15.noarch.rpm

This doesn't sit well together.

If neither ntp nor chrony is installed, system-config-date won't let you select NTP for setting the time, that is right and proper. Alternatively, you can set the time manually. AIUI, upon clicking "next", s-c-date will set the date and time and hand off control back to firstboot which apparently has begun with the next step (smolt) when it hangs.

Will: Is sending the smolt profile somehow dependent on system date and time?

> At this point this holding up alot of people who create updated spins in one
> form or another

The obvious workaround is to add ntp or chrony to comps for these spins.

Comment 14 Walter Francis 2011-09-09 12:49:33 UTC
(In reply to comment #13)

> The obvious workaround is to add ntp or chrony to comps for these spins.

ntp IS on the DVD and installed by default, right?  This problem is not just with the respins Ben is doing but also with the DVD install when Updates are enabled, per comment 5.

Comment 15 Nils Philippsen 2011-09-09 13:37:37 UTC
(In reply to comment #14)
> ntp IS on the DVD and installed by default, right?  This problem is not just
> with the respins Ben is doing but also with the DVD install when Updates are
> enabled, per comment 5.

Has anybody tried out to make a spin with s-c-date downgraded to the version before?

Comment 16 Nils Philippsen 2011-09-09 14:45:27 UTC
> Will: Is sending the smolt profile somehow dependent on system date and time?

Martin: how can we find out where (in which step) firstboot is hanging actually?

Comment 17 Nils Philippsen 2011-09-09 15:28:05 UTC
Meanwhile I could reproduce the problem and it's two-fold, the triggering bug is in s-c-date, but a followup one is in firstboot, specifically in its date module:

[...]
    def apply(self, interface, testing=False):
        if testing:
            return RESULT_SUCCESS

        try:
            rc = self.scd.firstboot_apply()
            if rc == 0 and self.scd.closeParent:
                return RESULT_SUCCESS
            else:
                return RESULT_FAILURE
        except:
            return RESULT_FAILURE
[...]

--> this code catches all exceptions raised from self.scd.firstboot_apply() (which makes debugging hard) and apparently (I'm guessing here) causes firstboot to not advance any further in this step (because of "return RESULT_FAILURE"?).

I made that code re-raise the exception and got this:

firstboot 1.119 exception report
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/firstboot/interface.py", line 105, in _nextClicked
    self.advance()
  File "/usr/lib/python2.7/site-packages/firstboot/interface.py", line 148, in advance
    result = module.apply(self, self.testing)
  File "/usr/share/firstboot/modules/date.py", line 54, in apply
    rc = self.scd.firstboot_apply()
  File "/usr/share/system-config-date/scdMainWindow.py", line 213, in firstboot_apply
    return self.apply ()
  File "/usr/share/system-config-date/scdMainWindow.py", line 92, in apply
    self.dateBackend.stopNtpService ()
  File "/usr/lib/python2.7/site-packages/scdate/core/dateBackend.py", line 247, in stopNtpService
    if self.isNtpRunning():
  File "/usr/lib/python2.7/site-packages/scdate/core/dateBackend.py", line 252, in isNtpRunning
    if not os.access(self.ntpConfig, os.R_OK):
TypeError: coercing to Unicode: need string or buffer, NoneType found

Martin, I'll fix this in s-c-date, do you want/need a separate Bugzilla for the firstboot side?

Comment 18 Nils Philippsen 2011-09-09 15:31:25 UTC
Similar traceback when run standalone:

nils@gibraltar:~> system-config-date
Traceback (most recent call last):
  File "/usr/share/system-config-date/scdMainWindow.py", line 75, in ok_clicked
    self.apply ()
  File "/usr/share/system-config-date/scdMainWindow.py", line 92, in apply
    self.dateBackend.stopNtpService ()
  File "/usr/lib/python2.7/site-packages/scdate/core/dateBackend.py", line 247, in stopNtpService
    if self.isNtpRunning():
  File "/usr/lib/python2.7/site-packages/scdate/core/dateBackend.py", line 252, in isNtpRunning
    if not os.access(self.ntpConfig, os.R_OK):
TypeError: coercing to Unicode: need string or buffer, NoneType found

Comment 19 Nils Philippsen 2011-09-09 15:50:33 UTC
fixed in upstream:

commit 4d54c76f13aae2f2dc8932801e595f106b0bff43
Author:     Nils Philippsen <nils@redhat.com>
AuthorDate: Fri Sep 9 17:35:18 2011 +0200
Commit:     Nils Philippsen <nils@redhat.com>
CommitDate: Fri Sep 9 17:35:18 2011 +0200

    cope with neither ntpd nor chrony being installed (#734993)

Comment 20 Nils Philippsen 2011-09-09 15:57:08 UTC
> ntp IS on the DVD and installed by default, right?  This problem is not just
> with the respins Ben is doing but also with the DVD install when Updates are
> enabled, per comment 5.

For whatever reason, neither ntpd nor chrony seems to be installed in this case, I could only reproduce the issue if both are missing.

Comment 21 Scott Dowdle 2011-09-09 16:02:23 UTC
I tested my rebuild and it was broken too.  I did notice that ntp was not installed and I it was not included in the package list in my build .ks file... so I've manually added to the list and am rebuilding.  On previous builds it looks like ntp was there... so my guess is that ntp got removed somewhere as a dependency and with out it firstboot gets stuck.  But then again, perhaps that isn't it and there are other issues.  But in any event, I do need ntp on my build and it wasn't there so adding it doesn't hurt.  Will report back ASAP after rebuilding.

Comment 22 Fedora Update System 2011-09-09 16:03:24 UTC
system-config-date-1.9.65-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/system-config-date-1.9.65-1.fc15

Comment 23 Scott Dowdle 2011-09-09 18:00:52 UTC
Ok, after adding ntp to my build .ks file to ensure it was installed, I did NOT encounter the firstboot issue.  I was get through the date and time selection, and progress through the rest to a successful completion.

Without ntp installed, the Firstboot date/time screen did not have the ntp option selectable... and that is where it would get stuck.  With ntp installed, the ntp option is selectable.

I guess the fix is to alter system-config-date so it can live with ntp missing and so Firstboot won't get stuck.  That is reasonable.  Ideally, I think ntp should be there so that Firstboot won't present a ghosted out option making people wonder... why can't I pick ntp?  But then again, I'd rather have it failsafe if ntp isn't there.

Comment 24 Scott Dowdle 2011-09-09 18:02:58 UTC
Man, my typing today is very much "broken English".  Sorry about that. In my previous post I meant to say, "I was *able to* get through the date and time selection".

Comment 25 Fedora Update System 2011-09-10 00:29:25 UTC
Package system-config-date-1.9.65-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing system-config-date-1.9.65-1.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/system-config-date-1.9.65-1.fc15
then log in and leave karma (feedback).

Comment 26 Andreas Girgensohn 2011-09-10 19:14:23 UTC
I ran into the same problem when installing from the Fedora 15 i386 DVD.  I found a suggestion to use ALT-F4 to get out of the firstboot window and that worked.

ntp was not installed and I had to install it manually.  I picked "Graphical Desktop" and "Customize later".  I deselected the installation repo and selected the network repos with the exception of test updates.

In an earlier installation on the same system, I only selected the installation repo and ntp was included automatically.

Comment 27 Nils Philippsen 2011-09-10 22:50:23 UTC
(In reply to comment #26)
> In an earlier installation on the same system, I only selected the installation
> repo and ntp was included automatically.

It was probably picked up because s-c-date depended on it, which is no longer the case.

Comment 28 Adam Williamson 2011-09-12 22:39:58 UTC
also, you may have checked the 'get system time over the network' checkbox in firstboot before - which would cause ntp to be installed - and you couldn't do it this time because that's where firstboot is hanging...

Comment 29 Fedora Update System 2011-09-13 05:47:19 UTC
system-config-date-1.9.65-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 30 Nils Philippsen 2011-09-13 10:21:32 UTC
(In reply to comment #28)
> also, you may have checked the 'get system time over the network' checkbox in
> firstboot before - which would cause ntp to be installed
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Uhm, no. Previously, ntp was just installed as a dependency of system-config-date, there's been no magic that would have installed it when checking that box.

Comment 31 Nils Philippsen 2011-09-13 10:28:49 UTC
Opoened bug #737882 for the firstboot side of this issue.

Comment 32 Adam Williamson 2011-09-13 18:41:47 UTC
ah, i see. well, i guess we need such magic now then =)

Comment 33 Kevin Kofler 2011-09-22 03:03:53 UTC
We don't install NTP by default anymore? Why?

IMHO having it as a dependency of system-config-date makes a lot of sense. It's customary for programs to have dependencies on stuff needed to make features in their UI actually work. Why was that dropped? Whether the default is the traditional ntpd or chrony doesn't matter as long as any NTP client is dragged in by default.

And IMHO, we should install with NTP enabled (not just installed) by default. I'm totally fed up of computers displaying incorrect times when the technology to keep the time accurate automatically exists.

Comment 34 Nils Philippsen 2011-09-22 08:28:56 UTC
This isn't really the place to discuss this, but anyway: now that it supports both, s-c-date won't make any prescriptions which of these gets installed, I won't add a hard dependency on one or the other. I won't add a hard virtual ntp client dependency either as s-c-date is able to function without and configure machines that simply don't have NTP installed meanwhile. The place to add a default NTP package is comps, or the respective spin configuration.


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