Debian Bug report logs - #342887
util-linux: hwclock runs at the wrong point in the rcS.d sequence

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Robert Luberda <robert@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: util-linux: hwclock runs too early, breaking the system time

Date: Sun, 11 Dec 2005 15:30:47 +0100

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 renewed.

After some investigation I found that hwclock is now run before /usr 
is mounted, so it assumes that the local time zone is UTC (because
/etc/localtime was a dangling symlink on that time).

To make it more clear, here's an example from my system.
The S22hwclock.sh script sets the date to:
	Sun Dec 11 14:48:47 UTC 2005

But when the S35mountall.sh is run, the date is:
	Sun Dec 11 15:48:48 CET 2005


Best Regards,
robert




-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (100, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/pdksh
Kernel: Linux 2.6.14
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)

Versions of packages util-linux depends on:
ii  libc6                         2.3.5-8.1  GNU C Library: Shared libraries an
ii  libncurses5                   5.5-1      Shared libraries for terminal hand
ii  libslang2                     2.0.5-1    The S-Lang programming library - r
ii  libuuid1                      1.38-2     universally unique id library
ii  zlib1g                        1:1.2.3-8  compression library - runtime

util-linux recommends no packages.

-- no debconf information

Message #10 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Jan De Luyck <jan-bugs@kcore.org>

To: Debian Bug Tracking System <342887@bugs.debian.org>

Subject: util-linux: hwclock runs too early, breaking the system time

Date: Mon, 12 Dec 2005 17:54:52 +0100

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: Linux 2.6.14.3
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages util-linux depends on:
ii  libc6         2.3.5-8.1                  GNU C Library: Shared libraries an
ii  libncurses5   5.5-1                      Shared libraries for terminal hand
ii  libslang2     2.0.5-1                    The S-Lang programming library - r
ii  libuuid1      1.38+1.39-WIP-2005.12.10-1 universally unique id library
ii  zlib1g        1:1.2.3-8                  compression library - runtime

util-linux recommends no packages.

-- no debconf information

Message #15 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Ken Kennedy <kkennedy@kenzoid.com>

To: Debian Bug Tracking System <342887@bugs.debian.org>

Subject: util-linux: Seeing same issue...

Date: Mon, 12 Dec 2005 20:44:28 -0500

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
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages util-linux depends on:
ii  libc6         2.3.5-8.1                  GNU C Library: Shared libraries an
ii  libncurses5   5.5-1                      Shared libraries for terminal hand
ii  libslang2     2.0.5-1                    The S-Lang programming library - r
ii  libuuid1      1.38+1.39-WIP-2005.12.10-1 universally unique id library
ii  zlib1g        1:1.2.3-8                  compression library - runtime

util-linux recommends no packages.

-- no debconf information

Message #20 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Nate Eldredge <nge@cs.hmc.edu>

To: 342887@bugs.debian.org

Subject: Re: util-linux: hwclock runs too early, breaking the system time

Date: Thu, 15 Dec 2005 14:35:07 -0800 (PST)

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 
triggered and the resulting error stops you from booting. But fsck must 
happen before /usr can be mounted. :(

I don't know what to do about this.  You could set TZ in /etc/default/rcS 
but then you have to change both that and /etc/localtime if you want to 
switch time zones.  You could make /etc/localtime a copy instead of a 
symlink but that's not very nice.  Or you could suppress that behavior of 
e2fsck somehow and move hwclock back after fsck.

Personally, I gave up and just set my hw clock to GMT.

-- 
Nate Eldredge
nge@cs.hmc.edu

Message #25 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Michael Spang <mspang@twcny.rr.com>

To: Debian Bug Tracking System <342887@bugs.debian.org>

Subject: util-linux: too early yet too late

Date: Sat, 17 Dec 2005 00:12:13 -0500

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. Regardless, fscking all of my drives is quite time-consuming. In the
meantime I have replaced the symlink in /etc/ and bumped hwclock's priority
to 09.


-- 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: Linux 2.6.15-rc5
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages util-linux depends on:
ii  libc6         2.3.5-8.1                  GNU C Library: Shared libraries an
ii  libncurses5   5.5-1                      Shared libraries for terminal hand
ii  libslang2     2.0.5-1                    The S-Lang programming library - r
ii  libuuid1      1.38+1.39-WIP-2005.12.10-1 universally unique id library
ii  zlib1g        1:1.2.3-8                  compression library - runtime

util-linux recommends no packages.

-- no debconf information

Message #30 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Joey Hess <joeyh@debian.org>

To: 342887@bugs.debian.org

Subject: /etc/localtime

Date: Tue, 27 Dec 2005 13:14:11 -0500

[Message part 1 (text/plain, inline)]

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 using that version in early boot if /usr is not mounted?

-- 
see shy jo

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: 342887@bugs.debian.org, 342887-submitter@bugs.debian.org

Cc: Nate Eldredge <nge@cs.hmc.edu>, Ken Kennedy <kkennedy@kenzoid.com>, Jan De Luyck <jan-bugs@kcore.org>

Subject: hwclock must run after /usr

Date: Sat, 31 Dec 2005 15:58:44 -0200

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 modes of early boot operation:

  1. UTC (hardware clock in UTC, UTC=yes)
  
  2. Non-UTC with TZ set or /etc/localtime in the root filesystem
     (hardware clock in local time, UTC=no, system knows timezone)

Anything else is an invalid system configuration, and must be fixed.  By
invalid configuration, I mean one where the system UTC clock (which has
nothing to do with the hardware clock) is NOT set to the correct UTC time.

I would bet it is common to find people with invalid configurations, since a
separate /usr is common, TZ is not mentioned at the top of
/etc/init.d/hwclockfirst.sh, and there isn't a way for d-i to set that up
either.

Also, do refer to tzset(3), we would need to use the simplest TZ form, since
it must work without data that is in /usr/share.

It is good to remember that timezones can be changed at will, by any user
(just set TZ) at any time, and also that TZ overrides /etc/localtime so we
don't want to define it system-wide.

What that means?  Below are the two valid configurations and what actions
hwclock initscripts should do (doing anything else is probably a big bad
bug ;-) ), and the most common invalid configuration.

(*) are the points where hwclock scripts must take some action.

UTC mode:
  0. Kernel might boot with correct time (if it reads the RTC by itself)
* 1. hwclockfirst sets kernel time to the correct UTC time
  2. system runs with a local timezone (if /etc/localtime is readable)
     or with UTC as a timezone
  3. something mounts /usr
  4. System runs with the proper timezone
  
  Early boot runs fine, system thinks timezone is UTC if /usr is not
  mounted, or reads timezone from /etc/localtime if it is mounted.
  No big deal, as apps use UTC for persitent timekeeping.  e2fsck
  should not be going bonkers in this case.

  hwclock should try to set the system clock only on early boot.

Non-UTC valid config mode, with /usr as a separate partition
  0. kernel boots with wrong time (even if it reads the RTC by itself)
* 1. TZ is set so hwclockfirst sets the kernel time to the correct UTC time
  2. system runs with a local timezone (if /etc/localtime is readable)
     or with UTC as a timezone
  3. Something mounts /usr
  4. System runs with the proper timezone

  Again, hwclock should try to set the system clock only on early boot.
  Notice that TZ must be set only for the hwclockfirst initscript, we don't
  want it in the global environment.  I'd suggest removing UTC from
  /etc/default/rcS, and adding TZ and UCT to a new file,
  /etc/default/timezone.
  
Non-UTC *valid config* mode, /usr inside the root partition
  0. kernel boots with wrong time (even if it reads the RTC by itself)
  1. /etc/localtime is readable, so everything else runs just like it
     does in UTC mode.

With a valid configuration, hwclockfirst does all the job that doesn't need
a timezone and must run VERY early.  hwclock does the jobs that require a
timezone (which is actually just displaying the time in the local timezone
so that the users have a better clue of what's happening, and we don't
increase d-user traffic with RTC problems again).

This means hwclock.sh *must* run after /usr is mounted.  That's the only
time we *know* the timezone will be correct, no matter which configuration
is used (including invalid ones -- hwclock after /usr is a *debugging aid*).


What would happen in the typical broken configuration?

Non-UTC, /usr separate, no TZ defined anywhere:
  0. kernel boots with wrong time (even if it reads the RTC by itself)
* 1. hwclock sets the kernel UTC time to the local time in the RTC,
     and thus the system clock could be wrong by several hours in either
     direction.
  2. System runs with wrong time. e2fsck can croak, etc.
  3. something mounts /usr
* 4. hwclock runs, and tells the user a completely ludricous time
     (timezone applied twice :P) <=== We could fix the mess here, so
     if the user doesn't hit a bug (e.g. e2fsck) before, he would not
     suffer much from his broken config.

     hwclock MUST be run after /usr is mounted to be able to help fix
     the mess (well work around it, realy).

Now, there's a bug in that hwclockfirst should bitch to all winds if it
detects an invalid config, currently it just outputs a meek "System clock
was not updated at this time" and bangs out with exit status 1.

There is also a bug in that hwclockfirst must be one of the VERY first
things to be run, AND that hwclock must be run AFTER /etc/localtime is
working well in a typical Debian system.  I.e. *after* /usr is mounted.

And there is a third bug which is the lack of easy TZ handling and lack of
documentation.  The funny thing is that I could swear I added TZ and some
documentation to hwclockfirst, but that script has been extensively
modified since then.

After hwclock has enough infrastructure for it (i.e. /etc/default/timezone
or somesuch), d-i should be enhanced to set THAT if it is going to set
UTC=no.

I might submit a patch soon, it would have been faster than documenting all
of the above...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #43 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Nate Eldredge <nge@cs.hmc.edu>

To: Henrique de Moraes Holschuh <hmh@debian.org>

Cc: 342887@bugs.debian.org, 342887-submitter@bugs.debian.org, Nate Eldredge <nge@cs.hmc.edu>, Ken Kennedy <kkennedy@kenzoid.com>, Jan De Luyck <jan-bugs@kcore.org>

Subject: Re: hwclock must run after /usr

Date: Sun, 1 Jan 2006 14:22:25 -0800 (PST)

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 read any further is advised.
>
> AFAIK There are ONLY TWO valid modes of early boot operation:
>
>  1. UTC (hardware clock in UTC, UTC=yes)
>
>  2. Non-UTC with TZ set or /etc/localtime in the root filesystem
>     (hardware clock in local time, UTC=no, system knows timezone)
>
> Anything else is an invalid system configuration, and must be fixed.  By
> invalid configuration, I mean one where the system UTC clock (which has
> nothing to do with the hardware clock) is NOT set to the correct UTC time.

I think this is right.

> I would bet it is common to find people with invalid configurations, since a
> separate /usr is common, TZ is not mentioned at the top of
> /etc/init.d/hwclockfirst.sh, and there isn't a way for d-i to set that up
> either.
>
> Also, do refer to tzset(3), we would need to use the simplest TZ form, since
> it must work without data that is in /usr/share.

Right.  Which is kind of painful in the daylight savings case.  I can't 
just say US/Pacific, or even PST -0800, I have to look up the exact 
definition of when daylight savings changes and figure out the TZ syntax 
to specify that.  I don't know, but there might be places where the time 
zone is even more complicated and can't be fully described in the TZ 
variable.  In which you can't use this approach and be correct always.

> It is good to remember that timezones can be changed at will, by any user
> (just set TZ) at any time, and also that TZ overrides /etc/localtime so we
> don't want to define it system-wide.
>
> What that means?  Below are the two valid configurations and what actions
> hwclock initscripts should do (doing anything else is probably a big bad
> bug ;-) ), and the most common invalid configuration.
>
> (*) are the points where hwclock scripts must take some action.
>
> UTC mode:
>  0. Kernel might boot with correct time (if it reads the RTC by itself)
> * 1. hwclockfirst sets kernel time to the correct UTC time
>  2. system runs with a local timezone (if /etc/localtime is readable)
>     or with UTC as a timezone
>  3. something mounts /usr
>  4. System runs with the proper timezone
>
>  Early boot runs fine, system thinks timezone is UTC if /usr is not
>  mounted, or reads timezone from /etc/localtime if it is mounted.
>  No big deal, as apps use UTC for persitent timekeeping.  e2fsck
>  should not be going bonkers in this case.
>
>  hwclock should try to set the system clock only on early boot.

Yes.

> Non-UTC valid config mode, with /usr as a separate partition
>  0. kernel boots with wrong time (even if it reads the RTC by itself)
> * 1. TZ is set so hwclockfirst sets the kernel time to the correct UTC time
>  2. system runs with a local timezone (if /etc/localtime is readable)
>     or with UTC as a timezone
>  3. Something mounts /usr
>  4. System runs with the proper timezone
>
>  Again, hwclock should try to set the system clock only on early boot.
>  Notice that TZ must be set only for the hwclockfirst initscript, we don't
>  want it in the global environment.  I'd suggest removing UTC from
>  /etc/default/rcS, and adding TZ and UCT to a new file,
>  /etc/default/timezone.

Yes.  Note that setting TZ is rather inconvenient.  First because you have 
to figure out the format, as I mentioned above, and also now if you ever 
want to change your timezone you have to change it in two places 
(/etc/default and the /etc/localtime symlink) which are hard to find.  I 
forget which package has the config script where you select your timezone, 
but I guess it could in principle apply it in both places.  But that's 
kind of ugly, and anyway the Debian philospohy is not to force people into 
using config scripts.

> Non-UTC *valid config* mode, /usr inside the root partition
>  0. kernel boots with wrong time (even if it reads the RTC by itself)
>  1. /etc/localtime is readable, so everything else runs just like it
>     does in UTC mode.

i.e. hwclockfirst sets the time to correct UTC.  Provided UTC=NO.

> With a valid configuration, hwclockfirst does all the job that doesn't need
> a timezone and must run VERY early.  hwclock does the jobs that require a
> timezone (which is actually just displaying the time in the local timezone
> so that the users have a better clue of what's happening, and we don't
> increase d-user traffic with RTC problems again).
>
> This means hwclock.sh *must* run after /usr is mounted.  That's the only
> time we *know* the timezone will be correct, no matter which configuration
> is used (including invalid ones -- hwclock after /usr is a *debugging aid*).
>
>
> What would happen in the typical broken configuration?
>
> Non-UTC, /usr separate, no TZ defined anywhere:
>  0. kernel boots with wrong time (even if it reads the RTC by itself)
> * 1. hwclock sets the kernel UTC time to the local time in the RTC,
>     and thus the system clock could be wrong by several hours in either
>     direction.
>  2. System runs with wrong time. e2fsck can croak, etc.
>  3. something mounts /usr
> * 4. hwclock runs, and tells the user a completely ludricous time
>     (timezone applied twice :P) <=== We could fix the mess here, so
>     if the user doesn't hit a bug (e.g. e2fsck) before, he would not
>     suffer much from his broken config.
>     hwclock MUST be run after /usr is mounted to be able to help fix
>     the mess (well work around it, realy).

I don't have my unstable box handy to check right now, but it gets fixed 
eventually.  I think when hwclock runs after /usr is mounted, it sets the 
time correctly.  So it's only wrong before that point.  I used to have 
this broken config, and until e2fsck was changed to start complaining, I 
never noticed a problem.  (Actually, I think there was something funny 
with computing module dependencies, but I worked around that somehow.)

> Now, there's a bug in that hwclockfirst should bitch to all winds if it
> detects an invalid config, currently it just outputs a meek "System clock
> was not updated at this time" and bangs out with exit status 1.

Agreed.  I always assumed that message was innocuous.

> There is also a bug in that hwclockfirst must be one of the VERY first
> things to be run, AND that hwclock must be run AFTER /etc/localtime is
> working well in a typical Debian system.  I.e. *after* /usr is mounted.
>
> And there is a third bug which is the lack of easy TZ handling and lack of
> documentation.  The funny thing is that I could swear I added TZ and some
> documentation to hwclockfirst, but that script has been extensively
> modified since then.
>
> After hwclock has enough infrastructure for it (i.e. /etc/default/timezone
> or somesuch), d-i should be enhanced to set THAT if it is going to set
> UTC=no.

You know, another solution would be to relocate the whole 
/usr/share/zoneinfo hierarchy to the root filesystem.  I don't really like 
it, but it seems that we really may need all  that information early in 
the boot process.  Setting TZ isn't as good.  OTOH, it's a significant 
change just to benefit those "weird" people who have their hw clocks set 
to local time, which isn't really the Unix way.  (I only did it because I 
was dual-booting Windows, which insisted on having the hw clock in local 
time.)

>
> I might submit a patch soon, it would have been faster than documenting all
> of the above...

Thanks for looking into this!

-- 
Nate Eldredge
nge@cs.hmc.edu

Message #51 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Nate Eldredge <nge@cs.hmc.edu>

Cc: 342887@bugs.debian.org, 342887-submitter@bugs.debian.org, Ken Kennedy <kkennedy@kenzoid.com>, Jan De Luyck <jan-bugs@kcore.org>

Subject: Re: hwclock must run after /usr

Date: Sun, 1 Jan 2006 23:14:22 -0200

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
everything transparently) in util-linux.

Either one must have one's clock on UTC as any non-braindamaged system does,
OR one's /etc/localtime better be in the root partition.  Otherwise, one has
to keep daylight savings in mind and fix TZ by himself... or risk breakage.

> Yes.  Note that setting TZ is rather inconvenient.  First because you have 

Using a hardware clock not in UTC is extremely inconvenient, as well. In
fact, supporting that has been extremely inconvenient for long YEARS, now.
I'd have dropped that support a loooong time ago.

At least this time, I know there is nothing better we can do.  The user has
two choices, either he must have the hw clock in UTC, or he must have his
system fully timezone-capable since instant zero, which means /etc/localtime
MUST be in the root partition.

Setting TZ is kind of a middleground fix, a best effort fix if you will.
And it does work, but it means people have to go and manually fix TZ when
entering and leaving daylight savings time...

> forget which package has the config script where you select your timezone, 

libc6 has tzconfig.

> but I guess it could in principle apply it in both places.  But that's 

Yes, it could be changed.

> kind of ugly, and anyway the Debian philospohy is not to force people into 
> using config scripts.

Well, if we were to do it in the strict Debian way (always do what is more
correct technically speaking), we would drop non-UTC support. It complicates
the boot procedure, it is prone to *very* subtle bugs, and it is technically
insane to have a hardware clock in local time, and Microsoft itself only
does so because they were dumb enough not to fix that in Windows 95, and
because of MSDOS before that.

But we try our best to support it, since people seem to find it useful.  If
that means they will have to jump through loops, that means they will have
to jump through loops.

But we certainly need to document this better, and d-i should warn the user
right away that using the hardware clock in local time mode IS NOT a good
idea, and that the system might not be able to deal automatically with
daylight savings in that case.

> >What would happen in the typical broken configuration?
> >
> >Non-UTC, /usr separate, no TZ defined anywhere:
> > 0. kernel boots with wrong time (even if it reads the RTC by itself)
> >* 1. hwclock sets the kernel UTC time to the local time in the RTC,
> >    and thus the system clock could be wrong by several hours in either
> >    direction.
> > 2. System runs with wrong time. e2fsck can croak, etc.
> > 3. something mounts /usr
> >* 4. hwclock runs, and tells the user a completely ludricous time
> >    (timezone applied twice :P) <=== We could fix the mess here, so
> >    if the user doesn't hit a bug (e.g. e2fsck) before, he would not
> >    suffer much from his broken config.
> >    hwclock MUST be run after /usr is mounted to be able to help fix
> >    the mess (well work around it, realy).
> 
> I don't have my unstable box handy to check right now, but it gets fixed 
> eventually.  I think when hwclock runs after /usr is mounted, it sets the 
> time correctly.  So it's only wrong before that point.  I used to have 

Yes, but this bug showed up exactly because it is not running after /usr
anymore (which is in fact broken behaviour and should be fixed, as I
explained).

> You know, another solution would be to relocate the whole 
> /usr/share/zoneinfo hierarchy to the root filesystem.  I don't really like 

That's 5MiB more in the root filesystem.  One can always ask the glibc
maintainers to do it, or one can ask them to add something that keeps track
of /etc/localtime and updates it every time glibc is updated or tzconfig is
run, so only the required data would end up in the root partition (and
/etc/localtime would not be a symlink anymore).

I won't though. If the submitter feels like doing it, be my guest. Remember
to point the glibc people to this bug so that they get the whole story.

> to local time, which isn't really the Unix way.  (I only did it because I 
> was dual-booting Windows, which insisted on having the hw clock in local 
> time.)

Does it even do that anymore?  Anyway, just lie about your timezone to
Windows so that you get the correct time, and keep the clock in UTC.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #61 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: 342887@bugs.debian.org

Subject: [PATCH] move hwclock to S05 and S46. Fix initscript problems

Date: Thu, 5 Jan 2006 21:37:59 -0200

[Message part 1 (text/plain, inline)]

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 mounting /usr.


USER'S GUIDE:

1. Install util-linux with the patch applied
2. Edit hwclockfirst.sh and set TZ to your timezone
3. Change that TZ according to daylight savings time, manually.

The TZ hack will be uncessary eventually, and util-linux will be fixed
accordingly to not mention TZ anymore in the initscript (dpkg will warn you
that the initscript conffile has changed).  When that happens, please update
the initscript.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

[util-linux-hwclock.diff (text/plain, attachment)]

Message #70 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Martin Stolle <mstoll@sus.mcgill.ca>

To: Debian Bug Tracking System <342887@bugs.debian.org>

Subject: util-linux: please copy /etc/localtime

Date: Thu, 12 Jan 2006 18:44:06 -0500

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 to a timezone spec that requires
/usr/share/zoneinfo itself!

The only valid solution is to copy the appropriate timezone info to
/etc/localtime.  Rerunning tzconfig or recopying this file when
/usr/share/zoneinfo is updated is a perfectly fine solution and by far
the least hackiest solution.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages util-linux depends on:
ii  libc6         2.3.5-11                   GNU C Library: Shared libraries an
ii  libncurses5   5.5-1                      Shared libraries for terminal hand
ii  libslang2     2.0.5-1                    The S-Lang programming library - r
ii  libuuid1      1.38+1.39-WIP-2005.12.31-1 universally unique id library
ii  zlib1g        1:1.2.3-9                  compression library - runtime

util-linux recommends no packages.

-- no debconf information

Message #75 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Martin Stolle <mstoll@sus.mcgill.ca>, 342887@bugs.debian.org

Subject: Re: Bug#342887: util-linux: please copy /etc/localtime

Date: Thu, 12 Jan 2006 23:32:16 -0200

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 report back that NOTHING
breaks...).

I have that running on two systems already, no problems so far. I believe we
have to test the KDE and GNOME timezone setting stuff too, but those should
be changed in Debian to use tzconfig and /etc/timezone anyway, so if they
break, we just fix them and go ahead.

> /usr/share/zoneinfo is updated is a perfectly fine solution and by far
> the least hackiest solution.

Yes. TZ=something is just a workaround.

BTW, RedHat does what we are trying to do, so I am pretty sure we won't have
much problems, just some Debian scripts (in the glibc package) to fix.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #80 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Rob Heilman <robheilman@digger.cc>

To: 342887@bugs.debian.org

Subject: Re: Bug#342887: util-linux: please copy /etc/localtime

Date: Wed, 18 Jan 2006 17:53:21 -0500

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 having this problem as that it seems the trigger is having a
separate /usr and HW clock set to local.

Did I miss something in the explination above?  I have made no
customizations to my timezone settings anywhere other than the install
dialogs.

Message #85 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Thomas Hood <jdthood@yahoo.co.uk>

To: Rob Heilman <robheilman@digger.cc>

Cc: 342887@bugs.debian.org

Subject: Re: Bug#342887

Date: Tue, 24 Jan 2006 15:20:36 +0100

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 localtime, my
> timezone is EST, and to observe daylight savings.  I do not understand
> why I am having this problem as that it seems the trigger is having a
> separate /usr and HW clock set to local.
> 
> Did I miss something in the explination above?  I have made no
> customizations to my timezone settings anywhere other than the install
> dialogs.


There is a bug in util-linux: hwclockfirst.sh is not run early enough.

hwclockfirst.sh should be run earlier than checkroot.sh so that the system
clock gets correctly set before fsck is run.
-- 
Thomas Hood

Message #92 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>

To: 342887@bugs.debian.org

Subject: hwclock sets the wrong time

Date: Wed, 25 Jan 2006 17:32:29 +0100

From: Joey Hess <joeyh@debian.org>
| 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

Message #99 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Mario Lipinski <debian-bugs@l4w.info>

To: Debian Bug Tracking System <342887@bugs.debian.org>

Subject: util-linux: How to use TZ?

Date: Mon, 30 Jan 2006 12:55:36 +0100

Package: util-linux
Version: 2.12r-6
Followup-For: Bug #342887

To what should i set the TZ var?
Living in Germany. (CET, Europe/Berlin)
Getting the clock set +1h every time i boot my laptop is quite annoying.

Mario
-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.1-absinth
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE)

Versions of packages util-linux depends on:
ii  libc6         2.3.5-12                   GNU C Library: Shared libraries an
ii  libncurses5   5.5-1                      Shared libraries for terminal hand
ii  libslang2     2.0.5-3                    The S-Lang programming library - r
ii  libuuid1      1.38+1.39-WIP-2005.12.31-1 universally unique id library
ii  lsb-base      3.0-15                     Linux Standard Base 3.0 init scrip
ii  zlib1g        1:1.2.3-9                  compression library - runtime

util-linux recommends no packages.

-- no debconf information

Message #104 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Mario Lipinski <debian-bugs@l4w.info>, 342887@bugs.debian.org

Subject: Re: Bug#342887: util-linux: How to use TZ?

Date: Mon, 30 Jan 2006 10:47:21 -0200

On Mon, 30 Jan 2006, Mario Lipinski wrote:
> To what should i set the TZ var?
> Living in Germany. (CET, Europe/Berlin)
> Getting the clock set +1h every time i boot my laptop is quite annoying.

You will also have to move /etc/rc.d/S??hwclockfirst.sh to priority 05, or
it won't be any good.

CET is UTC + 1 hour, so that'd make TZ="CET-01:00"

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #109 received at 342887@bugs.debian.org (full text, mbox, reply):

From: "Dwayne C. Litzenberger" <dlitz@dlitz.net>

To: 342887@bugs.debian.org

Subject: Re: Bug#342887: util-linux: How to use TZ?

Date: Sat, 18 Mar 2006 16:07:25 -0600

Why doesn't someone just fix e2fsck?  It seems to me that crapping out just 
because the system clock is wrong is severely brain-damaged.

-- 
Dwayne C. Litzenberger <dlitz@dlitz.net>

Message #116 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Mike Dornberger <Mike.Dornberger@gmx.de>

To: Debian Bug Tracking System <342887@bugs.debian.org>

Subject: util-linux: Problems with /etc/localtime is a dangling symlink at boot - possible solution?

Date: Mon, 1 May 2006 15:27:14 +0200

Package: util-linux
Version: 2.12p-4sarge1
Followup-For: Bug #342887

Hi,

is /etc/localtime a symlink to save space on the rootfs or to easily see
what timezone the system is running?

If the latter, and /usr is a mountpoint, why not (with some debconf stuff;
asking user if he/she wants to, if UTC=no)
mount --bind / /tmp/rootfs
and install a symlink [/tmp/rootfs]/usr/share/zoneinfo pointing to e. g.
/etc/util-linux/zoneinfo where the zoneinfo file can be copied to on
updates? (On Sarge, i386 the biggest zoneinfo file right/Asia/Riyadh87 has
3840 bytes; plus the space needed for up to 3 subdirs, e. g.
posix/America/Argentina/.)

Maybe the libc6, initscripts and util-linux maintainers have to work
together for keeping things in sync then. (Changing local timezone?)

Greetings,
 Mike Dornberger

Message #121 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Mike Dornberger <Mike.Dornberger@gmx.de>, 342887@bugs.debian.org

Subject: Re: Bug#342887: util-linux: Problems with /etc/localtime is a dangling symlink at boot - possible solution?

Date: Tue, 2 May 2006 11:43:44 -0300

On Mon, 01 May 2006, Mike Dornberger wrote:
> is /etc/localtime a symlink to save space on the rootfs or to easily see
> what timezone the system is running?

It did both, but in hindsight it was a major design error.

Current code can very easily be changed (been there, done that, didn't get
any bad side-effects to date) to drop the symlink and use either handlinks
(if /usr is in the same partition -- in which case a symlink would do just
fine as well :( ) or copy the data from /usr.

> If the latter, and /usr is a mountpoint, why not (with some debconf stuff;

You don't need to add this much complexity to fix the issue, you can just do
as Fedora Core does, and cp <timezone file> /etc/localtime.  Only a few
*debian* scripts need to be fixed to not place a symlink back in there, and
some documentation needs to be updated.

> Maybe the libc6, initscripts and util-linux maintainers have to work
> together for keeping things in sync then. (Changing local timezone?)

You need the libc6 package to provide proper /etc/localtime at early boot
(i.e. to use cp and not symlinks if /usr is a separate partition).  You need
the util-linux package to fix the broken hwclock scripts.  You don't need
the initscripts package to do anything.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #126 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Christoph Pleger <Christoph.Pleger@cs.uni-dortmund.de>

To: Debian Bug Tracking System <342887@bugs.debian.org>

Subject: Status?

Date: Thu, 12 Oct 2006 14:14:29 +0200

Package: util-linux
Version: 2.12r-10
Followup-For: Bug #342887

May I ask what the exact status of this is at the moment? More than five
months have gone since the last comment on this topic and the problem
still exists in the current util-linux package for the upcoming release
of etch.

By the way, I believe that this is not only an important but even a
release critical bug because it is a serious problem if for example
(like in my case) two hours are added to the system time in every boot
phase.

Regards
  Christoph Pleger

Message #131 received at 342887-close@bugs.debian.org (full text, mbox, reply):

From: LaMont Jones <lamont@debian.org>

To: 342887-close@bugs.debian.org

Subject: Bug#342887: fixed in util-linux 2.12r-12

Date: Mon, 23 Oct 2006 17:51:58 -0700

Source: util-linux
Source-Version: 2.12r-12

We believe that the bug you reported is fixed in the latest version of
util-linux, which is due to be installed in the Debian FTP archive:

bsdutils_2.12r-12_i386.deb
  to pool/main/u/util-linux/bsdutils_2.12r-12_i386.deb
cfdisk-udeb_2.12r-12_i386.udeb
  to pool/main/u/util-linux/cfdisk-udeb_2.12r-12_i386.udeb
fdisk-udeb_2.12r-12_i386.udeb
  to pool/main/u/util-linux/fdisk-udeb_2.12r-12_i386.udeb
mount_2.12r-12_i386.deb
  to pool/main/u/util-linux/mount_2.12r-12_i386.deb
util-linux-locales_2.12r-12_all.deb
  to pool/main/u/util-linux/util-linux-locales_2.12r-12_all.deb
util-linux_2.12r-12.diff.gz
  to pool/main/u/util-linux/util-linux_2.12r-12.diff.gz
util-linux_2.12r-12.dsc
  to pool/main/u/util-linux/util-linux_2.12r-12.dsc
util-linux_2.12r-12_i386.deb
  to pool/main/u/util-linux/util-linux_2.12r-12_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 342887@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
LaMont Jones <lamont@debian.org> (supplier of updated util-linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 19 Oct 2006 19:01:33 -0600
Source: util-linux
Binary: util-linux cfdisk-udeb fdisk-udeb util-linux-locales bsdutils mount
Architecture: all i386 source 
Version: 2.12r-12
Distribution: unstable
Urgency: low
Maintainer: LaMont Jones <lamont@debian.org>
Changed-By: LaMont Jones <lamont@debian.org>
Description: 
 bsdutils   - Basic utilities from 4.4BSD-Lite
 cfdisk-udeb - Partition a hard drive (cfdisk)
 fdisk-udeb - Partition a hard drive (manual)
 mount      - Tools for mounting and manipulating filesystems
 util-linux - Miscellaneous system utilities
 util-linux-locales - Locales files for util-linux
Closes: 342887 392236
Changes: 
 util-linux (2.12r-12) unstable; urgency=low
 .
   * drop hwclockfirst.sh, and put hwclock.sh back at 50.  See #50572 and
     Closes: #342887
   * Deal with _syscall5 going away.  Patch imported from Ubuntu.
     Closes: #392236
Files: 
 d4800cc1396e5458f40885870b343343 740 base required util-linux_2.12r-12.dsc
 47e43502684d45a24a0e257552f70ab9 483484 debian-installer extra cfdisk-udeb_2.12r-12_i386.udeb
 733b48a3bb73c0eaca6330a5d0609504 372458 utils required util-linux_2.12r-12_i386.deb
 a8eb4da947eedde1cabaecfe6c33e0e4 1084740 utils optional util-linux-locales_2.12r-12_all.deb
 acb1be73af882cb7845d142334f2dffe 67788 utils required bsdutils_2.12r-12_i386.deb
 c870a876d4748abb8054dc9799ce4f50 100566 base required util-linux_2.12r-12.diff.gz
 d027bf7f1e1f5b93af73385adfd83ecb 58000 debian-installer extra fdisk-udeb_2.12r-12_i386.udeb
 ed3930152dee65b85a8df70116b4b724 155802 admin required mount_2.12r-12_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFPU8kzN/kmwoKyScRAgUEAJ9W4XR5qtw0sKrjtyevkXLwncv0vgCeMqR4
2xlOHW/kKKj3KvfOxPchVzI=
=fZwi
-----END PGP SIGNATURE-----

Message #151 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <sven_joachim@web.de>

To: 342887@bugs.debian.org

Subject: hwclock.sh runs too late, files have incorrect timestamps

Date: Fri, 27 Oct 2006 14:20:39 +0200

reopen 342887
thanks

Quoting /usr/share/doc/util-linux/changelog.Debian.gz:

,----
|   * drop hwclockfirst.sh, and put hwclock.sh back at 50.  See #50572 and
|     Closes: #342887
`----

Ahem, shouldn't hwclock.sh be run as early as possible, not as late as
possible?!  I have UTC=no and several files modified by the boot
scripts had their timestamps in the future after booting :-(

If I understand the lengthy logs for #342887 correctly, the problem
was that /etc/localtime might not be readable before /usr was
mounted.  However, this was fixed in libc6 2.3.6-6, /etc/localtime
should now always be a real file, not a symlink (see #346342).

So why can't hwclock.sh run earlier (not before checkroot.sh, of
course)?  I gave it priority 11, AFICS this works fine.

Message #158 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 342887@bugs.debian.org

Cc: Sven Joachim <sven_joachim@web.de>, Henrique de Moraes Holschuh <hmh@debian.org>

Subject: hwclock.sh runs too late

Date: Tue, 31 Oct 2006 17:37:42 +0100

[Message part 1 (text/plain, inline)]

As /etc/localtime is a copy and not a symlink anymore, hwclock.sh could
 be started even earlier than S11. The only requirement I see is S03udev
(because of /dev/rtc). So the earliest possible time would be S04. As
Thomas pointed out earlier, it should also be started before
S10checkroot.sh. So somewhere between 04 and 10 would be a good place.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #163 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 342887@bugs.debian.org

Subject: severity serious

Date: Tue, 31 Oct 2006 17:40:40 +0100

[Message part 1 (text/plain, inline)]

I'm also for raising the severity of this bug to serious, as it
potentially breaks many packages (as in #396137) in very subtle ways.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #168 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 342887@bugs.debian.org

Subject: hwclock.sh runs too late

Date: Tue, 31 Oct 2006 17:20:57 +0100

[Message part 1 (text/plain, inline)]

I also had to discover, that running hwclock.sh that late (S50) causes
some very strange behaviour. See bug #396137 as a reference.

In short, it kills the roaming mode of wpasupplicant, because networking
is started at 40 and hwclock afterwards at 50.
I have to agree, that hwclock.sh has to be run as ealry as possible,
meaning as soon as /usr is available.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #175 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <sven_joachim@web.de>

To: Michael Biebl <biebl@debian.org>

Cc: 342887@bugs.debian.org, Henrique de Moraes Holschuh <hmh@debian.org>

Subject: Re: hwclock.sh runs too late

Date: Tue, 31 Oct 2006 20:37:32 +0100

Michael Biebl writes:
> As /etc/localtime is a copy and not a symlink anymore, hwclock.sh could
>  be started even earlier than S11. The only requirement I see is S03udev
> (because of /dev/rtc). So the earliest possible time would be S04. As
> Thomas pointed out earlier, it should also be started before
> S10checkroot.sh. So somewhere between 04 and 10 would be a good place.

In this case, hwclock.sh cannot write to /etc/adjtime because the root
filesystem is still mounted read-only.  Currently hwclock.sh creates
/etc/adjtime if it doesn't exist, but that might not be necessary, I don't
know.

Cheers,

Sven

Message #180 received at 342887@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Sven Joachim <sven_joachim@web.de>

Cc: Michael Biebl <biebl@debian.org>, 342887@bugs.debian.org

Subject: Re: hwclock.sh runs too late

Date: Tue, 31 Oct 2006 17:11:05 -0300

On Tue, 31 Oct 2006, Sven Joachim wrote:
> In this case, hwclock.sh cannot write to /etc/adjtime because the root
> filesystem is still mounted read-only.  Currently hwclock.sh creates
> /etc/adjtime if it doesn't exist, but that might not be necessary, I don't
> know.

hwclock can cope well with read-only adjtime, if you do things right, EVEN
when you depend on adjtime to keep your clock working right (which nowadays
mostly nobody does, as chrony and ntp have taken over).  This was one of the
reasons behind the split into hwclockfirst and hwclock initscripts.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Message #185 received at 342887-close@bugs.debian.org (full text, mbox, reply):

From: LaMont Jones <lamont@debian.org>

To: 342887-close@bugs.debian.org

Subject: Bug#342887: fixed in util-linux 2.12r-13

Date: Tue, 31 Oct 2006 16:23:25 -0800

Source: util-linux
Source-Version: 2.12r-13

We believe that the bug you reported is fixed in the latest version of
util-linux, which is due to be installed in the Debian FTP archive:

bsdutils_2.12r-13_i386.deb
  to pool/main/u/util-linux/bsdutils_2.12r-13_i386.deb
cfdisk-udeb_2.12r-13_i386.udeb
  to pool/main/u/util-linux/cfdisk-udeb_2.12r-13_i386.udeb
fdisk-udeb_2.12r-13_i386.udeb
  to pool/main/u/util-linux/fdisk-udeb_2.12r-13_i386.udeb
mount_2.12r-13_i386.deb
  to pool/main/u/util-linux/mount_2.12r-13_i386.deb
util-linux-locales_2.12r-13_all.deb
  to pool/main/u/util-linux/util-linux-locales_2.12r-13_all.deb
util-linux_2.12r-13.diff.gz
  to pool/main/u/util-linux/util-linux_2.12r-13.diff.gz
util-linux_2.12r-13.dsc
  to pool/main/u/util-linux/util-linux_2.12r-13.dsc
util-linux_2.12r-13_i386.deb
  to pool/main/u/util-linux/util-linux_2.12r-13_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 342887@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
LaMont Jones <lamont@debian.org> (supplier of updated util-linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Tue, 31 Oct 2006 13:51:50 -0700
Source: util-linux
Binary: util-linux cfdisk-udeb fdisk-udeb util-linux-locales bsdutils mount
Architecture: all i386 source 
Version: 2.12r-13
Distribution: unstable
Urgency: low
Maintainer: LaMont Jones <lamont@debian.org>
Changed-By: LaMont Jones <lamont@debian.org>
Description: 
 bsdutils   - Basic utilities from 4.4BSD-Lite
 cfdisk-udeb - Partition a hard drive (cfdisk)
 fdisk-udeb - Partition a hard drive (manual)
 mount      - Tools for mounting and manipulating filesystems
 util-linux - Miscellaneous system utilities
 util-linux-locales - Locales files for util-linux
Closes: 297789 342887 394941
Changes: 
 util-linux (2.12r-13) unstable; urgency=low
 .
   * NFS seems to not like 127.0.0.1 as a client ID for everyone.
     Closes: #394941
     - 30nfs4-setclientid.dpatch by Steinar H. Gunderson <sesse@debian.org>
   * Move hwclock.sh to 8 since localtime is now a file, not a symlink.
     Adds Depends: tzdata (>=2006c-2)
     Closes: #342887
   * ship rdev on amd64.  Closes: #297789
Files: 
 1db3826062471b1b4970c57f59a9703f 156234 admin required mount_2.12r-13_i386.deb
 486a3bf463e9eb0b8033c15b0b8073a3 740 base required util-linux_2.12r-13.dsc
 4cd3de3ab072bc244198739ab26e6701 101859 base required util-linux_2.12r-13.diff.gz
 6d151675f25f551133a249d0e98f1b88 372576 utils required util-linux_2.12r-13_i386.deb
 7c69a09628dfc2e8ba23715f1cb438c3 483470 debian-installer extra cfdisk-udeb_2.12r-13_i386.udeb
 c62bbb056ae520cd58d866c53a168b64 67892 utils required bsdutils_2.12r-13_i386.deb
 d9df018d305243630cff3f74d71c3432 58002 debian-installer extra fdisk-udeb_2.12r-13_i386.udeb
 de59ecf2943437d33ccbe6111f4c1cc8 1084872 utils optional util-linux-locales_2.12r-13_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFFR77VzN/kmwoKyScRAmOYAJ4vg3I3OHI4azLwkPg+7VfRRGTqTgCgm/QF
G1WwWWQrSCCj8PF67j5VcQA=
=ouDb
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.