fsck should check against a timestamp "49710 days" old

Bug #43239 reported by kko on 2006-05-06
40
This bug affects 1 person
Affects Status Importance Assigned to Milestone
e2fsprogs (Debian)
Fix Released
Unknown
e2fsprogs (Ubuntu)
Medium
Unassigned
util-linux (Debian)
Fix Released
Unknown
util-linux (Ubuntu)
Undecided
Unassigned

Bug Description

If the system clock has been misadjusted while fsck last run, fsck reports on next boot that the partition "has gone 49710 days without being checked, check forced". Happens to me in Ubuntu after I do an occasional boot to a parallel partition if fsck gets run there.

This is clearly nonsense. A quick google of "fsck 49710" gives out numerous examples, revealing inter alia that 49710 days is close to 2^32 seconds, and gives a clear indication that fsck simply isn't equipped to deal with a misconfigured system clock.

In such a case fsck should only run if the filesystem was actually marked "dirty", i.e. not just because of the old timestamp. In addition, fsck probably could fix the timestamp.

The problem is annoying. It often occurs for me when I try to debug various system configuration issues (mainly X). Sometimes the system hangs, leading to a hard boot, leading to fsck, often leading to the further aggravation of unnecessary fsck checks due to a 136-year old timestamp.

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

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

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>

Package: e2fsprogs
Version: 1.38+1.39-WIP-2005.12.10-1
Severity: normal

Since upgrading to version 1.38+1.39-WIP-2005.12.10-1, whenever I boot
up, the following error is displayed:

/: Superblock last write time is in the future

The date & time on my system is kept in Eastern time (the hardware clock
that is). /etc/default/rcS has the following line: UTC=no

What is the cause of this error? I have a dual boot system with Windows.
Do I need to change how the clock is setup? If so, how?

-- 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.14-1-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages e2fsprogs depends on:
ii e2fslibs 1.38+1.39-WIP-2005.12.10-1 ext2 filesystem libraries
ii libblkid1 1.38+1.39-WIP-2005.12.10-1 block device id library
ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an
ii libcomerr2 1.38+1.39-WIP-2005.12.10-1 common error description library
ii libss2 1.38+1.39-WIP-2005.12.10-1 command-line interface parsing lib
ii libuuid1 1.38+1.39-WIP-2005.12.10-1 universally unique id library

e2fsprogs recommends no packages.

-- no debconf information

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

On Fri, Dec 16, 2005 at 03:41:20PM -0500, Rick Friedman wrote:
> Package: e2fsprogs
> Version: 1.38+1.39-WIP-2005.12.10-1
> Severity: normal
>
>
> Since upgrading to version 1.38+1.39-WIP-2005.12.10-1, whenever I boot
> up, the following error is displayed:
>
> /: Superblock last write time is in the future
>
> The date & time on my system is kept in Eastern time (the hardware clock
> that is). /etc/default/rcS has the following line: UTC=no
>
> What is the cause of this error? I have a dual boot system with Windows.
> Do I need to change how the clock is setup? If so, how?

Sigh, I see what's going on. Unfortunately S22hwclockfirst.sh gets
done *after* S10checkroot. So the system time is still incorrect when
we check the root filesystem; it doesn't get adjusted to account for
the fact that you're using a non-GMT time until afterwards. I run
with my hardware clock set to UTC, so I didn't notice this problem.

Could you try renaming /etc/rcS.d/S22hwclockfirst.sh to
/etc/rcS.d/S09hwclockfirst.sh and see if this addresses your problem?

      - Ted

On Sat, Dec 17, 2005 at 07:45:42PM -0500, Theodore Ts'o wrote:
> Sigh, I see what's going on. Unfortunately S22hwclockfirst.sh gets
> done *after* S10checkroot. So the system time is still incorrect when
> we check the root filesystem; it doesn't get adjusted to account for
> the fact that you're using a non-GMT time until afterwards. I run
> with my hardware clock set to UTC, so I didn't notice this problem.
>
> Could you try renaming /etc/rcS.d/S22hwclockfirst.sh to
> /etc/rcS.d/S09hwclockfirst.sh and see if this addresses your problem?
>

Oops, I just realized, this won't work if /usr is a separately mounted
filesystem, since /etc/localtime is a typically a symlink to
/usr/share/zoneinfo/<timezome>, and at the time when the root
filesystem is checked, any other filesystems (such as possibly /usr)
won't be mounted yet.

      - Ted

On Sat December 17 2005 07:50 pm, Theodore Ts'o wrote:
> On Sat, Dec 17, 2005 at 07:45:42PM -0500, Theodore Ts'o wrote:
> > Sigh, I see what's going on. Unfortunately S22hwclockfirst.sh gets
> > done *after* S10checkroot. So the system time is still incorrect when
> > we check the root filesystem; it doesn't get adjusted to account for
> > the fact that you're using a non-GMT time until afterwards. I run
> > with my hardware clock set to UTC, so I didn't notice this problem.
> >
> > Could you try renaming /etc/rcS.d/S22hwclockfirst.sh to
> > /etc/rcS.d/S09hwclockfirst.sh and see if this addresses your problem?
>
> Oops, I just realized, this won't work if /usr is a separately mounted
> filesystem, since /etc/localtime is a typically a symlink to
> /usr/share/zoneinfo/<timezome>, and at the time when the root
> filesystem is checked, any other filesystems (such as possibly /usr)
> won't be mounted yet.

Actually, I don't have /usr as a separate partition. I just have two
partitions, one for / and one for /home. So I tried your suggestion.
Interestingly, I had two symlinks to two different scripts in /etc/rcS.d
which did the same thing. One was S22hwclock.sh and the other was
S18hwclockfirst.sh. They were exactly the same scripts. So, I removed the
symlink, S22hwclock.sh (as well as the script hwclock.sh in /etc/init.d). I
then changed the S18hwclockfirst.sh symlink to S09hwclockfirst.sh.

I then booted into Windows and then booted back into Debian Sid. Previously,
doing so would trigger the Superblock error on bootup. However, this time, no
error was triggered. Bootup went smoothly.

So, this workaround was perfect for me. However, it would seem that a more
general fix is necessary for others. I imagine this would mean having to
change the boot setup for Debian.

Rick

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

Download full text (7.2 KiB)

Source: e2fsprogs
Source-Version: 1.38+1.39-WIP-2005.12.10-2

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

comerr-dev_2.1-1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/comerr-dev_2.1-1.38+1.39-WIP-2005.12.10-2_i386.deb
e2fsck-static_1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/e2fsck-static_1.38+1.39-WIP-2005.12.10-2_i386.deb
e2fslibs-dev_1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/e2fslibs-dev_1.38+1.39-WIP-2005.12.10-2_i386.deb
e2fslibs_1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/e2fslibs_1.38+1.39-WIP-2005.12.10-2_i386.deb
e2fsprogs-udeb_1.38+1.39-WIP-2005.12.10-2_i386.udeb
  to pool/main/e/e2fsprogs/e2fsprogs-udeb_1.38+1.39-WIP-2005.12.10-2_i386.udeb
e2fsprogs_1.38+1.39-WIP-2005.12.10-2.diff.gz
  to pool/main/e/e2fsprogs/e2fsprogs_1.38+1.39-WIP-2005.12.10-2.diff.gz
e2fsprogs_1.38+1.39-WIP-2005.12.10-2.dsc
  to pool/main/e/e2fsprogs/e2fsprogs_1.38+1.39-WIP-2005.12.10-2.dsc
e2fsprogs_1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/e2fsprogs_1.38+1.39-WIP-2005.12.10-2_i386.deb
libblkid-dev_1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/libblkid-dev_1.38+1.39-WIP-2005.12.10-2_i386.deb
libblkid1-udeb_1.38+1.39-WIP-2005.12.10-2_i386.udeb
  to pool/main/e/e2fsprogs/libblkid1-udeb_1.38+1.39-WIP-2005.12.10-2_i386.udeb
libblkid1_1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/libblkid1_1.38+1.39-WIP-2005.12.10-2_i386.deb
libcomerr2_1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/libcomerr2_1.38+1.39-WIP-2005.12.10-2_i386.deb
libss2_1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/libss2_1.38+1.39-WIP-2005.12.10-2_i386.deb
libuuid1-udeb_1.38+1.39-WIP-2005.12.10-2_i386.udeb
  to pool/main/e/e2fsprogs/libuuid1-udeb_1.38+1.39-WIP-2005.12.10-2_i386.udeb
libuuid1_1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/libuuid1_1.38+1.39-WIP-2005.12.10-2_i386.deb
ss-dev_2.0-1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/ss-dev_2.0-1.38+1.39-WIP-2005.12.10-2_i386.deb
uuid-dev_1.2-1.38+1.39-WIP-2005.12.10-2_i386.deb
  to pool/main/e/e2fsprogs/uuid-dev_1.2-1.38+1.39-WIP-2005.12.10-2_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.
Theodore Y. Ts'o <email address hidden> (supplier of updated e2fsprogs 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: Sat, 31 Dec 2005 01:05:35 -0500
Source: e2fsprogs
Binary: e2fslibs-dev libblkid1-udeb libblkid1 comerr-dev libuuid1 ss-dev uuid-dev e2fslibs e2fsck-static e2fsprogs-udeb libuuid1-udeb e2fsprogs libblkid-dev libcomerr2 libss2
Architecture: source i386
Version: 1.38+1.39-WIP...

Read more...

Download full text (5.4 KiB)

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

Read more...

Download full text (7.5 KiB)

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

Read more...

Download full text (4.7 KiB)

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

Read more...

Package: e2fsprogs
Version: 1.38+1.39-WIP-2005.12.10-2
Followup-For: Bug #343645

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (750, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-ck6
Locale: LANG=fr_FR@euro, LC_CTYPE=fr_FR@euro (charmap=ISO-8859-15)

Versions of packages e2fsprogs depends on:
ii e2fslibs 1.38+1.39-WIP-2005.12.10-2 ext2 filesystem libraries
ii libblkid1 1.38+1.39-WIP-2005.12.10-2 block device id library
ii libc6 2.3.5-11 GNU C Library: Shared libraries an
ii libcomerr2 1.38+1.39-WIP-2005.12.10-2 common error description library
ii libss2 1.38+1.39-WIP-2005.12.10-2 command-line interface parsing lib
ii libuuid1 1.38+1.39-WIP-2005.12.10-2 universally unique id library

e2fsprogs recommends no packages.

-- no debconf information

I will make it short, I posted on debian-user-french to solve the
problem mentioned in the subject. It seemed to be a so strange
error ... I looked to the changelog.Debian.gz in /usr/share/doc and
also on http://bugs.debian.org to read the bug reports .

The error is following, sometimes , not all the time, at the end of the
boot process I get following error message : "/sbin/init : Cannot
execute binary file "
"Respawning too fast, disabled for five minutes"

I have to reboot, in recovery mode, to umount my / , and to do manually
#fsck /dev/hdb3 , then I get this error : Superblock last mount time is
in the future, fix it (Y)
After this I can boot without any problem.

The date & time on my system is set on Western time . /etc/default/rcS has the following line: UTC=no

How can I fix this ??

Thanks for all

Sorry for my english

mahashakti89

reassign 343645 initscripts
thanks

On Wed, Jan 04, 2006 at 09:52:39PM +0100, mahashakti89 wrote:
>
> I will make it short, I posted on debian-user-french to solve the
> problem mentioned in the subject. It seemed to be a so strange
> error ... I looked to the changelog.Debian.gz in /usr/share/doc and
> also on http://bugs.debian.org to read the bug reports .
>
> The error is following, sometimes , not all the time, at the end of the
> boot process I get following error message : "/sbin/init : Cannot
> execute binary file "
> "Respawning too fast, disabled for five minutes"

If this is happening all the time, and it's fixed by running by
running e2fsck, then you have something causing filesystem corruption
problems. This could be a hardware problem, or perhaps a buggy kernel
or a buggy device driver. It could also be a some kind of
configuration error. Is e2fsck actually giving you some kind of
filesystem corruption problem other than "superblock last mount time
is in the future?"

> I have to reboot, in recovery mode, to umount my / , and to do manually
> #fsck /dev/hdb3 , then I get this error : Superblock last mount time is
> in the future, fix it (Y)
> After this I can boot without any problem.
>
> The date & time on my system is set on Western time . /etc/default/rcS has the following line: UTC=no
>

This error is not an e2fsck bug, but a bug in the initscripts if you
use UTC=no. The problem is that the init scripts run a large portion
of the init scripts, including the initial e2fsck, with the wrong time
set. This is because /etc/localtime is a symlink to
/usr/share/zoneinfox/xxx, and /usr might not be mounted yet.

So if you use UTC=no, the system clock is set incorrectly until much
later in the boot process, thus triggering the e2fsck warning message.
It's harmless, and it's caused by this bug in the init scripts; e2fsck
requires that the time be correctly set when it is run.

What needs to happen with the init scripts is that the localtime
should be set in /etc/localtime.conf, and /etc/localtime should be a
copy of /usr/local/zoneinfo/`cat /etc/localtime.conf`; then the system
clock can be set correctly before e2fsck is run.

You can work around the problem by setting your hardware clock to UTC,
by setting /etc/default/rcS with the line: UTC=yes. The only reason
why this would be problematic is if you dual-boot Windows.

Regards,

      - Ted

clone 343645 -1
reassign -1 util-linux
retitle -1 util-linux: System time is not set correctly prior to root filesystem fsck
severity -1 serious
merge -1 342887
retitle 343645 initscripts: Please work around util-linux's broken clock-setting
severity 343645 wishlist
stop

Debian Bug Tracking System wrote:
> reassign 343645 initscripts

The hwclock initscripts are in the util-linux package. There is already a bug
report (#342887) open against util-linux pointing out that the S22hwclock.sh
script requires /usr but runs before /usr is mounted, with the result being that
the system time is not set correctly on some systems. The bug reported here is
related to that one, so I am merging a clone of this report to that one.

While I would hope that this problem would be fixed in util-linux, we should
consider working around the problem somehow in the initscripts package.
--
Thomas

reopen 346064
merge 346064 342887
reopen 343645
stop

clone 343645 -1
reassign -1 util-linux
retitle -1 util-linux: System time is not set correctly prior to root filesystem fsck
severity -1 serious
merge -1 342887
retitle 343645 initscripts: Please work around util-linux's broken clock-setting
severity 343645 wishlist
stop

Debian Bug Tracking System wrote:
> reassign 343645 initscripts

The hwclock initscripts are in the util-linux package. There is already a bug
report (#342887) open against util-linux pointing out that the S22hwclock.sh
script requires /usr but runs before /usr is mounted, with the result being that
the system time is not set correctly on some systems. The bug reported here is
related to that one, so I am merging a clone of this report to that one.

While I would hope that this problem would be fixed in util-linux, we should
consider working around the problem somehow in the initscripts package.
--
Thomas

_______________________________________________
Pkg-sysvinit-devel mailing list
<email address hidden>
http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel

tag 343645 wontfix
thanks

Please, no screwing with this glibc and util-linux issue.

It should be fixed by util-linux (patch 50% done by yours thruly), and
glibc. It is wontfix for initscripts. It is almost-pending for util-linux.
I have no idea if, after util-linux is fixed, glibc will do the right thing
and make sure /etc/localtime is always valid (bugs will need to be
reassigned to glibc, I don't think they have been notified yet.

/etc/localtime IS glibc's domain, as timezones and locales are their domain.
It should be kept up-to-date by tzconfig. It should be a copy of the
zonefile instead of a symlink. d-i probably has to be fixed to severely
discourage UTC=no and to also do copies, but that's something else.

I am against futher breakage on this issue by trying to work around it in
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

Henrique de Moraes Holschuh wrote:
> I am against futher breakage on this issue by trying to work around it in
> initscripts.

OK
--
Thomas

Hi LaMont!

On Thu, 05 Jan 2006, LaMont Jones wrote:

> On Thu, Jan 05, 2006 at 08:55:26AM -0200, Henrique de Moraes Holschuh wrote:
> > It should be fixed by util-linux (patch 50% done by yours thruly), and
> > glibc. It is wontfix for initscripts. It is almost-pending for util-linux.
> > I have no idea if, after util-linux is fixed, glibc will do the right thing
> > and make sure /etc/localtime is always valid (bugs will need to be
> > reassigned to glibc, I don't think they have been notified yet.
>
> What's the status of the patch, and can I get a copy of it?

I was trying to write one that did all in util-linux, but during that time
it become apparent that the fix needs to involve glibc and initscripts too
to be effective during DST.

I will send you a simple patch ASAP that just fixes things but requires the
user to manually edit the hwclockfirst.sh file and add TZ= something there,
and fix that manually for DST.

The full solution will (if approved by initscripts and glibc) have a working
/etc/localtime by the time hwclockfirst is run, so that TZ= will be
unneeded, and it will all work even during DST.

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

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

On Thu, Jan 05, 2006 at 04:50:24PM +0100, Henrique de Moraes Holschuh wrote:
> I was trying to write one that did all in util-linux, but during that time
> it become apparent that the fix needs to involve glibc and initscripts too
> to be effective during DST.

The patch was too simplistic to be of use anyway. Granted that it was
"tested lightly"...

I don't see any discussion on this thread that points out that modifying
the hardware clock from another system can make the Debian system unbootable
(until one waits for the future to arrive ;-).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

On Fri, 06 Jan 2006, Thomas Dickey wrote:
> On Thu, Jan 05, 2006 at 04:50:24PM +0100, Henrique de Moraes Holschuh wrote:
> > I was trying to write one that did all in util-linux, but during that time
> > it become apparent that the fix needs to involve glibc and initscripts too
> > to be effective during DST.
>
> The patch was too simplistic to be of use anyway. Granted that it was
> "tested lightly"...

Simplistic as in? What did it fail to do?

The whole fix involves a lot of crap that won't be done by util-linux, but
rather initscripts. The patch just fixes util-linux back to what it should
be doing.

> I don't see any discussion on this thread that points out that modifying
> the hardware clock from another system can make the Debian system unbootable
> (until one waits for the future to arrive ;-).

And you won't :-P We don't protect people from hanging themselves on
purpose. If you want to discuss that the test is completely stupid, or that
fsck is not repairing it correctly or in the desired way, you have to talk
to the e2fsck maintainer.

OTOH, a misshandled clock (as in we say we support it in local time but
really don't) is a bug no matter how we look at it, so even if e2fsck stops
caring about the system clock, we would still need to do something about
this issue at early boot anyway. Or drop the non-UTC support for the RTC.

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

On Fri, Jan 06, 2006 at 09:29:02AM -0200, Henrique de Moraes Holschuh wrote:
> On Fri, 06 Jan 2006, Thomas Dickey wrote:
> > On Thu, Jan 05, 2006 at 04:50:24PM +0100, Henrique de Moraes Holschuh wrote:
> > > I was trying to write one that did all in util-linux, but during that time
> > > it become apparent that the fix needs to involve glibc and initscripts too
> > > to be effective during DST.
> >
> > The patch was too simplistic to be of use anyway. Granted that it was
> > "tested lightly"...
>
> Simplistic as in? What did it fail to do?

It wasted my time.

bye

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

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

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

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

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.

Henrique de Moraes Holschuh asked:
> Simplistic as in? What did it fail to do?

Thomas E. Dickey replied:
> It wasted my time.

Who is wasting whose time? You make derogatory comments and then don't bother
to explain what you mean.

Back to your cave, troll!
--
Thomas Hood

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

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

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

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

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>

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

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

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

kko (kko) wrote :

If the system clock has been misadjusted while fsck last run, fsck reports on next boot that the partition "has gone 49710 days without being checked, check forced". Happens to me in Ubuntu after I do an occasional boot to a parallel partition if fsck gets run there.

This is clearly nonsense. A quick google of "fsck 49710" gives out numerous examples, revealing inter alia that 49710 days is close to 2^32 seconds, and gives a clear indication that fsck simply isn't equipped to deal with a misconfigured system clock.

In such a case fsck should only run if the filesystem was actually marked "dirty", i.e. not just because of the old timestamp. In addition, fsck probably could fix the timestamp.

The problem is annoying. It often occurs for me when I try to debug various system configuration issues (mainly X). Sometimes the system hangs, leading to a hard boot, leading to fsck, often leading to the further aggravation of unnecessary fsck checks due to a 136-year old timestamp.

Daniel Robitaille (robitaille) wrote :

it's not always 49710 days. I reported a similar bug last year
(bug 20104 ) where I had the same problem with a fsck checking my system after "49709 days". That bug report got rejected at the time by a Ubuntu developper ("system clock was set incorrectly")

Daniel Robitaille (robitaille) wrote :

Debian has a bug report open about fsck not automatically checking a disk if the date of the last check seems to be more than 10 years old (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344940)

kko (kko) wrote :

Even though it is considered bad form to confirm one's own bug reports, I am marking this confirmed (i.e. reproducible) based on Daniel R's comments.

Changed in e2fsprogs:
status: Unconfirmed → Confirmed

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

Download full text (3.2 KiB)

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

Read more...

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.

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?

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?

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?

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

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

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

Download full text (3.4 KiB)

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

Read more...

Andi T. (andreastetzlaff) wrote :

The problem still exists using Kubuntu 7.04 (Feisty Fawn) Beta x86 Desktop CD.

BIOS time/CMOS time is set to local time ("Berlin/Germany"). After booting the Desktop CD (the clock shows the correct local time) I started the Installation, chose Berlin/Germany in "step 2 of 6" and re-formatted the target root (/) directory.

When the installation finished and I rebooted my computer, it runs a filesystem check on my root (/) partition (/dev/sda6) because there had been no fsck since 49710 days.

Renzo Bagnati (renbag) wrote :

This happened to me also, after installing ubuntu 7.04 beta in an already partitioned hard drive (/dev/sda9, local time Rome/Italy).

Philip Wyett (philwyett) wrote :

I get this also when installing the 7.04 betas and the RC.

My system is set to the current time here in the UK. The live CD is booting -1 hour and during installation
it comes to current time. Upon reboot the system is forcing fsck because the timestamp for the last
mount is in the past.

Included is a dmesg of the system concerned for luck.

Philip Wyett (philwyett) wrote :

It seems the issue is that the installer is not correct. You set the time zone to London and you get BST+1, when really it should be GMT+1 I believe.

BST in the installer seems to be = GMT + 1 + 1

Happened to me also (Kubuntu 7.04 daily build 20070417). During the first boot fsck checked root partition and told me that it had found some errors and then rebooted my machine.

I had set my system to GMT+2 time zone.

Olli Rajala (olli-rajala) wrote :

Same here. GMT+2 time zone and Kubuntu 7.04 daily build 20070417. In my case it (fsck?) claimed that some time stamp was in the future, did some tweaking, rebooted computer and kubuntu started well.

Pascal Vandeputte (pascal-vdp) wrote :

Same here, same message and amount of days (it's /dev/sda6 in my case because that's where my root partition is). I'm dual-booting with XP and Vista but hadn't booted these since wiping Ubuntu 6.10.

This happened to me too, during the installation of ubuntu 7.04 final. On the first reboot after installation, fsck checked all my partitions (quite annoying in itself). Fsck reported "Superblock last mount time is in the future" on all partitions, and on /dev/sda9 I got the "has gone 49710 days without checking" error.

Pascal Vandeputte (pascal-vdp) wrote :

Update: when you boot Debian Etch for the first time, after installing it into /dev/sda3 on a system with Windows in /dev/sda1, you also get this fsck error. I've installed Etch numerous times on other (Linux-only) systems without any issues whatsoever.

Theodore Ts'o (tytso) wrote :

The fundamental bug here is in the init scripts. E2fsck assumes that the system time is correct. Unfortunately, if you have the system time set to tick localtime, instead of GMT, the Debian/Ubuntu boot scripts do not adjust for the fact that the hardware clock is not ticking UTC until after checking the root filesystem. This causes the "last checked" time to be writen out in the wrong time zone, and then if you reboot right away, it causes this problem.

In the latest versions of e2fsprogs, e2fsck will print a messaging that the clock is insane, and then check the filesystem since it could also be the case that the clock is insane. But the real, fundamental flaw is that the init scripts aren't correctly making sure that the system clock is accurately set before e2fsck is run.

Changed in e2fsprogs:
status: Confirmed → Invalid
Theodore Ts'o (tytso) wrote :

I started looking further on this issue, and it looks like it has been fixed in util-linux by making /etc/localtime a file, and by making sure the timezone is set correctly at boot time. See these debian bug reports:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343645
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342887

In any case, it's not an e2fsprogs issue. Time should be set correctly when e2fsck runs, gosh darn it!

Changed in sysvinit:
status: New → Invalid
kko (kko) wrote :

Thank you for looking into this.

"In the latest versions of e2fsprogs, e2fsck will print a messaging that the clock is insane, and then check the filesystem since it could also be the case that the clock is insane."

If I understand correctly, this should be sufficient to consider the originally reported issue "fixed" for e2fsprogs.

(It is beyond me why you marked this invalid, as you've actually implemented a check against an insane timestamp, which, essentially, this report was originally about - regardless of what actually caused the misadjusted timestamp. Knowing you're the one who wrote e2fsprogs, though, I won't question your decision here. ;-)

Then, as a separate issue, I definitely agree that a standard init process (without e.g. a parallel boot messing things up) shouldn't cause such conditions to occur, where fsck has to (unnecessarily) warn about an "insane clock" (even if the fsck now still runs). (You seem to indicate this has been fixed before you added the task for sysvinit, which would mean we can expect the fix to flow downstream to Ubuntu in due course.)

Tormod Volden (tormodvolden) wrote :

We have to keep one Ubuntu task open as long as the bug is not fixed in Ubuntu. Note that the Status of the (Ubuntu) tasks reflects the status in Ubuntu and not upstream. You can open (upstream) tasks which can have independent status.

If the e2fsprogs issue is fixed upstream, and we just wait for the fix to arrive in Ubuntu, someone should set it to "Won't Fix".

Changed in sysvinit:
status: Invalid → Confirmed
Theodore Ts'o (tytso) wrote :

Well, the problem is fundamentally more about the initscripts and util-linux than it is about e2fsprogs. The message printed by e2fsprogs will change, so that it says the time is in the future, as opposed to 49710 days. But the root cause of the bug really is the fact that the system clock is not set correctly at the time the root filesystem is checked. Even with the future version of e2fsprogs, if the time is incorrect, a filesystem check will be forced when it doesn't need to be, which is what users really complain about. Simply changing the message isn't going to keep users from getting upset (and they deserve to be).

I had thought the bug was fixed since util-linux moved the hwclock.sh to rcS.d/S8hwclock.sh in version 2.12r-13, and Feisty is using 2.12r-17ubuntu, but I see that upon closer inspection it looks like Feisty still has hwclock.sh started at S50 (and Debian still has it as S11 instead of S8, argh; so bug #342887 was inappropriately closed in Debian, sigh).

So I believe the correct answer at this point is that an Ubuntu task against util-linux needs to be kept open against the Ubuntu util-linux package, since that is where the correct patch should be applied. Does that sound right to you?

Tormod Volden (tormodvolden) wrote :

Thanks Theodore, that sounds good.

kko (kko) wrote :

Thank you again for the clarification. (And yes, you are correct in stating that the time it takes to run a filesystem check is what users will complain about.)

I am still unsure whether forcing a filesystem check when the timestamp is in the future is the desired action. As it is not my decision to make, I must trust your judgment in whether an unwarranted fsck can (could) be avoided in such a case.

Tormod Volden (tormodvolden) wrote :

In Gutsy, hwclock is started at S11, which in Ubuntu is after S10udev and before S20checkroot.sh, so this should be fine now. Please reopen if you can reproduce with Gutsy.

WRT to the question of fsck'ing if the timestamp is in the future: Then you know the clock is wrong, and you can not trust it, and you should fsck just to be sure.

Changed in util-linux:
status: Confirmed → Fix Released
Changed in e2fsprogs:
status: Unknown → Confirmed
Changed in util-linux:
status: Unknown → Fix Released
Changed in e2fsprogs:
status: Confirmed → Won't Fix
description: updated
Caracuri (caracuri) wrote :

also i have this problem with:
Linux notebook 2.6.31-9-generic #29-Ubuntu SMP Sun Aug 30 17:39:23 UTC 2009 i686 GNU/Linux

Ubuntu Karmic Koala

Tormod Volden (tormodvolden) wrote :

Yes, this can be different again now that the hwclock setting is done by a udev rule instead of an init script. Caracuri, can you please file a new bug, using "ubuntu-bug util-linux"?

Changed in e2fsprogs (Debian):
status: Won't Fix → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.