util-linux: hwclock runs too early, breaking the system time
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
util-linux (Debian) |
Fix Released
|
Unknown
|
|||
util-linux (Ubuntu) |
Fix Released
|
High
|
Scott James Remnant (Canonical) |
Bug Description
Automatically imported from Debian bug report #342887 http://
Debian Bug Importer (debzilla) wrote : | #1 |
Debian Bug Importer (debzilla) wrote : | #2 |
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=
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
In Debian Bug tracker #342887, Jan De Luyck (jan-bugs) wrote : | #3 |
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=
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.
ii zlib1g 1:1.2.3-8 compression library - runtime
util-linux recommends no packages.
-- no debconf information
Debian Bug Importer (debzilla) wrote : | #4 |
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=
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.
ii zlib1g 1:1.2.3-8 compression library - runtime
util-linux recommends no packages.
-- no debconf information
In Debian Bug tracker #342887, Ken Kennedy (kkennedy) wrote : util-linux: Seeing same issue... | #5 |
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=
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.
ii zlib1g 1:1.2.3-8 compression library - runtime
util-linux recommends no packages.
-- no debconf information
Debian Bug Importer (debzilla) wrote : | #6 |
Message-ID: <20051213014428
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=
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.
ii zlib1g 1:1.2.3-8 compression library - runtime
util-linux recommends no packages.
-- no debconf information
In Debian Bug tracker #342887, Nate Eldredge (nge) wrote : | #7 |
I see this behavior as well. Unfortunately there is a catch-22 in fixing
it. e2fsck as of e2fsprogs-
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) wrote : | #8 |
Message-ID: <Pine.GSO.
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-
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>
In Debian Bug tracker #342887, Michael Spang (mspang) wrote : util-linux: too early yet too late | #9 |
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=
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.
ii zlib1g 1:1.2.3-8 compression library - runtime
util-linux recommends no packages.
-- no debconf information
Debian Bug Importer (debzilla) wrote : | #10 |
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=
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.
ii zlib1g 1:1.2.3-8 compression library - runtime
util-linux recommends no packages.
-- no debconf information
In Debian Bug tracker #342887, Joey Hess (joeyh) wrote : /etc/localtime | #11 |
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) wrote : | #12 |
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-
Content-
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/
Content-
Content-
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDsYRzd8H
Ux6nDGS95/
=fo4d
-----END PGP SIGNATURE-----
--IS0zKkzwUGydF
In Debian Bug tracker #342887, Henrique de Moraes Holschuh (hmh) wrote : hwclock must run after /usr | #13 |
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.
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/
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) wrote : | #14 |
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.
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/
Non-UTC...
In Debian Bug tracker #342887, Nate Eldredge (nge) wrote : | #15 |
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.
> 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) wrote : | #16 |
Message-ID: <Pine.GSO.
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.
> 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
>...
In Debian Bug tracker #342887, Henrique de Moraes Holschuh (hmh) wrote : | #17 |
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) wrote : | #18 |
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,...
In Debian Bug tracker #342887, Thomas Hood (jdthood-yahoo) wrote : Re: [Pkg-sysvinit-devel] Processed: Re: Bug#343645: e2fsprogs: Superblock last mount time is in the future, fix it ? (Y) | #19 |
reopen 346064
merge 346064 342887
reopen 343645
stop
Debian Bug Importer (debzilla) wrote : | #20 |
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-
last mount time is in the future, fix it ? (Y)
reopen 346064
merge 346064 342887
reopen 343645
stop
Debian Bug Importer (debzilla) wrote : | #21 |
*** Bug 28016 has been marked as a duplicate of this bug. ***
In Debian Bug tracker #342887, Henrique de Moraes Holschuh (hmh) wrote : [PATCH] move hwclock to S05 and S46. Fix initscript problems | #22 |
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) wrote : | #23 |
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-
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-
diff -ruN util-linux-
--- util-linux-
+++ util-linux-
@@ -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/
# 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/
verbose_
@@ -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...
In Debian Bug tracker #342887, Thomas Hood (jdthood-yahoo) wrote : housekeeping | #24 |
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) wrote : | #25 |
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) wrote : | #26 |
*** Bug 28072 has been marked as a duplicate of this bug. ***
In Debian Bug tracker #342887, Martin Stolle (mstoll) wrote : util-linux: please copy /etc/localtime | #27 |
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=
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.
ii zlib1g 1:1.2.3-9 compression library - runtime
util-linux recommends no packages.
-- no debconf information
Debian Bug Importer (debzilla) wrote : | #28 |
Message-ID: <20060112234406
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=
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.
ii zlib1g 1:1.2.3-9 compression library - runtime
util-linux recommends no packages.
-- no debconf information
In Debian Bug tracker #342887, Henrique de Moraes Holschuh (hmh) wrote : Re: Bug#342887: util-linux: please copy /etc/localtime | #29 |
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) wrote : | #30 |
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
In Debian Bug tracker #342887, Rob Heilman (robheilman) wrote : | #31 |
I have two newly installed (this week) Sarge systems that exhibit this
problem. I used the debian-
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.
In Debian Bug tracker #342887, Thomas Hood (jdthood-yahoo) wrote : Re: Bug#342887 | #32 |
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-
> 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
In Debian Bug tracker #342887, Goswin von Brederlow (brederlo) wrote : hwclock sets the wrong time | #33 |
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
In Debian Bug tracker #342887, LaMont Jones (lamont) wrote : severity of 342887 is important | #34 |
severity 342887 important
In Debian Bug tracker #342887, Mario Lipinski (debian-bugs-l4w) wrote : util-linux: How to use TZ? | #35 |
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=
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.
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
In Debian Bug tracker #342887, Henrique de Moraes Holschuh (hmh) wrote : Re: Bug#342887: util-linux: How to use TZ? | #36 |
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.
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
In Debian Bug tracker #342887, Darsey Litzenberger (dlitz) wrote : | #37 |
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>
In Debian Bug tracker #342887, LaMont Jones (lamont) wrote : severity of 362274 is important, merging 362274 342887 | #38 |
# Automatically generated email from bts, devscripts version 2.9.10
severity 362274 important
merge 362274 342887
In Debian Bug tracker #342887, Mike Dornberger (mike-dornberger) wrote : util-linux: Problems with /etc/localtime is a dangling symlink at boot - possible solution? | #39 |
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]
/etc/util-
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/
Maybe the libc6, initscripts and util-linux maintainers have to work
together for keeping things in sync then. (Changing local timezone?)
Greetings,
Mike Dornberger
In Debian Bug tracker #342887, Henrique de Moraes Holschuh (hmh) wrote : Re: Bug#342887: util-linux: Problems with /etc/localtime is a dangling symlink at boot - possible solution? | #40 |
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) wrote : | #41 |
hwclock on Ubuntu is not run until /usr is mounted
Changed in util-linux: | |
assignee: | lamont → keybuk |
status: | Unconfirmed → Fix Released |
In Debian Bug tracker #342887, Christoph Pleger (christoph-pleger-cs-uni-dortmund) wrote : Status? | #42 |
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
In Debian Bug tracker #342887, LaMont Jones (lamont) wrote : Bug#342887: fixed in util-linux 2.12r-12 | #43 |
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_
to pool/main/
cfdisk-
to pool/main/
fdisk-udeb_
to pool/main/
mount_2.
to pool/main/
util-linux-
to pool/main/
util-linux_
to pool/main/
util-linux_
to pool/main/
util-linux_
to pool/main/
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:
d4800cc1396e54
47e43502684d45
733b48a3bb73c0
a8eb4da947eedd
acb1be73af882c
c870a876d4748a
d027bf7f1e1f5b
ed3930152dee65
-----BEGIN PGP SIGNATURE----- iD8DBQFFPU8kzN/
Version: GnuPG v1.4.2.2 (GNU/Linux)
Changed in util-linux: | |
status: | Unconfirmed → Fix Released |
In Debian Bug tracker #342887, Sven Joachim (sven-joachim) wrote : hwclock.sh runs too late, files have incorrect timestamps | #44 |
reopen 342887
thanks
Quoting /usr/share/
,----
| * 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.
Changed in util-linux: | |
status: | Fix Released → Unconfirmed |
In Debian Bug tracker #342887, Michael Biebl (mbiebl) wrote : hwclock.sh runs too late | #45 |
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?
In Debian Bug tracker #342887, Michael Biebl (mbiebl) wrote : | #46 |
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?
In Debian Bug tracker #342887, Michael Biebl (mbiebl) wrote : severity serious | #47 |
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?
In Debian Bug tracker #342887, Michael Biebl (biebl) wrote : blocking bug | #48 |
block 396137 by 342887
thanks
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
In Debian Bug tracker #342887, Sven Joachim (sven-joachim) wrote : Re: hwclock.sh runs too late | #49 |
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
In Debian Bug tracker #342887, Henrique de Moraes Holschuh (hmh) wrote : | #50 |
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
In Debian Bug tracker #342887, LaMont Jones (lamont) wrote : Bug#342887: fixed in util-linux 2.12r-13 | #51 |
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_
to pool/main/
cfdisk-
to pool/main/
fdisk-udeb_
to pool/main/
mount_2.
to pool/main/
util-linux-
to pool/main/
util-linux_
to pool/main/
util-linux_
to pool/main/
util-linux_
to pool/main/
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-
* 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:
1db3826062471b
486a3bf463e9eb
4cd3de3ab072bc
6d151675f25f55
7c69a09628dfc2
c62bbb056ae520
d9df018d305243
de59ecf2943437
Changed in util-linux: | |
status: | Unconfirmed → Fix Released |
Automatically imported from Debian bug report #342887 http:// bugs.debian. org/342887