> But the resulting fsck just doesn't work on symlinks. It says it
> expects a bunch of inodes - the first two of which appear
> to be symlinks -- are size 2 blocks and should be zero,
> and tries to correct them. This is clearly wrong: on 4.2 filesystems,
> the destination of a soft link is put into direct blocks.
> I believe that they're really two blocks --it's an 8k/1k filesystem,
> with DEV_BSIZE at 512 bytes. This has the really nasty effect
> that if one follow's Adam's suggestion on booting, the
> symlink  in /sbin from /init to /bin/init gets trashed..

umm, could you send the 'fsck -n' output to me?  it sounds like
something else is happening here, because i don't think i've
heard about this problem before, from people using 4.2FFS's...

For instance, it's unclear to me why fsck would claim the symlinks
were two blocks long; that's a pretty long symlink!

it sounds a bit fishy, to me...

> Some debugging shows that sblock.fs_maxsymlinklen was being set to -1,
> presumably from the superblock.

right.  that's because, in the 4.2 superblock, that field was unused
and thus set to -1.

> I tried the following (gross) patch,
> and it works for me.  Now I can safely, happily mount local
> filesystems read-write. Hooray!

Umm, "it might not work for you for too long."

If you fsck with that patch in, and a problem is corrected,
and the superblock is written out, the wrong data (i.e. 0, rather than
 -1) will be written out for the fs_maxsymlinklen field.  This won't
agree with the alternate superblock, and will probably cause
fsck to complain if you run it again...


chris

------------------------------------------------------------------------------