fsck: "Bad super block: magic number wrong"

Unless you chose otherwise, the volume was likely set up as an HFS volume rather than a UFS volume. The message you are getting likely is a result of trying to run /sibn/fsck on an HFS volume rather than /sbin/fsck_hfs.

Good luck...

George,

I'm unfamiliar with safe mode, but familiar with single-user mode (which is usually used for these kinds of things on the boot disk). I trust 'safe mode' doesn't automatically mount your firewire disk, but loads the kernel extensions for your Firewire bus.

When in doubt, try the debugging option on the whole disk, /sbin/fsck_hfs -f -d /dev/disk3 (or 7).

Bruce

George,

Sadly, I'm not that familiar with Macs. However, a few facts might give you some ideas.

1. Apple is diligent in making sure MacOSX works, but it cares very little about Darwin's commands. No backup programs were ever updated to HFS+ but 'fsck_hfs; and 'ditto', a replacement for 'cp'! Clearly fsck_hfs couldn't identify the disk's format, but MacOSX could.

2. You probably partitioned the disk to support volumes of different file systems. One possibility is ext2, Linux's file system, known also as Apple UNIXSVR2. So, why didn't fsck recognize it? I'm not sure. Unix, historically, has been run on processor with 'big-endian' words.

3. Microsoft formats are designed for an Intel processor, and are likely written in little-endian. It's possible that you need an Intel Mac to open files written with one, and you are attempting to open use a disk prepared for an Intel Mac with a PPC Mac, or vice versa. The tradition is for Linux, for example, to write big-endian files, even from an Intel processor. But Mac may be shooting for speed rather than compatibility. Anyone know?

It's rather amusing that MacOSX correctly identified the MDB in the first block, but fsck_hfs didn't know its file system, couldn't read its 'magic number'. The MDB for ext2 is at 0x83, not 0x0; so I'm unfamiliar with the file system too.

Perhaps the history of the drive will allow you to identify the problem with reading it. Sorry I can't help more. You need more current technical help.

Bruce

George,

My migraine medicine is working, and I realized what a careless error I wrote. Have to fix it. I was referring to byte-switched, of course; not 'word-switched', and a 'magic number' used to be the first two bytes of a file or 'special file': each of the two characters might be switched and be unreadable to the utility kindly provided by Apple (but not its OS).

Don't quote me, but I seem to remember the Master Boot Record starting at sector 0 on Microsoft formats. There are so many formats devised to contain volumes of different OSs and even load the boot records of many that only you would know which yours is. Goodnight and good luck.

Bruce

George,

When you formatted the drive, did you re-partition it and format it with HFS+? It seems partitioned by another OS, which allows HFS+ volumes. Did you use a boot loader, so you could boot two OSs from the disk? I'll just offer some more things sighted, not insights. 🙂

This is looking like a common problem, though; so I could use some help with ownership & permissions from someone. It would seem that Tiger & Leopard both mount NTFS partitions read only, but NTFS-3g's permission system is similar enough to Unix's that it can be mounted read/write.

MacFUSE appears to do things with 'FUSE', a mystical object at first glance, one whose permissions can be converted to either HFS+, ext2, or usf. The ownership & permissions appear to change with where the external drive is mounted on the boot disk's file tree. I assume you know all about these things.

Is using them together a good idea? In any case, they both allow a file system to be mounted read/write, and modify the Mac OS itself. Here's an interesting remark from the MacFUSE FAQ:

+ Q 3.2. After installing MacFUSE, I can't mount any disk images, optical discs, etc. What's going on?+

+ A: It's likely that you installed a broken ntfs-3g package you found on the Internet. The package might be interfering with the disk image/disc mounting process. Try removing the /System/Library/Filesystems/ntfs-3g.fs/ directory.+

Also, Leopard's update 10.5.1 has the sentence:

+Addresses formatting issues with certain drives used with Time Machine (specifically, single-partition MBR drives greater than 512 GB in size as well as NTFS drives of any size and partition scheme).+

You can check the volume's ownereship & permissions with a Ctrl-click 'Info Menu' on the mounted volume's icon. Does all look OK?

Wish I knew more, but perhaps these observations will give you some ideas. Best of luck.

Bruce

George,

A cross-platform bug! That worth one paper at least!

Seriously, now that you've proved it's the disk, it would be nice to know whether one of those file system adjuncts (that modify ownerships & permissions) changed your partition table (or what if it, if it were originally parititioned for a RAID array). Did this problem occur before you installed & tried one of the two file system adjuncts?

If you have a utility that can read the binary on your hard disk,

http://en.wikipedia.org/wiki/GUIDPartitionTable

lists a host of GUIDs and where to find them. Note also, it does mention that the first two bytes of these partition-table identifiers can each be byte-switched to create, presumably, an old-fashioned 'magic number'.

Bruce

George,

I don't know how much time you have, whether the computers are 32- or 64-bit, whether your at home computer has an Intel microprocessor, whether the drive is ATA or SCSI, or how much time or interest you have to investigate.

However, here is a list from sourceforge.net of physical disk editors. In physical mode, I imagine you would request to see a range of blocks or clusters; in logical mode, I should imagine it would find those files & directories of interest to you. Just guessing here.

http://sourceforge.net/softwaremap/trove_list.php

Bruce