November 18, 2005

Sharp tools in truth. Ow.

So li'l Gir died. So sad. I replaced him. However, it continues to rankle that an otherwise perfectly good, complex device like a 40G iPod has to be called 'dead' and discarded/recycled because the HD is acting up. When this first started happening, I tried to figure out if there was a way to just map out the bad sectors on the drive, since there did appear to be particular sectors that caused the poor thing to freak out when hit. Unfortunately, I couldn't figure out a way, because I'm not as smart as yer average bear.

Idly trolling the net, however, I found this - where someone else with a similar problem apparently had the same thought! And unlike me, knew enough C to make a dangerous stab at it!

Intrigued, I wished to subscribe to his newsletter. Er, no. That is to say, I downloaded the code, untarred it onto my Mac, and had a look. Apparently, his solution to the 'I'm not sure how the heck bad sector tables or their equivalent work in HFS+' problem that forced me to give up was much more elegant - he simply formatted his iPod as a FAT32 volume. The iPod doesn't care, and will function as either on a Macintosh - and there's much more info available on FAT32 FAT muckery. In particular, rather than telling the drive that the sector was bad, this gent proposed to tell the FAT itself that the sector was no good.

The downsides of this approach are obvious from reading his page - the modified FAT, with the bad sectors marked, wouldn't survive a reformatting/re-iPod-firmwaring of the device, since those would write a new FAT to the disk. The page itself came about because after several months of using his 'hacked' 'pod, he himself had to flash it, and was forced to go revisit his quick hack to determine what it did and how so that he could do it again. This time around, he figured why not document it (sorta) on the web?

Anyway, I find myself with a few terminal windows open, mucking around inside typedefs and big-endian->little-endian macros, blithely reading and writing raw bytes from and to li'l Gir. Haven't fixed anything yet, but I'm learning. After having the code tell me that my FAT copies weren't in agreement, and then refuse to make any changes, I've discovered that the author (apparently) hardcoded in certain values like the number of sectors per FAT and the number of FAT copies - values which differ depending on the size of the disk, and Gir isn't the same size as his 'pod, apparently.

While there's code that's ostensibly supposed to figure out some of this info by dumping it from the MBR/boot sector, it's not in the same executable, so i can't be sure that things which share var names across the executables really mean the same thing...esp. when they're derived in the first case from data off the drive, and simply declared for use in a different manner in the second. Replacing the values in the hardcoded versions with information taken from my runs of the dump code doesn't seem to work - it changes what sectors the code attempts to muck with, but they still come up as inconsistent (the FAT and backup FAT, that is) which prevents attempts to change it.

Now I just noticed that the dump code is warning that there's a sector 0 read error...and while the second FAT copy typedef's hexdump has interesting stuff in it, including what looks like packed bytes and a 'NON-BOOTABLE DISK' text message, the first FAT copy seems to be all zeros.

Hm.

Oh, suck. If sector 0 is tanked, then the primary FAT isn't working?

Hm, but Disk Utility claims it managed to properly initialize the volume, which doesn't sound like the primary FAT is corrupted. More likely, the place it's looking for the FAT is wrong, given the disk size difference.

ARGH. I don't know enough yet. More research.

Posted by jbz at November 18, 2005 1:14 AM | TrackBack

Comments
Post a comment









Remember personal info?