NavigationUser loginSpam?See spam posts on this site? If so, please don't reply to the spam! Instead, just report the URL to the webmaster. Cost of War |
Setting hwclock --localtime failsI 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, kit:~# hwclock --localtime 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 -- |
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
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:
>
>
> 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.
--