Date: Mon, 17 Sep 2001 21:13:27 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Aram Khalili <aram@cs.umd.edu> Cc: freebsd-questions@freebsd.org Subject: Re: corrupted superblock/fsck problem Message-ID: <200109172113.aa21589@salmon.maths.tcd.ie> In-Reply-To: Your message of "Mon, 17 Sep 2001 15:12:03 EDT." <Pine.SOL.4.21.0109171455570.4082-100000@toblerone.cs.umd.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.SOL.4.21.0109171455570.4082-100000@toblerone.cs.umd.edu>, Aram Khalili writes: >I run FreeBSD on an IBM T20 and I recently had a corrupted superblock on >my /home filesystem. It would boot, and suggested I run fsck manually. I >did that, and it would say that my superblock values are corrupted and >exit. So I looked at the man page, ran fsck -p and got the same result. >Then I ran fsck -p -b 32, and that fixed some things, and subsequent runs >of fsck -p -b 32 ran clean, however subsequent fsck -p runs still gave >corrupted values and exited, and it still wouldn't boot. Why does fsck >not copy the fixed superblock onto the 1st (0th) superblock? Fsck's error messages aren't exactly accurate here - when fsck says VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE it actually means that the very last superblock in the filesystem does not match the master superblock. Maybe you have partitions that overlap, and the end of this partition got clobbered? If fsck finishes successfully using "fsck -b 32" (i.e. you are satisfied that the master superblock is intact), then the tunefs program can be used to rewrite all the secondary superblocks: tunefs -A /dev/whatever Fsck never attempts to change the backup superblocks itself. These are written when the filesystem is first created and they are not modified by the kernel, so there should never be a need for them to be updated. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200109172113.aa21589>