Debian Etch netinstall all on an ext3 partition of slave disk. Two other installs on the machine, Sid with root on a reiserfs partition and its home on another ext3 partition of slave disk. And Windows XP on master disk FAT32. Windows does not (and I don't want it to!) see or touch my linuxes so it shouldn't be a factor with this problem.
I do have Sid mounting Etch's partition and vice versa automatically. Every 25 mounts or so when fsck goes off on etch's boot, it whines about the date of the superblock being in the future, fixes it and reboots. Then all is fine until the next scheduled fsck.
At first thought the clock on Sid must be fast or Etch slow but have tried various synching and not rebooting to Etch too quickly after having shutdown Sid. Doesn't help. Googling and a helper on another forum came across a previous bug:
Quote:
|
E2fsck will detect if the superblock's last mount field or last write field is in the future, and offer to fix if so. (Addresses Debian Bug #327580) These problems will be fixed automatically in preen mode since Debian's boot sequence bogusly doesn't set the time correctly until potentially very late in the bootup process, and this can cause false positives which will cause users' systems to fail to boot. (Addresses Debian Bugs #343662 and #343645)
|
It was supposed to have been fixed in e2fsprogs 1.38+1.39-WIP-2005.12-31-1 and I currently have version 1.39+1.40-WIP-2006.11.14+dfsg-1.
Any ideas? It just a bit of a nuisance since I use Sid as my main install that etch gets mounted quite a bit and so anytime I decide to boot the Etch install, fsck generally will be run since its been mounted so many times and I have to wait through a reboot after a fix.
