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
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
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 assistance
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
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 set
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
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
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
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
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
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
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
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 to /bin/bash
Kernel
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.6.12-1-k7
14 matches
Mail list logo
