"superblock last write time is in the future" on boot
Brandon Simmons
After upgrading my system to 'testing', on bootup I am getting the error above
after "checking root filesystem..."; it then forces a reboot and fsck
on the next
boot. According to the Debian changelog for the e2fsprogs package, the newest
version checks for this, so I don't know whether e2fsprogs is mistaken or
whether there really is a problem. How would I go about checking this?
Thanks,
Brandon
Henrique de Moraes Holschuh
> boot. According to the Debian changelog for the e2fsprogs package, the newest
> version checks for this, so I don't know whether e2fsprogs is mistaken or
> whether there really is a problem. How would I go about checking this?
Short and to the point: stop using your RTC in local timezone mode.
Currently it simply cannot be as well supported as a RTC in UTC mode, and it
was never a sound engineering idea to begin with to have that in local time,
even back on the DOS days it was already broken by design.
Real fix: whatever you do, make sure /etc/localtime IS IN THE ROOT
FILESYSTEM (it is usually a symlink to /usr, and since you got the bug, your
/usr is probably a separate partition...).
Cosmetic fix: Edit hwclockfirst.sh and add right at the top of the file
TZ=TMP+200 (if your timezone is two hours less than UTC) or TZ=ABC-500 (if
it is five hours more than UTC). Move hwclock.sh in /etc/rcS.d to priority
36. Forget about getting it right for daylight savings, leap seconds and
any other advanced timezone stuff until after S35mountall has run, you'll
have to update that TZ= thing manually...
See tzset(3) for more information on TZ. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342887 for more details.
Note that glibc will have to change how they deal with /etc/localtime for a
proper fix to this one.
--
"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
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
John Fry
> After upgrading my system to 'testing', on bootup I am getting the
> error above after "checking root filesystem..."; it then forces a
> reboot and fsck on the next boot.
FWIW I found the error went away once I ran 'fsck -y' (more
specifically, when I set 'FSCKFIX=yes' in /etc/default/rcS).
John
Lei Kong
> On Tue, 03 Jan 2006, Brandon Simmons wrote:
> > boot. According to the Debian changelog for the e2fsprogs package, the newest
> > version checks for this, so I don't know whether e2fsprogs is mistaken or
> > whether there really is a problem. How would I go about checking this?
>
> Short and to the point: stop using your RTC in local timezone mode.
> Currently it simply cannot be as well supported as a RTC in UTC mode, and it
> was never a sound engineering idea to begin with to have that in local time,
> even back on the DOS days it was already broken by design.
>
> Real fix: whatever you do, make sure /etc/localtime IS IN THE ROOT
> FILESYSTEM (it is usually a symlink to /usr, and since you got the bug, your
> /usr is probably a separate partition...).
>
so this real fix is not a fix to me, :-(
>
> Cosmetic fix: Edit hwclockfirst.sh and add right at the top of the file
> TZ=TMP+200 (if your timezone is two hours less than UTC) or TZ=ABC-500 (if
> it is five hours more than UTC). Move hwclock.sh in /etc/rcS.d to priority
> 36. Forget about getting it right for daylight savings, leap seconds and
> any other advanced timezone stuff until after S35mountall has run, you'll
> have to update that TZ= thing manually...
>
> See tzset(3) for more information on TZ. See
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342887 for more details.
>
> Note that glibc will have to change how they deal with /etc/localtime for a
> proper fix to this one.
>
--
Henrique de Moraes Holschuh
> > On Tue, 03 Jan 2006, Brandon Simmons wrote:
> > > boot. According to the Debian changelog for the e2fsprogs package, the newest
> > > version checks for this, so I don't know whether e2fsprogs is mistaken or
> > > whether there really is a problem. How would I go about checking this?
> >
> > Short and to the point: stop using your RTC in local timezone mode.
> > Currently it simply cannot be as well supported as a RTC in UTC mode, and it
> > was never a sound engineering idea to begin with to have that in local time,
> > even back on the DOS days it was already broken by design.
> >
> > Real fix: whatever you do, make sure /etc/localtime IS IN THE ROOT
> > FILESYSTEM (it is usually a symlink to /usr, and since you got the bug, your
> > /usr is probably a separate partition...).
> >
> I don't have a seperate partition for /usr, and still I have this problem.
> so this real fix is not a fix to me, :-(
That's a very interesting datapoint. Does /etc/localtime point to a valid
file, and more important, to the file corresponding to the timezone your RTC
is in? Is UTF=yes set in /etc/default/rcS? Is your RTC in local time
instead of in UTC?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Andrew Sackville-West
Henrique de Moraes Holschuh <h...@debian.org> wrote:
> On Wed, 04 Jan 2006, Lei Kong wrote:
> > > On Tue, 03 Jan 2006, Brandon Simmons wrote:
> > > > boot. According to the Debian changelog for the e2fsprogs package, the newest
> > > > version checks for this, so I don't know whether e2fsprogs is mistaken or
> > > > whether there really is a problem. How would I go about checking this?
> > >
> > > Short and to the point: stop using your RTC in local timezone mode.
> > > Currently it simply cannot be as well supported as a RTC in UTC mode, and it
> > > was never a sound engineering idea to begin with to have that in local time,
> > > even back on the DOS days it was already broken by design.
> > >
> > > Real fix: whatever you do, make sure /etc/localtime IS IN THE ROOT
> > > FILESYSTEM (it is usually a symlink to /usr, and since you got the bug, your
> > > /usr is probably a separate partition...).
> > >
> > I don't have a seperate partition for /usr, and still I have this problem.
> > so this real fix is not a fix to me, :-(
>
> That's a very interesting datapoint. Does /etc/localtime point to a valid
> file, and more important, to the file corresponding to the timezone your RTC
> is in? Is UTF=yes set in /etc/default/rcS? Is your RTC in local time
> instead of in UTC?
I submitted a bug against e2fsprogs a couple weeks ago due to similar issues on boot up. the developer got right on it and apparently fixed it. Something to do with when debian sets the system clock as it relates to the fsck portion of boot. So, his solution was two fold. 1) fix the hardware clock to UTC and 2) upgrade to his latest package. don't know if its been committed yet or not and whether it'll trickle into testing soon or not, but thats my
.02
A
Lei Kong
> > > On Tue, 03 Jan 2006, Brandon Simmons wrote:
> > > > boot. According to the Debian changelog for the e2fsprogs package, the newest
> > > > version checks for this, so I don't know whether e2fsprogs is mistaken or
> > > > whether there really is a problem. How would I go about checking this?
> > >
> > > Short and to the point: stop using your RTC in local timezone mode.
> > > Currently it simply cannot be as well supported as a RTC in UTC mode, and it
> > > was never a sound engineering idea to begin with to have that in local time,
> > > even back on the DOS days it was already broken by design.
> > >
> > > Real fix: whatever you do, make sure /etc/localtime IS IN THE ROOT
> > > FILESYSTEM (it is usually a symlink to /usr, and since you got the bug, your
> > > /usr is probably a separate partition...).
> > >
> > I don't have a seperate partition for /usr, and still I have this problem.
> > so this real fix is not a fix to me, :-(
>
> That's a very interesting datapoint. Does /etc/localtime point to a valid
> file, and more important, to the file corresponding to the timezone your RTC
> is in? Is UTF=yes set in /etc/default/rcS? Is your RTC in local time
> instead of in UTC?
>
hardware clock store UTC time (UTF=yes in /etc/default/rcS).
Now, my question is, any drawback in doing so? besides possbile windows problem
on a dual boot machine and confusion when looking at bios.
thanks.
Lei Kong
Henrique de Moraes Holschuh
> I submitted a bug against e2fsprogs a couple weeks ago due to similar
> issues on boot up. the developer got right on it and apparently fixed it.
> Something to do with when debian sets the system clock as it relates to
> the fsck portion of boot. So, his solution was two fold. 1) fix the
> hardware clock to UTC and 2) upgrade to his latest package. don't know if
> its been committed yet or not and whether it'll trickle into testing soon
> or not, but thats my
This is caused by breakage in glibc and util-linux, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342887 for the *real* full
story.
e2fsprogs has no bug at all. I hope they did not make the matters worse
trying to work around it.
Henrique de Moraes Holschuh
> Now, my question is, any drawback in doing so? besides possbile windows problem
> on a dual boot machine and confusion when looking at bios.
None whatsoever, other than now your system is that much more resilitent
against breakage on these issues, and will never get its UTC clock wrong due
to daylight savings (the local timezone might still enter and leave DST
incorrectly, if it is not up-to-date).
--
"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
Andrew Sackville-West
Henrique de Moraes Holschuh <h...@debian.org> wrote:
> On Wed, 04 Jan 2006, Andrew Sackville-West wrote:
> > I submitted a bug against e2fsprogs a couple weeks ago due to similar
> > issues on boot up. the developer got right on it and apparently fixed it.
> > Something to do with when debian sets the system clock as it relates to
> > the fsck portion of boot. So, his solution was two fold. 1) fix the
> > hardware clock to UTC and 2) upgrade to his latest package. don't know if
> > its been committed yet or not and whether it'll trickle into testing soon
> > or not, but thats my
>
> This is caused by breakage in glibc and util-linux, see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342887 for the *real* full
> story.
>
> e2fsprogs has no bug at all. I hope they did not make the matters worse
> trying to work around it.
according to email from the developer, they did this:
* Deal with the fact that Debian's boot sequence bogusly doesn't set the
time correctly until very late in the boot process; so if the
superblock's last mount or write time is in the future, don't treat
this as a fatal error. (Closes: #343662, #343645)
so I doubt that it broke anything else in the workaround, but we'll see.
A
Ray Lanza
My linux configuration is relatively simple with everything on a single partition. Time zone is set properly, is not a symbolic link and is in the same filesystem as root.
I've noticed that when I have the system set for local time it reports a time that is really GMT.
Everything worked fine until the last time I updated (debian/testing).
thanks,
ray
Henrique de Moraes Holschuh
> Is using UTC the last word for this problem? I must dual-boot with windows on my machine.
No, of course not. It is the _easiest_ fix. It is becoming aparent that we
can do a much better fix in glibc, but I need to investigate more. And
there is always the workaround of setting TZ in /etc/init.d/hwclockfirst.sh
for the meanwhile.
> My linux configuration is relatively simple with everything on a single
> partition. Time zone is set properly, is not a symbolic link and is in the
> same filesystem as root.
So it should just work. Make sure /etc/default/rcS has UTC=no in it, and
that TZ is not set anywhere in the /etc/init.d/hwclock* scripts. Look at
what the system says while booting up, it will output the system time twice
(one for hwclockfirst.sh, the other for hwclock.sh). They must make sense
(also pay attention to the timezone it reports).
> I've noticed that when I have the system set for local time it reports a time that is really GMT.
"date -u" will tell you what the system thinks is the UTC time. If the
output is different from plain "date", then it certainly thinks it is in
some timezone.
> Everything worked fine until the last time I updated (debian/testing).
The current bugs in util-linux should not matter much if /usr is in the same
partition as /, so we will need a bit more info to help you.
--
"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
Kent West
>On Fri, 06 Jan 2006, Ray Lanza wrote:
>
>
>>Is using UTC the last word for this problem? I must dual-boot with windows on my machine.
>>
>>
>
>No, of course not. It is the _easiest_ fix. It is becoming aparent that we
>can do a much better fix in glibc, but I need to investigate more. And
>there is always the workaround of setting TZ in /etc/init.d/hwclockfirst.sh
>for the meanwhile.
>
>
It seems like I had this on a newly-installed Sid box the other day.
After I installed "ntpdate" the problem went away (but I was fighting
several problems at once, so no guarantees that this had any relevance).
--
Kent
.
Henrique de Moraes Holschuh
[ root fsck problem caused by time skew ]
> It seems like I had this on a newly-installed Sid box the other day.
> After I installed "ntpdate" the problem went away (but I was fighting
> several problems at once, so no guarantees that this had any relevance).
I like that check even less day after day...
The fix to what you describe (assuming it is not caused by a local time RTC
plus util-linux bug plus /etc/localtime being a dangling symlink) is to have
d-i set the system clock properly BEFORE it starts mucking with filesystems.
--
"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
David E. Fox
Henrique de Moraes Holschuh <h...@debian.org> wrote:
>
> "date -u" will tell you what the system thinks is the UTC time. If the
> output is different from plain "date", then it certainly thinks it is in
> some timezone.
I'm also running testing. I've noted that 'date' is correct for PST,
'date -u' is correct (UTC), dates are set coorectly in the filesystem
for instance but the log entries are in UTC. That doesn't match the
behavior in sarge.
--
------------------------------------------------------------------------
David E. Fox Thanks for letting me
df...@tsoft.com change magnetic patterns
df...@m206-157.dsl.tsoft.com on your hard disk.
-----------------------------------------------------------------------
Henrique de Moraes Holschuh
> 'date -u' is correct (UTC), dates are set coorectly in the filesystem
> for instance but the log entries are in UTC. That doesn't match the
> behavior in sarge.
It doesn't match the behaviour in my sid system either (where it logs in
local time).
It is likely that you have some sort of conguration problem. Unless, of
course, for some reason the programs doing the logging are being started
with invalid timezone information (if it is that, a restart should fix the
problem -- check that).
Check for anything setting TZ. If you set TZ to an invalid value, all
programs with that broken TZ setting in the environment will run in UTC.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Z F
The problem is that the newest version of e2fsprogs fixed some problems
which revealed new ones. It has to do with the fact that the local time
is set after the disk is mounted. So if you clock is not on UT, you are
in
trouble. Thre possibilities to fix:
1. downgrade e2fsprogs (and e2fslibs)
2. set hardware clock to UT and change /etc/defaut/rcS so that
system know that hardware clock is on UT
3. change the boot sequence by modifying symbolic links from
/ets/init.d/ to /etc/rc? so that the clock is set before
the partitions are mounted (I do not think this will work for root
partition thogh)
Lazar
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com