Bug 734993
Summary: | Today Fedora 15 installation with updating repo's (no testing) hangs at Date and Time | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Thies Thate <mthate90> | |
Component: | system-config-date | Assignee: | Nils Philippsen <nphilipp> | |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | urgent | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 15 | CC: | awilliam, dowdle, haliyo, jbwillia, jkruger, kevin, mads, mark.hayes0338, mgracik, nphilipp, samuel-rhbugs, wally | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | system-config-date-1.9.65-1.fc15 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 737882 (view as bug list) | Environment: | ||
Last Closed: | 2011-09-13 05:47:26 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
Thies Thate
2011-09-01 06:16:12 UTC
Installation done with ftp://ftp.tudelft.nl/pub/Linux/download.fedora.redhat.com/linux/releases/15/Fedora/i386/iso/Fedora-15-i386-DVD.iso and also tested via Fedora-15-i386-netinst.iso (same problem) Checksum for both OK ftp://ftp.tudelft.nl/pub/Linux/download.fedora.redhat.com/linux/releases/15/Fedora/i386/iso/Fedora-15-i386-CHECKSUM 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 :( 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. 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. We've seen at least three people in #fedora with this issue, all Fedora 15 installs with updates enabled. started seeing this same issue on Saturday after creating updated dvd isos with pungi, so it does appear to be something in the updates 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 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 ... Ben thinks this is s-c-d, and firstboot does indeed call s-c-d to set the time/date. Same as Bug 734906. Oh, maybe not exactly the same, since Bug 734906 does not cause a hang, you just can't go to the next screen. 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 (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. (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. (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? > 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?
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? 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 fixed in upstream: commit 4d54c76f13aae2f2dc8932801e595f106b0bff43 Author: Nils Philippsen <nils> AuthorDate: Fri Sep 9 17:35:18 2011 +0200 Commit: Nils Philippsen <nils> CommitDate: Fri Sep 9 17:35:18 2011 +0200 cope with neither ntpd nor chrony being installed (#734993) > 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.
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. 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 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. 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". 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). 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. (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. 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... 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. (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. Opoened bug #737882 for the firstboot side of this issue. ah, i see. well, i guess we need such magic now then =) 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. 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. |