Bug 357311

Summary: firstboot refuses to go forward under Xen (due to hwclock error)
Product: [Fedora] Fedora Reporter: Eduardo Habkost <ehabkost>
Component: system-config-dateAssignee: Nils Philippsen <nphilipp>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: 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-08 22:42:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 235703    

Description Eduardo Habkost 2007-10-29 16:46:20 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 
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.
Comment 1 Jeremy Katz 2007-10-29 17:04:08 EDT
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 
Comment 2 Eduardo Habkost 2007-10-29 17:24:02 EDT
(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.
Comment 3 Nils Philippsen 2007-10-30 12:06:45 EDT
NB: Fixing this would cause translations to break, so I'll defer this until
after F8 is out.
Comment 4 Nils Philippsen 2007-10-30 12:21:38 EDT
NB2: Is there already a bug for the hwclock on Xen issue?
Comment 5 Eduardo Habkost 2007-10-30 12:30:24 EDT
(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.
Comment 6 Eduardo Habkost 2007-10-30 12:55:11 EDT
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.
Comment 7 Daniel Berrange 2007-10-30 13:02:21 EDT
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.
Comment 8 Jeremy Katz 2007-10-30 14:17:37 EDT
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.
Comment 9 Will Woods 2007-10-30 14:20:49 EDT
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.
Comment 10 Eduardo Habkost 2007-10-30 14:25:35 EDT
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.
Comment 11 Nils Philippsen 2007-10-30 16:08:27 EDT
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.
Comment 12 Jeremy Katz 2007-10-30 16:15:37 EDT
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.  
Comment 13 Jeremy Katz 2007-10-30 16:17:06 EDT
(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
Comment 14 Jeremy Katz 2007-10-30 17:31:22 EDT
Building with the return ignored for now -- Nils, if you want to take another
approach, get it built and send mail to rel-eng@fedoraproject.org so that we can
include it.  Cut-off of when we're composing is probably morning US time.
Comment 15 Nils Philippsen 2007-10-30 17:46:19 EDT
I'll make this change upstream and will build 1.9.16 with it.
Comment 16 Nils Philippsen 2007-10-30 17:58:02 EDT
NB: I'll leave the dialog in, but make it a warning one.
Comment 17 Nils Philippsen 2007-10-30 17:59:03 EDT
*** Bug 355611 has been marked as a duplicate of this bug. ***
Comment 18 Nils Philippsen 2007-10-30 18:18:23 EDT
I've built system-config-date-1.9.16-1.fc8, mail to rel-eng will follow shortly.
Comment 19 Will Woods 2007-10-31 13:17:07 EDT
Confirmed fixed in today's rawhide - an error message is shown, but firstboot
continues after that.
Comment 20 Fedora Update System 2008-07-01 05:53:30 EDT
system-config-date-1.9.32-1.fc8 has been submitted as an update for Fedora 8
Comment 21 Fedora Update System 2008-07-08 22:42:23 EDT
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.