Red Hat Bugzilla – Bug 357311
firstboot refuses to go forward under Xen (due to hwclock error)
Last modified: 2008-07-08 22:42:46 EDT
Description of problem:
When in a Xen guest, firstboot doesn't go forward on the "date and time" page,
giving the error "Failed to synchronize hardware clock". hwclock wouldn't work
Version-Release number of selected component (if applicable):
Steps to Reproduce:
- Install Fedora 8 on a Xen paravirt guest
- Go through firstboot screen on the first boot
- See the error when pressing "forward" on the date/time page
"Failed to synchronize hardware clock", and firstboot doesn't go forward.
User should be allowed to go forward. I don't know if it would be preferable
to not allow setting date/time when under Xen, or the hwclock error should be
I haven't installed my Xen guest using the Fedora 8 Test 3 image. I have
installed using a rawhide mirror updated a few days ago.
I am upgrading the mirror and downloading F8-Test3 to confirm if the bug is
present on latest Rawhide and/or F8-Test3. However, as time is short for
Fedora 8, I am reporting the problem before I confirm it on a latest version.
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
> 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 email@example.com 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.