Puppy 3.01 e2fsck errors

[maddox]

Hi,
I'm running Toutou 2.17 (puppy 2.17+X french translation) full install on hda3 (ext3 partition)
No probs there, I put in Puppy-live-cd 3.01, boot with pfix=ram..
- mount hda3 with mut to copy a file from puppy to Toutou, unmount hda3 with "mut"
- from rxtv run e2fsck -n /dev/hda3 reports "clean"
+-15 min later (still running puppy),
I remount hda3 (mut) to copy a new file, and unmount with (mut).
- from rxtv run e2fsck -n /dev/hda3 reports :
Toutou-217+X has gone 49710 days without being checked, check forced.

anybody got an idea about incorrect number of days between checks
as it was only about 15 mins between "e2fsck" runs ..
and if i do my maths + 139 years, or the year is incorrectly interpreted, or completely ignored.

----edit------
Ok here's a bit more info,
Puppy 2.17 uses "e2fsck" ver 1.38 (30-Jun-2005)
Puppy 3.01 uses "e2fsck" ver 1.39 (29-May-2006)
ver 1.39 says superblock last mount & write time is in the future.
That explains the strange day-count in this post.
But why does it think the filesystem is in the future ???
Does anybody know something about this error... ???

maddox

[PaulBx1]

All I can think of, is did you wait until the umount finished before doing the fsck? If you were copying a large file, sometimes it takes a while before the umount is done...

[maddox]

hi PaulBx1,
no, it was a 1K text file.
I just don't get why it reports so many days into the futur/past...
just as well the filesystem stayed "clean", using the puppy 3.01 live-cd
could the time format 12h / 24hr have something to do with it ????
or the fact that it's a french version, doubt that though..
I'm at a loss really, but willing to experiment if you guy's have any ideas..
maddox

[maddox]

Found out that I don't actually have to mount the 2.17 (ext3) partition to get the e2fsck error,
I just run the check after starting Puppy 3.01 live-cd.
I get the same strange superblock futur error.
But if I mount & transfer a small text file, unmount, then check, there are other errors.
I just ran into this.. Puppy 3.01 Beta
Certainly a quirk between the e2fsck versions,
which one to rely upon : version 1.38 or 1.39 ?
maddox

[maddox]

Actually it seems that version 1.38 is wrong (puppy 2.17)
rebooted with 2.17 live-cd, pfix=nox,ram, e2fsck -n /dev/hda3 gives errors
so 2.17 doesn't cleanly unmount the file-system upon shutdown.
wrong free blocks, dtime files.
tried copying the 1.39 ver to my full install, complains about :
ext2 library version out of date

--edited---
will keep trying, that's really part of learning and wanting knowledge.
Pretty sure it's a lot harder for the guys behind the puppy project.
-----end of edit--------

maddox

[Flash]

Oh, don't get discouraged and quit so easily. As for deleting this thread, I don't think so. You never know if a thread will turn out to be useful to someone, or who is reading your thread. You may have started someone working on a solution but he's too busy to talk. Have patience and keep plugging. That's the Puppy way.

[maddox]

Have had no Internet connection for 28 hrs, a bummer.
while running 2.17 I replaced e2fsck prog + lib to ver 1.39, rebooted.
3.01 live-cd pfix=nox,ram -> e2fsck -n /dev/hda3
"superblock in the futur + inode 44471 zero dtime".
fixed error, then rebooted into 2.17 -> /var/log/messages : no EXT3 error.!!
This was the only time I saw the filesystem clean in -> /var/log/messages
On next 2.17 reboot (with e2fsck 1.39), /var/log/messages : EXT3-fs recovery required on readonly filesystem.
I did get once, (while booting 2.17) and just after message "loading kernel modules"
and endless loop of the same messages on the console "rec ....44473"
flying by so fast, you can't read them...
nothing would stop it, but a brutal pull the plug.
Booted the 3.01 live-cd pfix=nox,ram -> e2fsck -n /dev/hda3
"superblock in the futur
pass 1 : inode 44471 zero dtime".
pass 5 : inode bitmap dif -44471
fixed errors, then rebooted into 2.17
X didn't start, just a prompt, -> xwin , error last time X booted...
xwin again -> X started, all seemed OK
Checked /var/log/messages, all the usual boot info wasn't in there
daemon.info init: ^MThe system is going down NOW !!
daemon.info init: ^MSending SIGTERM to all processes.
syslog.info System log daemon exiting.
syslog.info syslogd started: BusyBox v1.01
next line was adding swap

But the "inode 44471 zero dtime" has disapeared, and never came back using ver 1.39.
Still get the superblock futur, bla-bla

in rc.shutdown :
Tried adding sync and sleep 2 before swapoff -a , no diff.
and added sleep 3 just after "busybox umount -ar"

Sync doesn't seem to do exactly what it should, especially when shutting down.
the more sync's i add, the worse it gets.

Wondering a few things, either sync, e2fs prog (part of busybox) are at fault ?
- as i'm still getting superblock futur errors (ver 1.38 or ver 1.39).
Wondering also that maybe the filesystem shuts down OK,
BUT the restart/mount is at fault ?

I'd love to be a Puppy/linux mechanic, but I don't have the skills.

maddox

[maddox]

btw,
does /var/log/messages have a size/line limit,
because on reboot, and bringing up the usb wifi stick,
new lines were added to the begining of the file
but only after the file reached line 256.
(using geany + display line nbers)

maddox

[maddox]

Ok a bit more info,
the only way, just using puppy, to get a (one-time) clean filesystem
under 2.17 (running e2fsck 1.39),
is to use a puppy live-cd using the same e2fsck ver 1.39 :
booting live-cd, running e2fsck, fixing the errors, and rebooting, isn't enough.
you have to access and copy/create a file in the mounted filesystem
for the 2 block error to disappear.

one-time clean filesystem howto :
boot live-cd using e2fsck 1.39 (pfix=nox,ram or pfix=ram)
run e2fsck" on 2.17 full-install to fix 2 block error,
mount 2.17 filesystem, copy/create a small file,
unmount 2.17 filesystem, then reboot 2.17 full-install
/var/log/messages contains NO ext3 errors

so it's by fixing and creating a new file on the mounted filesystem
that the 2 block error disappears,
and also using a different puppy version to fix the error.
But this works only once !

What I've got :
- added sleep 3 in rc.shutdown, don't have superblock futur error anymore.
- using the same e2fsck version 1.39
- newer puppy version to fix e2fsck error
- same 2 free block error (this IS constant, and seems the problem ! )
- must mount and copy/create a file on 2.17 filesystem
- unmount filesystem
- reboot
no ext3 errors, but only until next 2.17 or later puppy live-cd reboot.

go figure that out, so e2fsck is NOT at fault.
- Live-cd shuts down correctly, but doesn't access the file-system
- Seems to rule out the starting of 2.17 prob,
as /var/log/messages has NO ext3 errors.

Comes back to the 2.17 shutting down prob.

maddox

[Bruce B]

After making a filesystem some distros think you haven't checked the filesystem since Moses was alive, then they force a full check on you.

For me it only happens one time per new partition.

Just for the record, Puppy's e2fsck and fsck are not at all the same programs.

[JustGreg]

I am posting because I noticed similar results with Puppy 3.01 and fsck (1.39) and e2fsck (1.39). Here is what I got:

e2fsck 1.39 (29-May-2006)
/dev/hda3 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 1030181 has zero dtime. Fix? yes
Deleted inode 1030238 has zero dtime. Fix? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(2064913--2064914)
Fix? yes
Free blocks count wrong for group #63 (31855, counted=31857).
Fix? yes
Free blocks count wrong (5270860, counted=5270862).
Fix? yes
Inode bitmap differences: -1030181 -1030238
Fix? yes
Free inodes count wrong for group #63 (16266, counted=16268).
Fix? yes
Directories count wrong for group #63 (24, counted=22).
Fix? yes
Free inodes count wrong (2697676, counted=2697678).
Fix? yes
/dev/hda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda3: 402/2698080 files (1.2% non-contiguous), 116937/5387799 blocks

I did noticed when I was running Dingo and did mount (no parameters) in console to get a list of devices mounted that /dev/hda3 was not listed. Could this be the source of the e2fsck results? I know Puppy mounts the save device when it shutdowns to save the changes. Maybe the save process does not umount the device correctly?

If anyone knows the script that does the saving during shutdown, please tell me. I will look at it. I can not say that I will be able to fix the problem, but I will try.

I hope this helps.

[maddox]

hi JustGreg,
Puppy 2.17 and 3.01 shutdown script is /etc/rc.d/rc.shutdown
It does the CD/ DVD, HD, USB backup/create pup-save.sfs of the live-cd session.
Haven't tried Dingo yet, so I can't give any info about that.
maddox

[JustGreg]

Thanks for the information. I will take a look.

[JustGreg]

I have been experimenting with my test Dingo alpha2 install. I checked /etc/rc,d/shutdown.rc for the umount commands. I thought I may found something. One of the umount is a "lazy" umount (-l option). A lazy umount detaches the filesystem from the hierarchy immediately, but don't clean up references until it is no longer busy. I eliminated -l option from the line and added a "sleep 10" after the modified umount command. It did not correct the problem.

I did notice in running e2fsk, the same block inode (Deleted inode 1030181 has zero dtime. Fix? yes) kept having a problem that needed to be fix.

I also tried changing from a "save to partition" to a normal frugal pup_save.2fs save. After doing some minor copying and deleting. I rebooted and check with e2fsck (puppy 3.01) the dingo save file, pup_save.2fs. e2fsck reported similar problems.

I have a Puppy 2.17 frugal save to partition install that works fine. However, checking with a CDROM with Puppy 2.16 (pfix=ram) shows it has the same types of problem when e2fsc is run.

I hope this helps in some way.

[maddox]

Hi JustGreg,
did you try, start live-cd then :
1: check for errors with e2fsck -n
2: correct the errors with e2fsck -fvy
3: mount the file-sys and create/modify a small 1K file.
4: unmount the file-sys
5: reboot, and check for clean file-sys in /var/log/messages or /tmp/bootkernel.log.
-------------------------------------------
well, what i've noticed is that (using my 2.17 full install),
when I delete a bunch of files or a directory with some files,
then reboot with 3.01 live-cd, I get more than just the 2 block error !
The free block count is way off and inode errors,
which seem to correspond to the nber of files/directory-files I deleted.
If I happen to wait a while, do other stuff +- 15-20 min,
and NO big transfering/deleting before I shutdown/reboot
Only a 2 block error.
Back to square one, this is worse than sudoku without glasses.

Maybe someone, could point out the Puppy shutdown file-system process,
and the following reboot/check mount process.
just even a link to relevant info would be nice.

maddox

[JustGreg]

maddox,

After the cdrom Puppy 2.16 started, I used e2fsk -y /dev/hda# to check the particular installation. In testing each of the installations, I opened geany and wrote a line or two of text and then save it to my-documents in root. I deleted the file and then rebooted. I have checked with the cdrom Puppy 2.16 (it is the oldest version I have available now). I will try the process you posted above. I will post the results for each.

[maddox]

hi JustGreg,
could you try the process, but don't delete the file before rebooting,
and thanks for your time.
maddox

[JustGreg]

Here are the results, maddox:

First using Puppy 2.16 CDROM, check the three installs, Puppy 3.01 full hard drive, Dingo alpha 2 frugal with pup_save.2fs and Puppy 2.17 frugal save to partition. Using Puppy 2.16 e2fsck, Puppy 3.01 had pass 5 inode count errors. For Puppy 2.17, e2fsck reported clean since it had not been used. Dingo alpha 2 was clean since it had not been used. But the save file for Dingo had the date problem. Fix any problems found.

I copied and then deleted (sorry about that) a small file (2600 bytes) using Puppy 2.16 to each file system when mounted. Rebooted

For Puppy 3.01, nothing was noted in bootkernel.log or messages. For Puppy 2.17, bootkernel.log had EXT2-fs warning about unchecked fs mounting. Dingo alpha2 had same bootkernel.log warning about unchecked fs mounting. Rebooted to the Puppy 2.16 CDROM.

Did a e2sck -n on each installation. For Puppy 3.01, e2fsck reported not cleanly unmounted, but no specific errors reported. The Puppy 2.17 errors were Pass 1 zero dtime and Pass 5 Block Bitmap differences. Dingo alpha save file has the same Pass 1 and Pass 5 errors as Puppy 2.17.

It seems the full hard disk installation is just not unmounted properly. The frugal installs seem to have more errors. If you want, I can delete the Dingo alpha 2 frugal installation and do a full partition install to see what happens.

I will retry with just copying and post the results.

[JustGreg]

Here are the results for copy only, maddox:

First using Puppy 2.16 CDROM, check the three installs, Puppy 3.01 full hard drive, Dingo alpha 2 frugal with pup_save.2fs and Puppy 2.17 frugal save to partition. Using Puppy 2.16 e2fsck, Puppy 3.01 had pass 5 inode count errors (same as last time). For Puppy 2.17, e2fsck reported clean since it had not been used. Dingo alpha 2 was clean since it had not been used. The Dingo save file had no errors. Fix any problems found.

I copied a small file (2600 bytes) using Puppy 2.16 to each file system when mounted. Rebooted

For Puppy 3.01, nothing was noted in bootkernel.log or messages. For Puppy 2.17, bootkernel.log had EXT2-fs warning about unchecked fs mounting. Dingo alpha2 had same bootkernel.log warning about unchecked fs mounting. Rebooted to the Puppy 2.16 CDROM.

Did a e2sck -n on each installation. For Puppy 3.01, e2fsck reported not cleanly unmounted, but no specific errors reported. The Puppy 2.17 errors were Pass 1 zero dtime and Pass 5 Block multiple types of errors. Dingo alpha save file has the same Pass 1 and Pass 5 errors as Puppy 2.17.

If you want, I can delete the Dingo alpha 2 frugal installation and do a full partition install to see what happens. However, I will not get to it today.

[maddox]

Hi JustGreg, thanks for your input and effort
I'm going to let this sink in for a day or 2, and try to find a bit more info.
Seem to be going round in circles, can't really pinpoint the exact prob/fault here,
already sent an email to colombo and monk...
I'll try further testing on 3.01, also check out Dingo, as it's a back to the roots version.
maddox