This is very common and is (mostly) harmless.Every time the system boots, it reports that the file was not cleanly unmounted, and does a repair
ext3 and ext4 have journals and a file system check works much faster (almost instantaneously) than ext2.
If fsck does a repair, it is often just releasing an inode and freeing the blocks belonging to the inode. If a file was deleted (the file name was removed from the dictionary) but the inode was still in the dictionary and the blocks still associated with the inode because something was still accessing that file, it can cause this to happen.
Puppy first copies the kernel vmlinuz into ram memory and starts executing the instructions in ram, which then copies initrd to ram (that is, the initial ram drive) and starts executing it. This is before the Puppy sfs files are found and mounted and before your save file is found and mounted.the time stamp is in the future
The init script in the initrd file does this:
Code: Select all
[ "$TZ" ] && export TZ
hwclock -l -s
The -l hwclock option tells it to use local time, but at this point, Puppy does not know your time zone. So the system time may not agree with the time stamps in the file system you are checking.
You can add the parameter TZ to your kernel boot parameters, for example:
Code: Select all
... pfix=ram TZ=EST5EDT ...
You should not fsck a savefile that is being used by a running Puppy, it can corrupt it. You can force a fsck with the -f option, for example:
Code: Select all
fsck.ext2 -vf savefile.2fs