Setting hwclock --localtime fails

I run a dual boot system with Vista and Debian unstable.

The clock in Debian is two hours ahead because it thinks the time is UTC.

I have been adviced that I should use hwclock to set the time to local time,
but I get this error:

kit:~# hwclock --localtime
select() to /dev/rtc to wait for clock tick timed out

Is there a bug? Any hints on what to do?

I have noticed that this error occurs during boot as well.

I think I also need to add that I have ntp installed.

Anders

--

0

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Setting hwclock --localtime fails

Anders Ellenshøj Andersen escreveu:
> I run a dual boot system with Vista and Debian unstable.
>
> The clock in Debian is two hours ahead because it thinks the time is UTC.
>
> I have been adviced that I should use hwclock to set the time to local time,
> but I get this error:
>
> kit:~# hwclock --localtime
> select() to /dev/rtc to wait for clock tick timed out
>
> Is there a bug? Any hints on what to do?
>
> I have noticed that this error occurs during boot as well.
>
> I think I also need to add that I have ntp installed.
>
> Anders
>
>
>
Hi.
When I had this problem, I corrected thus:
# date -s HH:MM
# hwclock -w
Good luck

Sérgio

--
Linux User #426387
Linux: A liberdade da escolha. A escolha da liberdade.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFF9vhuJ+YDTomMwA8RAvSAAJoDwkzHJK3P98vEDx5pJxeyT3xyzgCg22/u
W/MTldaxqdeNLjlWF49wpig=
=MVB7
-----END PGP SIGNATURE-----

--

Setting hwclock --localtime fails

rdate is updating the time from timeserver, but is more lightweight than
ntpdate. I couldn't discover a debian boot script for rdate, but it's a simple
issue, so I added this snippet to a customized /etc/rc.local script:

NTPSERVERS="80.237.234.16 130.133.1.10"
echo "Setting system clock:"
for timeserver in $NTPSERVERS; do
if (ping -q -c 1 -i 0.2 -W 1 $timeserver > /dev/null);
then found=true; echo "`/usr/sbin/rdate $timeserver`"; break
else found=false
fi
done
$found || echo "WARNING: No timeserver was reached!"

--micha

ps. you can direct output to a specific log by using function 'log' instead of echo

log () {
logger -t "xxx_rc.local" -p $loglevel "$1"
[ "$2" = "exit" ] && exit 0
}

--

Setting hwclock --localtime fails

On Do, Apr 12, 2007 at 09:14:49 +0200, Anders Ellenshøj Andersen wrote:
> I run a dual boot system with Vista and Debian unstable.
>
> The clock in Debian is two hours ahead because it thinks the time is UTC.
>
> I have been adviced that I should use hwclock to set the time to local time,
> but I get this error:

I think it is a bad, bad advice. And its wrong :-) You should tell your
system its not running UTC. Set UTC=no in /etc/default/rcS and your
system will run with local time, like Windows does.

You should never use hwclock. Let your system work for you, don't work
against your system :-)

other Problem:

> kit:~# hwclock --localtime
> select() to /dev/rtc to wait for clock tick timed out
>
> Is there a bug? Any hints on what to do?

No, not as far as I know. AFAIK this is the new?? but preferred way to
set the hardware clock. On some systems it isn't working, like yours. So
you should try to insert the option "--directisa" to the HWCLOCKPARS
variable in every /etc/init.d/hwclock*.sh

> I have noticed that this error occurs during boot as well.

This should go away with --directisa

Frank

--

Setting hwclock --localtime fails

On Thu, 12 Apr 2007 19:35:07 +0200
Frank Ursel wrote:

> On Do, Apr 12, 2007 at 09:14:49 +0200, Anders Ellenshøj Andersen wrote:

[snip]

> other Problem:
>
> > kit:~# hwclock --localtime
> > select() to /dev/rtc to wait for clock tick timed out
> >
> > Is there a bug? Any hints on what to do?
>
> No, not as far as I know. AFAIK this is the new?? but preferred way to
> set the hardware clock. On some systems it isn't working, like yours. So
> you should try to insert the option "--directisa" to the HWCLOCKPARS
> variable in every /etc/init.d/hwclock*.sh
>
> > I have noticed that this error occurs during boot as well.
>
> This should go away with --directisa

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=277298

Celejar

Setting hwclock --localtime fails

Torsdag 12 April 2007 17:35 skrev Frank Ursel:
> I think it is a bad, bad advice. And its wrong :-) You should tell your
> system its not running UTC. Set UTC=no in /etc/default/rcS and your
> system will run with local time, like Windows does.

Thanks for your help. The --directisa option works.

I also changed UTC=no in /etc/default/rcS as you suggested, but in KDE the
time is still two hours ahead?

kit:/etc/default# hwclock --directisa --show
tor 12 apr 2007 21:07:31 UTC -0.590975 sekunder

This is the correct local time. The time in KDE is two hours ahead of this.

Anders

--

Setting hwclock --localtime fails

Hi,

On Thu, Apr 12, 2007 at 09:14:49PM +0200, Anders Ellenshøj Andersen wrote:
> I run a dual boot system with Vista and Debian unstable.
>
> The clock in Debian is two hours ahead because it thinks the time is UTC.
>
> I have been adviced that I should use hwclock to set the time to local time,
> but I get this error:
>
> kit:~# hwclock --localtime
> select() to /dev/rtc to wait for clock tick timed out

I had the same problem. For some reason the rtc driver (module rtc.ko)
did not work. using genrtc.ko instead or neither (or "hwclock --directisa"
which ignores /dev/rtc) works for me.

michael

hwclock

Quote:
select() to /dev/rtc to wait for clock tick timed out

Had the same problem.

Try using "hwclock --localtime --directisa"

If no error returns, the "--directisa" switch was what was needed.

To carry this through reboots, edit the file /etc/init.d/hwclock.sh

and change the line (about line #23):

HWCLOCKPARS=""

to read:

HWCLOCKPARS="--directisa"

this will allow the system time to be saved to the hwclock on shutdown.

Make sure you have

UTC=no

in the file /etc/default/rcS

This will make sure the system properly reads and translates the hardware clock on startup.
--
Jai yen

hwclock

On Apr 13, 12:04 am, Seaslug wrote:
>

Quote:
select() to /dev/rtc to wait for clock tick timed out

>
> Had the same problem.
>
> Try using "hwclock --localtime --directisa"
>
> If no error returns, the "--directisa" switch was what was needed.
>
> To carry this through reboots, edit the file /etc/init.d/hwclock.sh
>
> and change the line (about line #23):
>
> HWCLOCKPARS=""
>
> to read:
>
> HWCLOCKPARS="--directisa"
>
> this will allow the system time to be saved to the hwclock on shutdown.
>
> Make sure you have
>
> UTC=no
>
> in the file /etc/default/rcS
>
> This will make sure the system properly reads and translates the hardware clock on startup.
> --
> Jai yen
>
> --

hwclock

carex@skynet.be wrote:

> HWCLOCKPARS="--directisa"  as you specified above and the problem
> vanished !

BTW, this issue came up sometime back (I guess with 2.6.18).

Will the fix be to include the "--directisa" option with hwclock ?
If yes, any ideas if this is going to be committed into the package ?

Thanks,
Ritesh
--
If possible, Please CC me when replying. I'm not subscribed to the list.

--

hwclock

On Tue, 24 Apr 2007 01:29:57 +0530
Ritesh Raj Sarraf wrote:

> wrote:
>
> > HWCLOCKPARS="--directisa"  as you specified above and the problem
> > vanished !
>
> BTW, this issue came up sometime back (I guess with 2.6.18).
>
> Will the fix be to include the "--directisa" option with hwclock ?
> If yes, any ideas if this is going to be committed into the package ?
>
> Thanks,
> Ritesh

See debian bug #410328.

Celejar
--
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator

hwclock

On Thu, 2007-04-12 at 21:03 +0200, Seaslug wrote:
>
> Make sure you have
>
> UTC=no
>
> in the file /etc/default/rcS

Hmmmm...

Won't that mean that my hardware clock will have to be adjusted whenever
there is a daylight savings transition?

I have always set UTC=yes there, and it works just fine. It is a matter
of being consistent though. If it is possible for you to be consistent
then UTC=yes is probably better.

Of course if you are unlucky enough to have to reboot into some
operating system which doesn't support the idea of the hardware clock
being set to a standard time then no UTC for you! :-)

Regards,
Andrew McMillan.

-------------------------------------------------------------------------
Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267
Flexibility is overrated. Constraints are liberating.
-------------------------------------------------------------------------

hwclock

On Sun, Apr 22, 2007 at 10:09:05PM +1200, Andrew McMillan wrote:
> On Thu, 2007-04-12 at 21:03 +0200, Seaslug wrote:
> >
> > Make sure you have
> >
> > UTC=no
> >
> > in the file /etc/default/rcS
>
> Hmmmm...
>
> Won't that mean that my hardware clock will have to be adjusted whenever
> there is a daylight savings transition?
>
> I have always set UTC=yes there, and it works just fine. It is a matter
> of being consistent though. If it is possible for you to be consistent
> then UTC=yes is probably better.
>
> Of course if you are unlucky enough to have to reboot into some
> operating system which doesn't support the idea of the hardware clock
> being set to a standard time then no UTC for you! :-)

Configure Windows not to adjust the clock for daylight savings, and live
with UTC. That’s what I do anyway.

Simon
--
Email: | Jabber ID:
A complex system that works is invariably found to have evolved
from a simple system that works. -- John Gaule

hwclock

* Andrew McMillan [2007-04-22 22:09:05 +1200]:

> Won't that mean that my hardware clock will have to be adjusted whenever
> there is a daylight savings transition?

No. Running localtime will automatically correct for DST. The new US DST
was compensated for quite some time before the change was in effect. I only
had problems on some clients' unpatched winslop boxes. The Debian package
that keeps track of this is tzdata - if it's kept updated, political changes
of timezones will be compensated for.

>
> I have always set UTC=yes there, and it works just fine. It is a matter
> of being consistent though. If it is possible for you to be consistent
> then UTC=yes is probably better.

Yep. I do this on all my straight *nix boxes - easier that way, and IMHO
much more sane.

> Of course if you are unlucky enough to have to reboot into some
> operating system which doesn't support the idea of the hardware clock
> being set to a standard time then no UTC for you! :-)

I believe the OP was doing a dual boot with winslop, hence the extra
gyration.

Cheers,

Dave.

--

Syndicate content