[Tfug] incorrect super block

[Shawn Nock]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

christopher floess wrote:
> Hi everyone, I'm trying to deal with what seems to be a corrupt
> super block. In FreeBSD when I issue
> 
> mount /dev/ad0s2c /mnt/chs

Fair warning, my BSD is a bit rusty, but... maybe this will get you
going in the right direction.

If you did disklabel the bios partition (not just putting UFS on the raw
bios partition) the command would be 'mount /dev/ad0s2a /mnt/chs' or
substitute b, d, e, f depending on how it was disklabeled.

'c' is used to integrate non-BSD slices into the BSD disk handling
methodology.

Every disk device has exactly four parts:
	bus type,number on bus,slice number,BSD partition in slice
	ad       0	       s2	    c

What 'c' implies is special, when the block device subsystem sees BSD
parition 'c' it knows that it should operate as though the slice (BIOS
partition) has the filesystem, not the third BSD partition in the slice.

You are certainly free to format the slice directly using newfs, but it
is not considered 'proper form'. However, if you were dual-booting
windows on the host and the bios partition was fat, this is the only way
to address this in FreeBSD. You cannot operate on ad0s2... ad0s2c
implies the same space.
	
> I get
> 
> mount: /dev/ad0s2c on /mnt/chs: incorrect super block.
> I have it partitioned as a ufs partition (165), of which other
> partions mount with this command.
> 
> Can someone help me fix this? Do I need to run disklabel,
> or newfs? Which one controls this?

So the idea is... if different systems support difference portioning
schemes... FreeBSD should abstract this by including (and enforcing) the
creation of a chunk of space that could be disklabeled into partitions
using a well known scheme. So, if freebsd can find the slice, all the
filesystems in the slice fall into line regardless of BIOS numbering, etc...

fdisk =
 create BIOS Partitions (BSD slices or fat partitions = s[x])
disklabel =
 define BSD partitions within BSD slices (create s[x]a(or b,d...)
newfs =
 create a filesystem on a partition (BSD or BIOS; format s[x]a as UFS)

> Actually if some one can point me to a good explanation
> of the partion process, I would really appreciate it. I've
> always had a hard time finding info on it. I understand the
> whole Unix/MS Partition/Slice thing, as well as the Unix
> partition/slice thing, but from what I can gather, the whole
> process of partitioning/slicing in unix goes

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-steps.html

> fdisk -> disklabel -> newfs
> 
> Is that right? What does each do? And how do I deal with
> rendering a specific slice that either has a corrupt super
> block, or I just want to convert from one thing to
> another?

Converting is not feasible... it doesn't have a solid meaning in this
context.

> Ok, a lot of questions here. Really, I just want to get my
> 177 gB of ad0s2 back

This clarifies things... it has mounted before. Could you post the
current disklabel and MBR partition list?

Superblocks are replicated often on the filesytem. fsck should know
where to find the backups... if you can direct it to the correct
partition. Try this first.

*Running newfs or disklabel willy-nilly will hose your data (or make
recovery more expensive). Don't do it, don't!.* newfs will overwrite all
of your superblocks...

If fsck fails (with unable to find superblock) it will require more
effort and reading through the on-disk format docs for the UFS2 fs.
Using the docs, search the hex dump of the first few hundred blocks for
'magic numbers' that appear in the superblock (I don't know the magic
numbers for UFS, google probably does). Find a backup superblock
(usually at block 160, but fsck will probably look here for you), give
the block number to fsck with the '-b [blocknum]'

If this fails, the voodoo shit will be required for recovery. The
expensive kind. I billed 2500 USD for a 36-hour gauntlet of digging 2TB
of ext3 out of a hosed lvm1 partition. Too bad all the money went into
the department coffers...

Anyway, this is long and ranty, try the fsck and/or post your disklabel
and Bios partition table.

Cheers,
Shawn

P.S. *DONT newfs or disklabel ad0s2c* you will regret it.

- --
Shawn Nock (OpenPGP: 0x3EA2777E)
Unix Systems Group; CCIT
University of Arizona
nock at email.arizona.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGnljIbbRzLz6id34RAluRAJ98YJQ57CxFvHPQRTQrYqACtjqk3gCfapF7
cp0iNBA6pdVKSSyVKqKorQc=
=Whel
-----END PGP SIGNATURE-----