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.
On Fri, 6 Jan 2006 19:20:52 -0200
Henrique de Moraes Holschuh [EMAIL PROTECTED] 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'
On Sat, 07 Jan 2006, David E. Fox wrote:
'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
Is using UTC the last word for this problem? I must dual-boot with windows on
my machine.
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
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
Henrique de Moraes Holschuh wrote:
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
On Fri, 06 Jan 2006, Kent West wrote:
[ 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
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.
On Wed, 04 Jan 2006, Lei Kong wrote:
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.
None whatsoever, other than now your system is that
On Thu, 5 Jan 2006 08:59:24 -0200
Henrique de Moraes Holschuh [EMAIL PROTECTED] 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
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
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
On Wed, 4 Jan 2006 22:28:15 -0200
Henrique de Moraes Holschuh [EMAIL PROTECTED] 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
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?
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:
Brandon Simmons [EMAIL PROTECTED] writes:
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
16 matches
Mail list logo
