Re: fsck leaving / hosed (evbppc)??

[Frank Kastenholz <fkastenholz%verizon.net@localhost>]

Some additional information on this issue...

This problem occurs when the processor is big-endian and the file system is 
little-endian.
Things go bad in the mount() call in fsck_ffs/main.c.  Just prior to the call, 
I open() and then fstat()  
the root directory.  The block count for the directory is 4.  After the mount() 
I do the same thing, 
67108864 (or 0x04000000).  Doing an opendir()/readdir() loop before the mount() 
produces
the expected results. After the mount() the loop produces lots of garbage

Further, when I converted the file system to big endian and conducted the same 
tests (the
operations that caused trouble, the fsck with added information, etc) 
everything worked fine

Thanks
Frank Kastenholz
BBN Technologies



On Aug 1, 2012, at 4:31 PM, 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?