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 under Xen. Version-Release number of selected component (if applicable): firstboot-1.4.39-1.fc8 system-config-date-1.9.15-1.fc8 How reproducible: Always. 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 Actual results: "Failed to synchronize hardware clock", and firstboot doesn't go forward. Expected results: 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 just ignored. Additional info: 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 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.