repeated fsck_ffs error: update

Polytropon freebsd at edvax.de
Thu Jan 1 13:25:09 UTC 2015


On Thu, 1 Jan 2015 13:00:18 +0000 (UTC), Thomas Mueller wrote:
> When rebooting, file system checks repaired root partition
> successfully, but I was unable to mount the desired home partition.

This indicates a still existing problem.



> My command was
> fsck_ffs -y /dev/gpt/Sea1-06
> 
> I ran it repeatedly (first without -y) and seemed to get partial
> fix, was able to mount read-only and rsync to another directory
> on another partition.

Very good. Could you already verify that the copied data
is complete?



> Latter part of message that came repeatedly, so there was no point
> in running fsck any more:
> 
> CYLINDER GROUP 356: BAD MAGIC NUMBER
> REBUILD CYLINDER GROUP? yes
> 
> CYLINDER GROUP 357: BAD MAGIC NUMBER
> REBUILD CYLINDER GROUP? yes
> 
> CYLINDER GROUP 358: BAD MAGIC NUMBER
> REBUILD CYLINDER GROUP? yes
> 
> CYLINDER GROUP 359: BAD MAGIC NUMBER
> REBUILD CYLINDER GROUP? yes
> 
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> UNREF FILE  I=3  OWNER=root MODE=100000
> SIZE=67108864 MTIME=Jun 24 04:22 2014 
> RECONNECT? yes
> 
> NO lost+found DIRECTORY
> CREATE? yes
> 
> CYLINDER GROUP 0: BAD MAGIC NUMBER
> REBUILD CYLINDER GROUP? yes
> 
> fsck_ffs: bad inode number 0 to ginode

Low inode numbers often correspond to "top-level" entries.
No root entry damaged?



> Now what is that last line about bad inode number 0 to ginode,
> and is there any way around?

Judging from /usr/src/sbin/fsck_ffs/inode.c:

        if (inumber < ROOTINO || inumber > maxino)
                errx(EEXIT, "bad inode number %d to ginode", inumber);

This error indicates a serious problem at the "top-level",
as I did assume. Somehow, fsck accesses the inode 0, which
as you can see is a problem.



> Do I need to reformat and rsync back?

This is probably the safest method, as it will make sure
the file system is properly constructed.



> I can also boot my NetBSD installation from last June
> (current, 6.99.44 amd64) and run NetBSD's fsck_ffs from there.
> 
> Even if that really messes up, I still have the rsync copy
> to rsync back from.

Very good.



> Update: I booted the NetBSD installation, ran 
> fsck_ffs -y /dev/dk5
> got the message that the filesystem was clean, no need to fsck.

You can always force a _full_ (!) check, see "man fsck_ffs"
for details. Use

	# fsck_ffs -yf /dev/dk5

or

	# fsck_ffs -yf /dev/gpt/Sea1-06

for this task. Perform the check in single-user mode, with
the partition not being mounted. Performing such a check is
never a bad idea. :-)






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


More information about the freebsd-questions mailing list