Interrupted OSX install on drive and now it's full of bad blocks?

By hard reset you mean that you powered off your mac during install?

Because this could result in bad blocks, because the harddisk head could crash onto the discs, and damage the disc and blocks. So this would be a hardware defect then.

But probabely it's only the Table Of Contents TOC that is corrupt. To repair this, you need an repair utility. Actually i only know TechTools or Norton

Hi Danial;

You suggested that Norton might solve the problem but I beg to differ with you. Norton does not appear to understand OS X and actually causes more harm then good. My suggestion is to never ever use Norton on a system with OS X.

Allan

Well, actually i already fixed some harddisc problems with Norton i have to admitt.
But i like TechTool a lot more, it has more functions and is better integrated with Mac OS X.

It is highly unlikely that a power interruption by itself would cause a head crash, since hard drives must be designed to power down without damaging anything. A normal power down usually "parks" the head assembly in a safe area so that mechanical shock (like dropping the drive) won't cause the head to crash into the platters; at worst, the 'hard reset' would leave the head over the platters. Even this is unlikely since there is usually enough stored energy in the power supplies to complete the parking movement. (Plus, if Robert didn't literally pull the plug & it is a Firewire drive, power continues to be supplied even on a forced shutdown.)

So Robert probably doesn't actually have any (new) bad blocks, just the corrupted data structure Daniel refers to. It may not be necessary to use a third party utility to correct this, depending on what Robert means by the hard drive not 'initializing' in Disk Utility. As long as Disk Utility recognized that the drive exists (it is on the list in the left side of the Disk Utility main window), he should be able to reformat it with Disk Utility's "Partition" tab.

Note that the drive & any volumes it contains are two different things. The first is usually listed as a string containing capacity & model info (like "149.1 GB ST3160023AS" or such); indented below that normally appear its volume(s), listed by name(s) like "Macintosh HD" or similar. The volume(s) may have been damaged enough not to appear, or not to be mountable, but the drive itself should be detected by Disk Utility. If so, selecting it should enable the "Partition" tab & partitioning the drive (with one or more volumes) should cause it to map out any actual bad blocks it (the drive itself) discovers during the process.

If so, selecting it should enable the
"Partition" tab & partitioning the drive (with one or
more volumes) should cause it to map out any actual
bad blocks it (the drive itself) discovers during the
process.

Just partitioning the drive won't map out bad blocks. You need to erase the drive and choose "Zero out data" from the "Security options". The bad blocks will then get mapped to spare blocks on the drive. If you have too many for it to remap all of them, the drive will be reported as "failing" by the S.M.A.R.T. status.

charlie

AFAIK, the "Zero out data" option applies to data partitions but not to the normally invisible partition that contains the partition type itself; for instance, an Apple Partition Scheme. (If this were not the case, the drive would require reformatting after erasure, since all partition info would be lost.)

In all cases, the drive itself actually discovers & maps out bad blocks. The zero out data option forces the drive to write to every data sector of a selected volume (or all of them if the drive itself is selected) in one (long) operation; thus, all such bad blocks are discovered at once instead of on-the-fly as the blocks are used, which is the normal way & transparent to the user. Either way, it should be obvious that any "housekeeping" partitions will not be zeroed, so it is incorrect to suggest that all potentially bad blocks on the drive will be discovered by erasure, even with the zero option.

I'm not certain if an interrupted installation of Tiger would result in bad partition info or not, but reformatting the drive should rewrite it, & in so doing, discover & map out any bad blocks in that part of the drive. Once that is accomplished, then Robert can, if he chooses, use the zero option to map out the remaining bad sectors, or just let the drive do that on the fly.

Unfortunately, the I/O errors suggest the drive itself may have some problem(s). Since DriveGenius offers free support, it may be best to contact Prosoft for advice.

Wish I could be helpful, but I'm not that familiar with the scope of DriveGenius' initialize command.

Hi--

AFAIK, the "Zero out data" option applies to
data partitions but not to the normally
invisible partition that contains the partition type
itself; for instance, an Apple Partition Scheme. (If
this were not the case, the drive would require
reformatting after erasure, since all partition info
would be lost.)

All I was doing was repeating a what had been posted by a MicroMat tech at the MacFixit forum. In any case, if I select the drive in Disk Utility and reformat it, the partitions have to be rebuilt. Perhaps that wasn't clear from my post.

In all cases, the drive itself actually discovers &
maps out bad blocks.

According to the tech from MicroMat, this is not necessarily true. The drive won't always remap the bad blocks, it will sometimes miss. The only guaranteed way to remap them is to erase the drive and zero out the data.

Either way, it should be
obvious that any "housekeeping" partitions will not
be zeroed, so it is incorrect to suggest that all
potentially bad blocks on the drive will be
discovered by erasure, even with the zero option.

Perhsps I wasn't clear in my post. I meant to boot from the OS X install disk, run Disk Utitility from there, choose the hard drive, not a partition, and erase it there, choosing the option to zero out all data. Certainly, that will delete the partion information, but to what extent it leaves any other "housekeeping" partitions, I really don't know.

charlie

Robert--

When using the zero out data option it still shows
the I/O errors.

It's beginning to sound to me like your drive has failed. One more thing to check would be to run the Apple Hardware Test for your PowerBook. It's on one of the discs that came with the PB. Run the short test first, as it should take around 10-15 minutes to complete. If it doesn't find any problems, try the extended tests. They may take as long as a couple of hours, depending on the amount of RAM installed.

The Apple Hardware Test won't scan the surface of the hard drive, but it will point out if there are problems with the drive. It's the "Mass Storage" test. If that fails, I think you need to have the computer looked at.

The Drive Genius scan stopped half thru presumably
because it couldn't proceed past the bad blocks.
Strange you'd expect a scan to finish regardless but
this one didn't. My system.log is full of I/O errors.

Yeah, it's odd it wouldn't finish, but I know nothing about Drive Genius. One thing that could be happening is that all the scans are just causing more bad blocks. In other words, as the head tries to read or write to check the surface of the disk, it's scraping off more of the magnetic surface.

My bad block experience is this: last year, I discovered I had 6 bad blocks on my old PowerBook's hard drive. I cloned off all the information and reformatted, zeroing out the data. I dont' remember if I saw any I/O errors in the logs, though, as I did the reformat. Once I was done, I did another surface scan with TechTool and is reported no bad blocks.

After I restored my clone, I compiled and installed a program called smartmontools, which is a command-line utility for S.M.A.R.T. status reporting. One of the things it will report is how many sectors (blocks) have been re-allocated.

I made a note to myself of the number of re-allocated sectors immediately after restoring the clone (28). About once a week, I'd run the surface scan and see if either the re-allocated sector count went up or the test reported any bad sectors. Up until the time I sold the laptop last year, there was no change, meaning that the drive was at least stable and not getting worse.

charlie

According to the tech from MicroMat, this is not necessarily true.

Interesting. I've been told that there is no way the OS can tell the drive to map out some specific physical block, only that it wants to read or write to some logical sector, which the drive translates to the cooresponding physical one. If the drive detects that the physical one is bad, it maps the logical sector to a spare if it can. This map is kept in the drive's firmware & generally cannot be accessed or changed short of factory-type procedures -- for all practical user purposes, it is a permanent change.

The various tech responses in the URL you mentioned seem to imply this is true. At one point he mentions that TTP's surface scan should not turn up the same bad block more than once, since once accessed the drive will not access that (physical) block again. It also appears that TTP & similar utilities can't actually mark blocks bad either, they instead mark ones they judge marginal as used in the file system, which is no more permanent than the file system itself. (The mention of Intech's SpeedTools Media Scanner somehow getting around this was interesting, though.)

I think what the tech meant about zeroing out data permanently remapping a bad block was in reference to this (the file system map vs. the firmware one), but I'm by no means certain. However, what he said about a multipass zero erase being no better than a single pass one makes me believe the only "miss" involved is for (physical) blocks not yet accessed by the drive.

Certainly, that will delete the partion information ...

I guess I wasn't being clear either. There are partitions that don't store regular data but metadata about the drive format itself, for example if uses an Apple or PC partition scheme. I do not believe such partitions are "zeroed out" with any "Erase" tab option of Disk Utility, although they may be written to, for instance to update the fact that only one Mac volume exists after a 'whole disk' erase.

To sum up, what I'm trying to say is that the drive has to access a sector to detect & map a bad one to a spare. If the drive doesn't do that, no utility will either. They are useful to monitor the rate of bad block creation/detection, but that is primarily a check of the drive's health, not a way to avoid problems resulting from bad blocks themselves.