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

[Debian Bug Importer]

Automatically imported from Debian bug report #342887 http://bugs.debian.org/342887

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #342887 http://bugs.debian.org/342887

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 11 Dec 2005 15:30:47 +0100
From: Robert Luberda <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: util-linux: hwclock runs too early, breaking the system time

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

[Jan De Luyck (jan-bugs)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 12 Dec 2005 17:54:52 +0100
From: Jan De Luyck <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: util-linux: hwclock runs too early, breaking the system time

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

[Ken Kennedy (kkennedy)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <20051213014428.9327.20176.reportbug@localhost>
Date: Mon, 12 Dec 2005 20:44:28 -0500
From: Ken Kennedy <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: util-linux: Seeing same issue...

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

[Nate Eldredge (nge)]

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
<email address hidden>

[Debian Bug Importer (debzilla)]

Message-ID: <Pine.GSO.4.63.0512151414390.29434@turing>
Date: Thu, 15 Dec 2005 14:35:07 -0800 (PST)
From: Nate Eldredge <email address hidden>
To: <email address hidden>
Subject: Re: util-linux: hwclock runs too early, breaking the system time

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
<email address hidden>

[Michael Spang (mspang)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 17 Dec 2005 00:12:13 -0500
From: Michael Spang <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: util-linux: too early yet too late

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

[Joey Hess (joeyh)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 27 Dec 2005 13:14:11 -0500
From: Joey Hess <email address hidden>
To: <email address hidden>
Subject: /etc/localtime

--IS0zKkzwUGydFO0o
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
=66rom 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?

--=20
see shy jo

--IS0zKkzwUGydFO0o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFDsYRzd8HHehbQuO8RAhcvAJ0XHhXaB3152qGfv1lrvxGcZX91swCeK2TI
Ux6nDGS95/cfXvlcgCNZa5s=
=fo4d
-----END PGP SIGNATURE-----

--IS0zKkzwUGydFO0o--

[Henrique de Moraes Holschuh (hmh)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 31 Dec 2005 15:58:44 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: <email address hidden>, <email address hidden>
Cc: Nate Eldredge <email address hidden>, Ken Kennedy <email address hidden>,
 Jan De Luyck <email address hidden>
Subject: hwclock must run after /usr

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

[Nate Eldredge (nge)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <Pine.GSO.4.63.0601011346350.13415@turing>
Date: Sun, 1 Jan 2006 14:22:25 -0800 (PST)
From: Nate Eldredge <email address hidden>
To: Henrique de Moraes Holschuh <email address hidden>
Cc: <email address hidden>, <email address hidden>,
 Nate Eldredge <email address hidden>, Ken Kennedy <email address hidden>,
 Jan De Luyck <email address hidden>
Subject: Re: hwclock must run after /usr

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

[Henrique de Moraes Holschuh (hmh)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 1 Jan 2006 23:14:22 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: Nate Eldredge <email address hidden>
Cc: <email address hidden>, <email address hidden>, Ken Kennedy <email address hidden>,
 Jan De Luyck <email address hidden>
Subject: Re: hwclock must run after /usr

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

[Thomas Hood (jdthood-yahoo)]

reopen 346064
merge 346064 342887
reopen 343645
stop

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 05 Jan 2006 11:36:36 +0100
From: Thomas Hood <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: Re: [Pkg-sysvinit-devel] Processed: Re: Bug#343645: e2fsprogs: Superblock
 last mount time is in the future, fix it ? (Y)

reopen 346064
merge 346064 342887
reopen 343645
stop

[Debian Bug Importer (debzilla)]

*** Bug 28016 has been marked as a duplicate of this bug. ***

[Henrique de Moraes Holschuh (hmh)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 5 Jan 2006 21:37:59 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: <email address hidden>
Subject: [PATCH] move hwclock to S05 and S46. Fix initscript problems

--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: 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

--6TrnltStXW4iwmi0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="util-linux-hwclock.diff"

diff -ruN util-linux-2.12r/debian/hwclock.sh util-linux-2.12r-fix2/debian/hwclock.sh
--- util-linux-2.12r/debian/hwclock.sh 2006-01-05 09:17:51.677942513 -0200
+++ util-linux-2.12r-fix2/debian/hwclock.sh 2006-01-05 20:41:58.799569064 -0200
@@ -11,6 +11,12 @@
 # during startup/shutdown.
 # - Added comments to alert users of hwclock issues
 # and discourage tampering without proper doc reading.
+# 2006-01-05 Henrique M. Holschuh <email address hidden>
+# - Improve message handling
+# - Fix FIRST=yes/no invocations of hwclock --hctosys,
+# and other minor things
+# - Make very sure /etc/adjtime is not used on FIRST=yes
+# - Follow symlinks in /etc/adjtime (no reason not to)

 # WARNING: Please read /usr/share/doc/util-linux/README.Debian.hwclock
 # before changing this file. You risk serious clock
@@ -22,8 +28,15 @@
 # as machine hardware clock type for Alphas.
 HWCLOCKPARS=

+# Set this to your timezone if your clock is not in UTC, this hack will go
+# away soon. Make sure to use the simplest form for TZ, see tzset(3) for
+# details
+# e.g. TZ=ABC+03:00 for GMT-3:00, TZ=AAA-05:30 for UTC+05:30
+#
+#TZ=
+
 [ ! -x /sbin/hwclock ] && exit 0
-. /etc/default/rcS
+[ -r /etc/default/rcS ] && . /etc/default/rcS

 . /lib/lsb/init-functions
 verbose_log_action_msg() { [ "$VERBOSE" = no ] || log_action_msg "$@"; }
@@ -34,7 +47,9 @@
   UTC=""
   if [ "X$FIRST" = "Xyes" ] && [ ! -r /etc/localtime ]; then
       if [ -z "$TZ" ]; then
- log_action_msg "System clock was not updated at this time"
+ log_warning_msg "Hardware clock misconfiguration detected!"
+ log_warning_msg "Hardware clock not in UTC, TZ unset and /etc/localtime unreadable"
+ log_failure_msg "System clock was not updated at this time"
    exit 1
       fi
   fi
@@ -42,55 +57,65...

[Thomas Hood (jdthood-yahoo)]

severity 344818 serious
tags 344818 patch
merge 344818 342887
retitle 300559 util-linux: hwclock hangs up Dell PW 670
retitle 339831 util-linux: [hwclock] Typos in hwclock.sh
stop

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 06 Jan 2006 14:15:16 +0100
From: Thomas Hood <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: housekeeping

severity 344818 serious
tags 344818 patch
merge 344818 342887
retitle 300559 util-linux: hwclock hangs up Dell PW 670
retitle 339831 util-linux: [hwclock] Typos in hwclock.sh
stop

[Debian Bug Importer (debzilla)]

*** Bug 28072 has been marked as a duplicate of this bug. ***

[Martin Stolle (mstoll)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <20060112234406.5908.74020.reportbug@localhost>
Date: Thu, 12 Jan 2006 18:44:06 -0500
From: Martin Stolle <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: util-linux: please copy /etc/localtime

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

[Henrique de Moraes Holschuh (hmh)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 12 Jan 2006 23:32:16 -0200
From: Henrique de Moraes Holschuh <email address hidden>
To: Martin Stolle <email address hidden>, <email address hidden>
Subject: Re: Bug#342887: util-linux: please copy /etc/localtime

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

[Rob Heilman (robheilman)]

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.

[Thomas Hood (jdthood-yahoo)]

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

[Goswin von Brederlow (brederlo)]

From: Joey Hess <email address hidden>
| 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

[LaMont Jones (lamont)]

severity 342887 important

[Mario Lipinski (debian-bugs-l4w)]

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

[Henrique de Moraes Holschuh (hmh)]

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

[Darsey Litzenberger (dlitz)]

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 <email address hidden>

[LaMont Jones (lamont)]

# Automatically generated email from bts, devscripts version 2.9.10
severity 362274 important
merge 362274 342887

[Mike Dornberger (mike-dornberger)]

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

[Henrique de Moraes Holschuh (hmh)]

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

[Scott James Remnant (Canonical) (canonical-scott)]

hwclock on Ubuntu is not run until /usr is mounted

[Christoph Pleger (christoph-pleger-cs-uni-dortmund)]

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

[LaMont Jones (lamont)]

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 <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
LaMont Jones <email address hidden> (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 <email address hidden>)

-----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 <email address hidden>
Changed-By: LaMont Jones <email address hidden>
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/kmwoKyScRAgUEAJ9W4XR5qtw0sK...

[Sven Joachim (sven-joachim)]

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.

[Michael Biebl (mbiebl)]

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?

[Michael Biebl (mbiebl)]

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?

[Michael Biebl (mbiebl)]

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?

[Michael Biebl (biebl)]

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

[Sven Joachim (sven-joachim)]

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

[Henrique de Moraes Holschuh (hmh)]

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

[LaMont Jones (lamont)]

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 <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
LaMont Jones <email address hidden> (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 <email address hidden>)

-----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 <email address hidden>
Changed-By: LaMont Jones <email address hidden>
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 <email address hidden>
   * 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 ...