Re: fsck leaving / hosed (evbppc)??

[Rajasekhar Pulluru <pullururajasekhar%gmail.com@localhost>]

Hi Greg,

I am seeing fsck failures, but not exactly as yours. I was able to
mount the file-system
even after fsck failures.

I am using NetBSD5, and find that after unclean shutdown, fsck_msdos
-y fails for
a FAT file-system with two different error messages at different times as below:

Error 1)
/dev/ld0h: Cluster 368810 is marked free in FAT 0, but continues with cluster 36
8811 in FAT 1
This message goes on and on.

Error 2)
/dev/wd0e: Lost cluster chain at cluster 432395
13154 Cluster(s) lost
FIXED
/dev/wd0e: No LOST.DIR directory
/dev/wd0e: 165 files, 1429224 free (357306 clusters)

Could someone explain why fsck is not able to fix these errors?

Thanks & Regards,
Rajasekhar

On Thu, Aug 2, 2012 at 2:01 AM, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>
> (This is about evbppc, but I suspect it's more general.)
>
> I have some systems with a P2020 running netbsd-6 (not quite up to date,
> plus a lot of local changes).  They are mostly ok (hat tip to Matt for lots
> of stability fixes).
>
> root is on a USB2 disk.  There's an ext2 partition with the kernel
> (U-Boot lacks ffs support) and
>
> When the system boots after a clean shutdown, everything is normal.
>
> When booting after an unclean shutdown (our local changes have some
> issues), fsck runs and fixes a few things, and then we find that /
> appears to have vanished.  "ls" gets "not found", and "echo /*" takes a
> long time and prints nothing.  It seems that the in-core version of /
> has lots of null entries.
>
> "fsck -f -p" after a clean boot results in no issues.
>
> So, it seems that fsck does something to tell the kernel to reload the
> filesystem, and that's going horribly wrong.
>
> Has anyone else seen this?