FSCK Bad Superblock?

you can try re-writing the file system with "newfs" in terminal or "tunefs." Both may require a unmounted unbooted file system to work.

note - I've never seen the error in OS X and never used the above commands.

I would first try using DiskWarrior on your drive to see if that fixes things before trying either tunefs or newfs.

Hello Kayjon - is this still an active problem?  Are you still stymied by it or have you found a solution?  I'd be willing to give you my thoughts if this issue is still around.

I have this issue with a Firewire daa drive (non-boot)
when I run
 bash :~ sudo mount /dev/disk1s14 /mnt
I get
/dev/disk1s14 on /mnt: Incorrect super block.

Ant way to replace the super block?

- jd

Hmm. Thanks for the info.
Tried what you suggested,

guests-Computer:~ root# newfs  -N /dev/disk1s14
Warning: Block size and bytes per inode restrict cylinders per group to 4.
Warning: inode blocks/cyl group (975) >= data blocks (519) in last
    cylinder group. This implies 4152 sector(s) cannot be allocated.
disk1s14:       57022080 sectors in 6988 cylinders of 255 tracks, 32 sectors
        27842.8MB in 1747 cyl groups (4 c/g, 15.94MB/g, 3968 i/g)
super-block backups (for fsck -b #) at:
 32, 32704, 65376, 98048, 130720, 163392, 196064, 228736,
 261408, 294080, 326752, 359424, 392096, 424768, 457440, 490112,
 522784, 555456, 588128, 620800, 653472, 686144, 718816, 751488,
 784160, 816832, 849504, 882176, 914848, 947520, 980192, 1012864,
 1045536, 1078208, 1110880, 1143552, 1176224, 1208896, 1241568, 1274240, ... snip ...

guests-Computer:~ root# fsck -b 32704 /dev/disk1s14
Alternate super block location: 32704
** /dev/rdisk1s14
BAD SUPER BLOCK: MAGIC NUMBER WRONG
guests-Computer:~ root#

So, what does the "MAGIC NUMBER WRONG" mean, and what can I do about that?

Thanks in advance,
- jd

Hi jd,

Let's drop back one square and review: Is this a new disk?  Did (or can) you run the manufactuer's format utility?  You may really need to run the 'newfs' command if you haven't done so already.  Can you mount the drive and its partitions with disktool?    

not a new disk.
manufacturers format?
I have data on this disk that I'd like to keep.... but I may be unlucky, I think.
formatting will "delete" the data, yes?

this is a firewire drive, with 4 partitions.
3 of the 4 partitions are mounting a.o.k.
all are hfs.

just rebooted, and only three of the four came back up.
/dev/rdisk1s14 looks a little hosed for some reason!

- jd

You asked if formatting a drive will delete the data.  The answer is yes, it will.  So will the newfs command, so let's avoid those until the bitter end. Two further thoughts:

1) Print out the partition map on your firewire drive and post it here:

sudo pdisk /dev/disk1 -dump [where disk1 is your firewire disk name]

2) Try mounting the drive with  'mount -t hfs /dev/disk1s14 /mnt'     where -t specifies a file type; its equivalent in Solaris (-F) over-rides the /etc/vfstab description of the file type (which is /etc/fstab in OS X).  I'm not certain that this will work, but it is worth a try

3) Run fsck several times with some options, namely b=1241568 (alternate superblock), -m (check only, do not repair) -p f (force check regardless of superblock flag).  Again, these are Solaris options, but they will probably work.  You do have an inode problem, but that is not the issue here; it can be fixed later.

Run:

fsck -o b=1241568 m
fsck -o b=1241568 f

Item 1: sudo pdisk /dev

guests-Computer:~ jon$ sudo pdisk /dev/rdisk1 -dump
/dev/rdisk1  map block size=512
   #:                 type name                  length   base      ( size )
   1:  Apple_partition_map Apple                     63 @ 1        
   2:       Apple_Driver43*Macintosh                 56 @ 64      
   3:       Apple_Driver43*Macintosh                 56 @ 120      
   4:     Apple_Driver_ATA*Macintosh                 56 @ 176      
   5:     Apple_Driver_ATA*Macintosh                 56 @ 232      
   6:       Apple_FWDriver Macintosh                512 @ 288      
   7:   Apple_Driver_IOKit Macintosh                512 @ 800      
   8:        Apple_Patches Patch Partition          512 @ 1312    
   9:           Apple_Free                            0+@ 1824    
  10:            Apple_HFS Apple_HFS_Untitled_2  79941584 @ 263968    ( 38.1G)
  11:           Apple_Boot eXternal booter        17408 @ 80205552  (  8.5M)
  12:            Apple_HFS Apple_UFS_Untitled_3  20253864 @ 80222960  (  9.7G)
  13:           Apple_Free                            0+@ 100476824
  14:            Apple_HFS Apple_HFS_Untitled_4  57026232 @ 100738968 ( 27.2G)
  15:           Apple_Boot eXternal booter        17408 @ 157765200 (  8.5M)
  16:            Apple_HFS Apple_UFS_Untitled_5  76659024 @ 157782608 ( 36.6G)
  17:           Apple_Free                            0+@ 234441632

Device block size=512, Number of Blocks=234441648
DeviceType=0x0, DeviceId=0x0
Drivers-
1: @ 64 for 23, type=0x1
2: @ 120 for 36, type=0xffff
3: @ 176 for 21, type=0x701
4: @ 232 for 34, type=0xf8ff

Item 2: mount -t hfs
guests-Computer:~ jon$ sudo mount -t hfs /dev/disk1s14 /mnt
mount_hfs: Invalid argument

Item 3:
multiple fsck's makes no difference, it seems!

Please note, I am running OS X 10.3.9
Thanks again for your continued help!

- jd

jd,

I'm seeing that your drive is a mixture of UFS and HFS partitions.  Did you use an Apple utility (disktool, for example) to partition this drive, and did you do the partitioning before you loaded data?  

I'm beginning to think that your disk1s14 (which is slice - or partition - 14), aka Apple_HFS_Untitled_4, got stepped on big-time.  Since you can't do mount it or do anything even with alternate Superblocks, your data may have gotten hosed also.

Let's not give up hope, yet.  Try this mount command:

hfs.util -m disk1s14 /mnt

And if that doesn't work use the same command with a capital 'M' which is a deprecated option but which is also a force mount:   hfs.util -M disk1s14 /mnt

Let me know what happens.

Hmm.
This is dragging on, heh!

Q: Did you use an Apple utility?
A: Yep. Disk Utility.
 
Q: did you do the partitioning before you loaded data?
A: yep. "partitioned" using diskutil, then created data.

Odd point maybe.
When I look at the output of pdisk, I see 2 x HFS and 2 x UFS - as above in this thread.
When I browse the info in the partition tab for the disk in "disk utility"  all of the 4 partitions are labeled as Mac OS Extended (Journalled). Don't know if this could be significant or not...

I tried running
sudo /System/Library/Filesystems/hfs.fs/hfs.util -m disk1s14 /mnt
and just got the usage statement
"
usage: /System/Library/Filesystems/hfs.fs/hfs.util action_arg device_arg [mount_point_arg] [Flags]
action_arg:
       -p (Probe for mounting)
       -m (Mount)
       -u (Unmount)
       -M (Force Mount)
       -a (Adopt permissions)
       -J (Make a file system journaled)
       -U (Turn off journaling on a file system)
       -I (Get size & location of journaling on a file system)
device_arg:
       device we are acting upon (for example, 'disk0s2')
       if '-J' or '-U' is specified, this should be the
       name of the file system we're to act on (for example, '/Volumes/foo' or '/')
mount_point_arg:
       required for Mount and Force Mount
Flags:
       required for Mount, Force Mount and Probe
       indicates removable or fixed (for example 'fixed')
       indicates readonly or writable (for example 'readonly')
       indicates suid or nosuid (for example 'suid')
       indicates dev or nodev (for example 'dev')
Examples:
       /System/Library/Filesystems/hfs.fs/hfs.util -p disk0s2 fixed writable
       /System/Library/Filesystems/hfs.fs/hfs.util -m disk0s2 /my/hfs removable readonly nosuid nodev
"
I then tried
sudo /System/Library/Filesystems/hfs.fs/hfs.util -m /dev/disk1s14 /mnt writable
with the same result.

I must have the syntax wrong somewhere.....
Any thoughts?

[ I'm thinking erase and start again! ] - don't want to waste too much more of your time...

Cheers,
- jd

Did you turn journaling on when you partitioned the drive?  I believe journaling is turned on as a default only with OS X Server, otherwise you have to explicitly turn it on.

There might be an issue with the pdisk utility which might be used by Disk Utility to create partitions.  I don't know if Disk Utility in fact does use pdisk but the problem is that older versions (10.2.x?) had a 15 partition limit (your drive has 17).  Thus one man page for pdisk has the following:

http://www.osxfaq.com/man/8/pdisk.ws
       Creating  more  than  fifteen  partitions  is not advised.
       There is currently a bug in the some (all?) of the kernels
       which  causes  access  to the whole disk fail if more than
       fifteen partitions are in the map.

But the current man page for pdisk does not have this warning:  http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/pdisk.8.html

There is a good explanation of this issue at http://www.macosxhints.com/article.php?story=2002062501132315&query=pdisk

As I said, I don't really know if Disk Utility uses pdisk in the background or not.  But the long and the short of it is, unless you want to use the next hint, I think you should just "erase and start again" as you recognized above.

If you are really "into it" you could try this technique for using the unix dd copy-and-convert-a-file command
http://www.macosxhints.com/article.php?story=20050720092514388&query=pdisk

(As an aside, I enjoyed this thread, and hope it was helpful to you.  It took me into different territory, yet conceptually it was similar to topics I should know for disaster-recovery scenarios where I work. I would have liked to have solved your problem, believe me! It was no idle exercise for me, and all I can say is "Good luck!")