Power failure during portsnap fetch update

[Polytropon]

On Sat, 21 Jul 2012 16:38:02 +0200, Leslie Jensen wrote:
> 
> My file system /usr/ports/net go damaged
> 
> I've done fsck -F in single user mode but there are warnings about not 
> being able to fix this.

First of all, you should give fsck a second try. Check the
damaged partition per "fsck -y /dev/ad0s1f" (which refers
to that partition, e. g. /usr).



> The directories below cannot be removed

That indicates a major file system defect.



> How do I go about this?

There is a nice tool in the base system: clri (clear inode).
Please note that you're going to "get your hands dirty"
with this approach!

First, determine the inodes of the "offending" directories.
Use "ls -ldi" to do this.

Example:

# cd /usr/ports/net
# ls -ldi ccxstream netselect spread vde2
288794 drwxr-xr-x  3 root  wheel  512 2011-08-21 03:14:43 ccxstream/
331753 drwxr-xr-x  3 root  wheel  512 2011-08-21 03:16:10 netselect/
424004 drwxr-xr-x  3 root  wheel  512 2011-08-21 03:17:50 spread/
424104 drwxr-xr-x  2 root  wheel  512 2011-08-21 03:18:04 vde2/

Alternative: You can also use "stat" to obtain information
about a file (and a directory) and its "health".

Example:

# cd /usr/ports/net
# stat ccxstream netselect spread vde2
120 288794 drwxr-xr-x 3 root wheel 1139829 512 "Jul 21 16:46:35 2012" "Aug 21 03:14:43 2011" "Aug 21 03:14:43 2011" "Feb 18 02:04:47 2011" 16384 4 0 ccxstream
120 331753 drwxr-xr-x 3 root wheel 1325518 512 "Jul 21 16:46:35 2012" "Aug 21 03:16:10 2011" "Aug 21 03:16:10 2011" "Feb 18 02:04:58 2011" 16384 4 0 netselect
120 424004 drwxr-xr-x 3 root wheel 1696620 512 "Jul 21 16:46:35 2012" "Aug 21 03:17:50 2011" "Aug 21 03:17:50 2011" "Feb 18 02:05:15 2011" 16384 4 0 spread
120 424104 drwxr-xr-x 2 root wheel 1696720 512 "Jul 21 16:46:35 2012" "Aug 21 03:18:04 2011" "Aug 21 03:18:04 2011" "Feb 18 02:05:18 2011" 16384 4 0 vde2

You recognize the inode numbers here. Write down the inode numbers
or store them in a temporary file. You can script this process if
you like. :-)

Then "go out of" the partition and unmount it. You are safer
if you apply clri to an UNMOUNTED partition.

Then, for example, do this:

# clri /dev/ad0s1f 288794
# clri /dev/ad0s1f 331753
# clri /dev/ad0s1f 424004
# clri /dev/ad0s1f 424104

Note that this directly modifies "file system bowels" of the
/usr partition! When done, apply fsck again:

# fsck -yf /dev/ad0s1f

Maybe fsck finds some errors in inode construction and will
therefore recover "lost data" (which we will accept as irrelevant
at this point) into the lost+found/ root directory on that
partition. You can remove its content later on.

If fsck finishes with success, you should be able to mount the
/usr partition again. Of course, some subdirecories in the
ports tree are now missing, but that has been inteneded.

Side note:

You can use the program "fsdb" to investigate inode information
in detail. See "man fsdb" and "man clri" for details.



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...