From: Joey Hess <[EMAIL PROTECTED]>
| Perhaps hwclock should stash a copy of /etc/localtime at shutdown and
| run using that version in early boot if /usr is not mounted?
/ is potentialy read-only so this doesn't work out.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Processing commands for [EMAIL PROTECTED]:
> retitle 342887 util-linux: hwclock runs at the wrong point in the rcS.d
> sequence
Bug#342887: util-linux: hwclock runs too early, breaking the system time
Changed Bug title.
> stop
Stopping processing here.
Please contact me if you need a
retitle 342887 util-linux: hwclock runs at the wrong point in the rcS.d sequence
stop
> I have two newly installed (this week) Sarge systems that exhibit this
> problem. I used the debian-31ra1a-i386-netinst image and /usr is in the
> root filesystem. I told the diaglog that the hardware was loc
I have two newly installed (this week) Sarge systems that exhibit this
problem. I used the debian-31ra1a-i386-netinst image and /usr is in the
root filesystem. I told the diaglog that the hardware was localtime, my
timezone is EST, and to observe daylight savings. I do not understand
why I am ha
On Thu, 12 Jan 2006, Martin Stolle wrote:
> The only valid solution is to copy the appropriate timezone info to
> /etc/localtime. Rerunning tzconfig or recopying this file when
That's what will be done, when we prove it to the glibc people that it is
save (i.e. please do so on your system, and re
Package: util-linux
Version: 2.12r-2
Followup-For: Bug #342887
I would like to reinforce that using TZ is NOT a valid answer... Either
TZ has to encode all the informatino from /usr/share/zoneinfo for the
appropriate timezone somehow (which I don't think would even be
possible!) OR it is s
tag 342887 + patch
thanks
See attached patch. It was not completely tested yet, but it seems sane,
and it survived some light testing.
Note that hwclock.sh runs much later than I'd like it to, but we need to
make sure /usr is mounted, and that means it must run after NFS has had its
change of mo
Please remember this is bug is being dealt with with util-linux perspective
when reading my answers...
On Sun, 01 Jan 2006, Nate Eldredge wrote:
> Right. Which is kind of painful in the daylight savings case. I can't
Correct. It is *flat out impossible* to fix this issue completely (as in do
e
On Sat, 31 Dec 2005, Henrique de Moraes Holschuh wrote:
Let's go over the way things work, and see how we can fix them back so that
they work correctly. Please bear with me while I go over the entire
problem, and feel free to correct any mistakes I make.
Reading manpage tzset(3) before you rea
Let's go over the way things work, and see how we can fix them back so that
they work correctly. Please bear with me while I go over the entire
problem, and feel free to correct any mistakes I make.
Reading manpage tzset(3) before you read any further is advised.
AFAIK There are ONLY TWO valid m
If you decide that /etc/localtime should be a copy and not a symlink,
let me know; there is code in d-i that sets up the symlink.
Using a copy seems problimatic, since the zoneinfo files can be updated
from time to time.
Perhaps hwclock should stash a copy of /etc/localtime at shutdown and
run us
Package: util-linux
Version: 2.12r-2
Followup-For: Bug #34288
You could also make the argument that it runs too late--since it runs after
checkroot, even after copying the symlinked localtime into /etc/, the root
filesystem will still be checked every other boot. I'm not sure what exactly
changed.
I see this behavior as well. Unfortunately there is a catch-22 in fixing
it. e2fsck as of e2fsprogs-1.38+1.39-WIP-2005.12.10-1 now checks if the
last mount date on a filesystem is "in the future". So if hwclock does
not run before fsck, and your timezone is west of GMT, this check is
trigger
Package: util-linux
Version: 2.12r-2
Followup-For: Bug #342887
I am seeing the same behavior.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2
Package: util-linux
Version: 2.12r-2
Followup-For: Bug #342887
I can confirm this behaviour.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked
Package: util-linux
Version: 2.12r-1
Severity: serious
Hi,
My hardware clock is set to localtime, not to GMT. And everything worked OK
until a few days ago.
Yesterday I noted that my system clock was an hour fast. I set it to a
valid value, rebooted the system, and (surprise!) the problem renewe
16 matches
Mail list logo
