I looked at the checkfs scripts and the various forum posts to see if I can find any indication what causes this problem and also I tried to reproduce this on a vmware image without success so far.
If someone is still affected by this problem I would really appreciate the output of:
$ cat /var/log/fsck/*
$ sudo tune2fs -l /dev/-insert-devices-here-
$ date
and the BIOS date settings.
The puzzeling thing is that on the systems I have at hand the "check interval is unset:
Check interval: 0 (<none>)
This means that it shouldn't do this check even if the clock is off a lot. Debian sets this interval to 6 month, but for ext3 we haven't been using this neither in edgy nor dapper (according to my checks on fresh installs).
If I run tune2fs -i and give it a different value than 0 I can easily reproduce the problem with a incorrect clock setting (as expected).
I would really appreciate the logs from someone affected by this bug.
I looked at the checkfs scripts and the various forum posts to see if I can find any indication what causes this problem and also I tried to reproduce this on a vmware image without success so far.
If someone is still affected by this problem I would really appreciate the output of: devices- here-
$ cat /var/log/fsck/*
$ sudo tune2fs -l /dev/-insert-
$ date
and the BIOS date settings.
The puzzeling thing is that on the systems I have at hand the "check interval is unset:
Check interval: 0 (<none>)
This means that it shouldn't do this check even if the clock is off a lot. Debian sets this interval to 6 month, but for ext3 we haven't been using this neither in edgy nor dapper (according to my checks on fresh installs).
If I run tune2fs -i and give it a different value than 0 I can easily reproduce the problem with a incorrect clock setting (as expected).
I would really appreciate the logs from someone affected by this bug.
Thanks,
Michael