Bug#346342: libc6: REALLY annoying: destroys workaround all the time
On Mon, Apr 10, 2006 at 07:42:41AM +0200, Aurelien Jarno wrote:
> Hi!
>
> First of all, please don't be so agressive. If you look at the bug log,
> we never say we won't fix the bug because of ideologicial concerns.
> Actually nobody from the glibc team answered to the bug report, so I
> don't know how you know our opinion.
I am sorry that I was so aggressive. I was just upset at comments such
as "(...) people who use UTC=no tend to be naive Linux users" and "(...) this
issue could be regarded as a wishlist item." I had followed this thread
(and the one over at util-linux) and was frustrated with the lack of
progress and repeated overwriting of the /etc/localtime symlink. I am
sorry for my overreaction.
>
> Then I think it's just that nobody found the time to work on this bug,
> and also the first mails sent to the bug log shows that the situation is
> unclear if it is a bug in the glibc or util-linux. After all nothing has
> changed on the glibc side, and the bug was not present before.
>
> If you need to be more helpful, please send a patch instead of shouting.
>
> Then on the bug itself, I will try to investigate that. The solution is
> not trivial, if you look at the tzconfig script, you may notice that the
> script use a readlink on /etc/localtime. Replacing it by a plain file
> may have consequences that have to be investigated. It seems that it is
> broken for some people (I fail to understand how it happens), and we
> don't want to break it for everyone.
I think the "fsck is messed up" is a util-linux bug, while the "system
clock is wrong because there's no timezone data in the root filesystem"
is a bug in libc6 (this package).
The way the breakage happens, is that the hwclock is set to local time
(due to Windows being stubborn). On bootup, linux sets the system clock
based on the hardware clock early on in the boot sequence before /usr is
mounted (this is necessary for fsck to work). Since /etc/localtime is
missing, hwclock doesn't know what local time the hwclock is in and
silently assumes UTC. So now, the system clock has the same time as the
hardware clock, but thinks it is UTC.
I would like to look into patching this problem. What file is
responsible for setting up the /etc/localtime ? tzconfig? Is that what
gets run on every package update? It seems like it is an interactive
program, so it is unlikely the source of the repeated /etc/localtime
breakage, unless some piping is happening.
Martin
Reply to: