Bug 357311
| Summary: | firstboot refuses to go forward under Xen (due to hwclock error) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Eduardo Habkost <ehabkost> |
| Component: | system-config-date | Assignee: | Nils Philippsen <nphilipp> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | 142.bugzilla.redhat, katzj, wwoods |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 1.9.32-1.fc8 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-07-09 02:42:46 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 235703 | ||
|
Description
Eduardo Habkost
2007-10-29 20:46:20 UTC
system-config-date could give a better message here, but it's not a problem if you don't select to use NTP. And up until very recently, there was a bug causing ntp to be selected by default. With today's rawhide, confirmed that that isn't the case. Given this, dropping from blocker and reassigning (In reply to comment #1) > system-config-date could give a better message here, but it's not a problem if > you don't select to use NTP. I don't know if I understood you correctly, but it seems to be de opposite: the problem happens when NTP is _not_ selected. If I do select to use NTP, firstboot goes forward after contacting the NTP server. At least selecting NTP is a workaround for the problem. NB: Fixing this would cause translations to break, so I'll defer this until after F8 is out. NB2: Is there already a bug for the hwclock on Xen issue? (In reply to comment #4) > NB2: Is there already a bug for the hwclock on Xen issue? hwclock isn't supposed to work inside a Xen guest. It is a feature. I have discussed the problem with the team, and concluded enabling NTP is not a valid workaround for the problem. It makes no sense to run NTP in a guest because its clock is synced to the host. Re-adding to F8Blocker. Furthermore, any user trying to install a guest will have no clue that 'enabling NTP' is the thing which magically makes the 'next' button work again. ALl they'll see is that firstboot refuses to goto the next screen. Enabling NTP is not an easily discoverable workaround. No, disabling NTP is the key. And it is disabled by default currently. It was being enabled by default for a little while due to ntp changes. Of course, the xen0 kernel being multiple revs back leads to it having weirdo irq problems on one of my boxes and the other one is hanging when trying to do anything with a guest. So - the default behavior (NTP disabled) works fine, but enabling NTP will cause firstboot to get stuck? And NTP is known not to work in Xen guests anyway? This sounds like a release note/common bug to me. NTP was alwasy disabled when the bug was reproduced. The problem happens when NTP is _disabled_, and enabling it isn't a valid workaround on a Xen guest. So what exactly is s-c-date supposed to do in a Xen guest? I've the feeling it's a bit late for stuff that needs UI changes that aren't i18n neutral. We could try to open /dev/rtc and if we get ENODEVICE, then just not run hwclock (or don't show any errors). Realistically, we could probably get away with not showing errors about syncing the hardware clock in general. (In reply to comment #12) > Realistically, we could probably get away with not showing errors about syncing > the hardware clock in general. Especially as we ignore it if you have ntp enabled already Building with the return ignored for now -- Nils, if you want to take another approach, get it built and send mail to rel-eng so that we can include it. Cut-off of when we're composing is probably morning US time. I'll make this change upstream and will build 1.9.16 with it. NB: I'll leave the dialog in, but make it a warning one. *** Bug 355611 has been marked as a duplicate of this bug. *** I've built system-config-date-1.9.16-1.fc8, mail to rel-eng will follow shortly. Confirmed fixed in today's rawhide - an error message is shown, but firstboot continues after that. system-config-date-1.9.32-1.fc8 has been submitted as an update for Fedora 8 system-config-date-1.9.32-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report. |