Bug 409551

Created attachment 276301 [details]
patch

David, I'm going to commit your patch upstream too. I assume you agree with
"Signed-off-by". Thanks for your patch.

util-linux-ng-2.13-3.1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update util-linux-ng'

At least with util-linux-ng-2.13-4.fc9 and kernel-2.6.24-0.73.rc4.git1.fc9
this is broken.  hwclock tries to access /dev/rtc, which exists,
gets ENODEV and does not fall back to /dev/rtc0.

After replacing /dev/rtc (c 10 135) with a link to /dev/rtc0 (c 254 0)
hwclock works again.  'udev' attemps such replacement operation but gives
up as "device node '/dev/rtc' already exists".

I suppose this is the same issue which leads to the following complaint
during the boot procedure for kernel 2.6.24-0.79.rc4.git5.fc9:

  "Cannot access the Hardware Clock via any known method. .."

This leads to a one hour -offset- of the system time which disappears
by forcing synchronization with an NTP server via ntpdate.
Fedora 8 update kernels for which there is -no- module directory
/lib/modules/`uname -r`/kernel/drivers/rtc/ behave correctly.
For the latter, according to the boot log - built-in (?) - "Real Time
Clock Driver v1.12ac" is used whereas for the "rawhide" kernel,
module 'rtc_cmos' is loaded.

Should be fixed now. Please, update to util-linux-ng >= 2.13.1-0.2.fc9.

No improvement for util-linux-ng-2.13.1-1.fc9.

util-linux-ng-2.13-3.1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

No progress for util-linux-ng-2.13-3.1.fc8:
...
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock  (localtime): Thu Dec 20 22:43:53 CET 2007   [  OK  ]
Starting udev: udevd-event[1161]: node_symlink: device node '/dev/rtc' already
exists, link to '/dev/rtc0' will not overwrite it
...

sh-3.2# rpm -q util-linux-ng
util-linux-ng-2.13-3.1.fc8
sh-3.2# rpm -q kernel
kernel-2.6.24-0.118.rc5.git6.fc9

For reasons not entirely clear to me (likely specifics of hardware) 
on a machine with F8 installation I have here udev does not create
/dev/rtc0 at all and only a _working_ /dev/rtc.  So the bug is masked.
Moreover after renaming /dev/rtc to /dev/rtc0 hwclock still works,
so it looks like indeed it tries to fall back to /dev/rtc0.

OTOH on my rawhide test machine udev comes with both /dev/rtc and
/dev/rtc0 but attempts to use /dev/rtc fail and this is what trips
hwclock from util-linux-ng-2.13-3.1.fc9.  A "hack-around" then is
to either remove /dev/rtc or force it to be a link to /dev/rtc0.
Then, and only then, hwclock starts to work.  This looks to me
like an excellent reason to reopen.

I believe this bug is already fixed and can be closed, see my comment in bug
290731 for the real reasons that people are still seeing problems.

> I believe this bug is already fixed ...

The original report said "/sbin/hwclock is supposed to fall back
to using /dev/rtc0 if /dev/rtc isn't working...".  If this is really
the case then I fail to see this happening.  It will fall back if
/dev/rtc does not exist - but this is not the same thing.

Yes, I agree that the resulting mess could be fixed in various ways
but it should be.  It appears that the quickest would be to make
in /etc/rc.d/rc.syslinux the first try with hwclock silent and check
results.  If this failed then remove /dev/rtc, if /dev/rtc0 exists,
and try again.  That is clearly a workaround instead of a fix but
it would help for now.

(In reply to comment #12)
> > I believe this bug is already fixed ...
> 
> The original report said "/sbin/hwclock is supposed to fall back
> to using /dev/rtc0 if /dev/rtc isn't working...".  If this is really
> the case then I fail to see this happening.  It will fall back if
> /dev/rtc does not exist - but this is not the same thing.
> 

The version currently in rawhide (and the version for this bug is set to rawhide
does fall back if /dev/rtc is present but not working, I've verified that yesterday.

Observations reported in comment #5 and comment #9 still apply entirely
to current "rawhide" with the following components:
- kernel-2.6.24-0.167.rc8.git4.fc9
- util-linux-ng-2.13.1-2.fc9
Does this mean I should file a separate bug report?

(In reply to comment #14)
> Observations reported in comment #5 and comment #9 still apply entirely
> to current "rawhide" with the following components:
> - kernel-2.6.24-0.167.rc8.git4.fc9
> - util-linux-ng-2.13.1-2.fc9
> Does this mean I should file a separate bug report?

No this is bug 290731, as I already said in my initial comment to this bug:
comment #11. These symptoms are not caused by any defect of hwclock, please read
me comment to bug 290731 for the real cause of this.

In the mean time, this bug can still be closed.

> The version currently in rawhide (and the version for this bug is
> set to rawhide does fall back if /dev/rtc is present but not working ...

In such case I would not expect to see the first two lines
in startup messages quoted below.  "Setting clock" comes from
a run of 'date' and not of 'hwclock'.

Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock  (utc): Fri Jan 25 09:28:17 MST 2008         [  OK  ]
Starting udev: udevd-event[1188]: node_symlink: device node '/dev/rtc' already
exists, link to '/dev/rtc0' will not overwrite it


I have a hack which later removes '/dev/rtc' in order to make
hwclock functional.  If I see "... via any known method" then
apparently we have different understanding what it means to 
"work". 'udev' messages are indeed from another story.

util-linux-ng-2.13.1-2.fc9
kernel-2.6.24-0.167.rc8.git4.fc9
udev-118-1.fc9

(In reply to comment #16)
> > The version currently in rawhide (and the version for this bug is
> > set to rawhide does fall back if /dev/rtc is present but not working ...
> 
> In such case I would not expect to see the first two lines
> in startup messages quoted below.  "Setting clock" comes from
> a run of 'date' and not of 'hwclock'.
> 

2 lines for which there is a perfect explanation, which is not hwclock's fault!
I'm not saying there is no bug, I'm just saying the bug is not in hwclock
(atleast not anymore). As already asked 3 times please read my (very long)
comment to bug 290731, where I explain why you are still seeing these messages
and why these messages are not hwclock's fault.

I'm closing this now, don't anyone dare to reopen it without reading my comment
to bug 290731, and giving thorough reasoning why they believe my reasoning is
wrong and this is still the fault of hwclock.

<cheesh people how hard is it to read a single comment if asked to do so a 
 gazillion times?>

So on bug 290731 we got, clearly incorrect, now:
"Bug 290731 depends on bug 409551, which changed state" so it got closed.
In other words - everything is now fixed just fine only, AFAICS, it
remains plain broken.  Count me terminally confused.

> giving thorough reasoning why they believe my reasoning is wrong

Again - according to the original report this is expected to happen:
"/sbin/hwclock is supposed to fall back to using /dev/rtc0 if /dev/rtc
isn't working".  Is it doing that?  Clearly it does not, at least on
my hardware, and no amount of "sofware lawyering" can change that.
What other kind of "thorough reasoning" is needed above that?
Does anybody else subscribe to Hans's opinion that this is working?

If bug 290731 would be fixed, instead of beeing closed, then it
would at least _hide_ the problem in hwclock.  Right now we are back
to square one.

Apparently bug 290731 is opened again.  I have in my mailbox
a message "CLOSED RAWHIDE" while bugzilla says something else.

Once more - fixing bug 290731 will make hwclock to work again
but it will do _nothing_ for the issue in the original report.

(In reply to comment #18)
> So on bug 290731 we got, clearly incorrect, now:
> "Bug 290731 depends on bug 409551, which changed state" so it got closed.
> In other words - everything is now fixed just fine only, AFAICS, it
> remains plain broken.  Count me terminally confused.
> 

We (Fedora) value user input very much, but can you _please_ learn to read /
check your facts before yelling fire. As said before and I'll say it again I'm
not denying there is a bug, on the contrary I'm working on creating a fix for
this bug!

Also if you point your browser at bug 290731, then you will see that that bug
Status field is set to assigned, not closed or resolved in anyway, iow it is
being worked on. Depending on means that someone has told bugzilla (in
retrospect wrongly) that bug 290731 could not be fixed before this bug (bug
409551) was fixed.

> > giving thorough reasoning why they believe my reasoning is wrong
> 
> Again - according to the original report this is expected to happen:
> "/sbin/hwclock is supposed to fall back to using /dev/rtc0 if /dev/rtc
> isn't working".  Is it doing that?  Clearly it does not, at least on
> my hardware, and no amount of "sofware lawyering" can change that.

Actually yes, it is doing that, it is falling back to /dev/rtc0, but it fails
for 2 reasons:
1) At this time in the bootup process /dev/rtc0 (the file) doesn't exist as it 
   gets created by udev, which hasn't run yet (proof: the udev errors are
   after the hwclock error)
2) Even if /dev/rtc0 (the file) would exist, things still wouldn't work as the
   rtc kernel driver is build as a loadable module (proof, do:
   "lsmod | grep rtc", and this driver gets loaded by udev, which runs after
   the hwclock command

And you could have known these 2 reasons if you would have read my comment to
bug 290731, how many times have I asked to that now? Imagine how much closer I
could be to actually fixing this if all the time I spend explaining myself,
because people refuse to thoroughly read and understand my comment in bug
290731, would actually have been spend working on a fix?


> What other kind of "thorough reasoning" is needed above that?

The kind where you actually take the time to read and understand the comment I
wrote in bug 290731, the one I went true when I spend several hours analysing
the situation before writing said comment. The kind were one shows understanding
that although component X (hwclock) gives an error it may very well not be
component X's fault.

> Does anybody else subscribe to Hans's opinion that this is working?
> 

I'm not saying that "this" is working I'm saying that the fall back is working
and that the other problems are not hwclock's fault, they are definitely a bug,
but not the bug described in this bug report.

Since a lot of people seem interested in this, just a quick note that I've added
a fix + instructions howto use / test that fix to bug 290731.