Why doesn't my mac startup after a failed zero writing?

Tom Selleck wrote:

Where to could it have gone?

Because it didn't complete writing zero's to the file, the file system wasn't updated so the file doesn't exist.

Tried to reboot from the internal disk, did not work.

When you deleted the data off the drive, that drive doesn't know it's gone yet, so you need to Single User Mode boot and fsck -y again, then one more time if it fixed it.

Hopefully it should boot once it knows the free space is now available.

If it doesn't what I suspect could have happened is another issue, perhaps you ran out of spare sectors or it's another problem.

Step by Step to fix your Mac

At least you have a external bootable drive, you might as well install your programs, and grab a copy of your files off the internal drive, rebuild the external drive like your internal, moving your files into same named accounts on the external drive.

It might come to that you will have to Disk Utility > Erase > Security Option > Zero the entire internal drive to fix the problem, map off any bad or failing sectors.

Reducing bad sectors effect on hard drives

It might come that you will have to repalce the internal drive if you ran out of spare sectors and the above method doesnt' work.

http://eshop.macsales.com/installvideos/

Then once you got a stable internal drive again you can use a wonderful free/donationware software called Carbon Copy Cloner to clone the whole external drive right onto the newly freshly zeroed internal drive. 😉

Default settings is fine for a first time clone, later you may want to change the update/backup options

http://www.bombich.com/

BTW, by chance have you ever happen to live on Black Point Road anytime in your life?

Was a extra a few times with my girlfriend, lived in the area and all.

We did bump into each other, especially at BoA I recall.

Tom Selleck wrote:

Oh, forgot to add: one weird thing is that although there was no temporary folder anymore under Library/Caches I could not find the 10Gb temporary file that was created when writing zeros... Even used the finder and typed its name with no success. Where to could it have gone?

That is consistent with the idea that temporary files are deleted on a normal shutdown & restart as part of the boot process. When you use Disk Utility while booted from another volume (like the installer DVD) to check the free space on the internal do you still see it at or near zero? If not, the temp files were probably deleted when you tried to start up from the internal.

It is possible you can't complete starting up from the internal drive now because some part of the OS has been damaged. (It would help diagnose what actually happened greatly if you would explain exactly how you interrupted the secure erase!) If this is the problem, just reinstall Snow Leopard from the installer DVD & update it as necessary to get to 10.6.8. This won't affect your user files or settings.

BTW, it is not true that any of the secure erase options perform any checks that result in mapping off bad sectors. The drive takes care of that by itself & only can do that when reading back data, which the secure erases do not force the drive to do. (A secure erase would not be very secure if it ignored bad sectors since they might still contain recoverable data.)

Tom Selleck wrote:

Now I am writing zeros over free space on internal disk to make sure that, in case it does not startup again, its not because of lack of space.

Writing zeros over free space does not change the amount of free space the drive has. A normal erase just deletes the directory entries of existing files & marks the space they used as unused in the file system, but it doesn't actually erase the data in the sectors the files used. A secure erase writes over these sectors with a new data pattern, all zeros or something else, to replace the sectors' original data to make it unrecoverable by utilities that ignore the directory & read sector data directly.

Thus the name "secure erase."

It has no other purpose. It doesn't free up any extra space or map out bad sectors.

R C-R wrote:

It doesn't ....map out bad sectors

It's a software "hack" when DU reads back the temp file for confirmation and enables the driver to map off failing blocks, and it does work.

https://discussions.apple.com/thread/577995?start=0&tstart=0

Two wrongs in one thread, going for record R? 😁

ds store wrote:

It's a software "hack" when DU reads back the temp file for confirmation and enables the driver to map off failing blocks, and it does work.

Disk Utility doesn't read back the temp file, which is only created for the erase free space options anyway.

I have confirmed this in several ways. The easiest is to time the operation & compare it to the drive's specs. There simply isn't enough time for the drive to read back all the sectors after writing to them before the process quits. I've even gone as far as probing the head driver's circuitry with an oscilloscope to verify that there are no sustained reads (write voltages are much higher than read voltages) long enough to read back all the zeroed sectors.

So when you say it does work, I have to ask how you have determined this. If you are going by Dr. Smoke's info, note that the only reference to Apple's developer docs is to a legacy tech note, & nowhere does it even say that a secure erase spares any blocks, even for the old HFS file system. Additionally, Dr. Smoke says, "Once the bad sectors have been spared, no attempt will ever be made to read-from or write-to them again." If this was true, a secure erase would not be secure since forensic techniques can read from any sector, sometimes as simply as by ignoring the directory structures and/or resetting the "grown defects" list stored in the drive with a manufacturer's utility.

R C-R wrote:

Disk Utility doesn't read back the temp file

R you denied DU > Zero even creates a temp file, until I managed to prove that it does, so obviously you haven't really throughly investigated what is going on in DU like I advised you to do so many ages ago.

There simply isn't enough time for the drive to read back all the sectors after writing to them before the process quits.

So when you say it does work, I have to ask how you have determined this.

Through personal experience over the years and also solving others like problems with the routine. The last time I used it myself was with this Early 2011 17" and it has worked on two occasions, once when OS X would act right despite being reinstalled twice and another time I couldn't format another parititon on the drive until the free space zero was performed.

I can confirm Dr. Smokes and Hatters considerable more expertise about the subject is valid, if you want to learn more about it or how DU works or why the zero works, I suggest you get with them, I frankly don't care as I concentrate on providing answers/information that work for people, not getting involved the myriad details.

If this was true, a secure erase would not be secure since forensic techniques can read from any sector..

Yes, a secure erase isn't as secure as intended, bad blocks could be mapped off and contain data that can be recovered using Magnetic Force Microscopy techniques.

Why I advise if one really needs to make 100% sure there are no recoverable bits with hard drives is to remove the storage device and destroy it.

How do I securely delete data from the machine?

ds store wrote:

I can confirm Dr. Smokes and Hatters considerable more expertise about the subject is valid...

If you read Hatter's comment, you will note that what he actually said in his 2006 post was

Any mapping is done by the drive, not by Disk Utility, which only can write zeroes or 7-way erase, and "hope" that the drive does the rest 🙂

So a) Disk Utility does not map out anything & b) there is no guarantee that the drive will do so, either.

Also note that Dr.Smoke claims, "When an attempt to write zeros to bad sectors fails, the bad sectors are both marked as occupied in the directory and added to the bad blocks file of the file system." Technically, this is a potentially misleading oversimplification. The head of a magnetic media drive can either write to or read from the media, but it can't do both at the same time. A bad sector can only be detected on a read, so unless the drive makes a second pass over a sector in read mode after the first pass in write mode, there is no way it can detect a "failed" write.

Since the drive & not Disk Utility controls bad block detection, the issue reduces to whether or not the drive actually does the second pass in read mode -- if it doesn't, it won't try to read the results of the write & can't detect if the sector is good or bad. Moreover, it has to read every sector it has written to. Since "soft" (recoverable) read errors occur from time to time even in good sectors, it would actually have to keep trying to read a sector that produced a read error until its internal logic decided it was actually bad & mark it as such. Thus, one can expect the process to take at least twice as long as a write-only operation, & longer still if there are any read errors, which obviously would be true if there are any bad sectors.

To see if the drive really does this, you can perform a simple test: obtain your drive's sustained read & write data rates. If you can't find the specs for this, you can use a disk performance benchmark tool like Blackmagic Disk Speed Test. With a bit of simple math you can figure out how long it takes to write zeros (or whatever) to all the sectors in a secure erase & how long it takes to read them. Add the two figures together. Compare that to how long the zero erase actually takes. If it doesn't take at least that long to do that, then the drive can't possibly be doing the second pass to read the data & thus it can't detect any bad blocks.

Note: to keep things simple & for the best accuracy, consider repartitioning a test drive with a relatively small first (& therefore fastest) partition for testing. Run the test before you write any other data to the partition to eliminate the (typically small) delays caused by file fragmentation.

I have done this with a variety of different ATA & SATA drives (all built after 2001), using Leopard & Snow Leopard & several different versions of Disk Utility, & have never once seen the secure erase take anywhere near long enough for the process to both write to & read from all the affected sectors. It just doesn't happen.

Regarding the significance of 2001, ATA-type drives, & the actual security of a secure erase, you might be interested in the comments here about the command set built into most post 2001 ATA drives for this purpose, including writing over data on bad blocks.

The bottom line is a secure erase might cause the drive to map out bad blocks it otherwise would not discover during normal operation, but the chances of that happening on modern drives users are likely to use with contemporary Macs are vanishingly small & the procedure should not be relied on for any purpose other than for secure deletion of data. If you want a reliable procedure that will map out bad blocks, choose one that guarantees that the drive will read the sectors.

When the drive writes data it is checked that it is written successfully, which is short of a full read, that's why you get the discrepancy. You should know this check occurs on all writes.

Bad blocks are obviously being mapped off, as the zero process works, some I've read use the 7x process as it's more reliable method, I don't recommend that as the time involved is unreasonable.

Yes, using some sort of third party product dedicated to the bad block mapping off task would be better, however we also have to balance the user into the equation and what they have to work with as this process of mapping off the entire boot drive is required from another bootable volume, which is difficult for users to take the additional step of installing OS X on a external drive, then installing the third party software to run on the internal drive.

I recommend the zero erase as it's already part of the Disk Utility, does the free space, it's on a boot disk/partition and does a well enough job considering the low volume of problems from bad sectors failing right where it causes the most issues not otherwise successfully taken care of by the drive by the read back mapping off process.

Using Disk Utility may mean one will have to do it a little more often, perhaps every 6 months before a big write or partition, but that should be plenty enough for those who require a bit more reliability with their hard drives or solve problems why OS X won't install/partition, which I did solve a few users problems here with that zero erase method as well as my own on many occasions.

I'm glad you finally realized that the zero erase process may map off bad sectors, that it does work "good enough" and convenient for users, despite it being a software hack, which it is.

If one wants even more insurance from bad sectors failing, they likely should use a third party product dedicated to the task, however those people likely needing such a product are pro users in video and audio (with very large files crossing many sectors), have encountered this issue before and use software tailored to the task of ensuring all bad blocks are eliminated before writing to a new drive.

The majority of users here are either non or semi-capable, so simplicity and ease of use is in order.

I will continue to recommend the process for hard drives, as it gives a free reliability bonus during the OS X install process and is convenient. Secure erase is not available for SSD's anyway.

Since hard drives are on their way out soon, we will likely only see them in future Mac's only in the Mac Pro and external drives, which both cases a third party solution would be preferred and more reliable and more rewarding for the user as it would be run from their more reliable SSD.

I hope this resolves your issue and technically I should receive a greenie from you for solving your problem.

You should apologize to the OP for hijacking their thread, you should have created this question in the Lounge where this topic belongs. 😐

ds store wrote:

When the drive writes data it is checked that it is written successfully, which is short of a full read, that's why you get the discrepancy.

Hogwash.

To begin with, there is no magic way for the drive to check that a write is successful "short of a full read," whatever that vague phrase is supposed to mean. Every block on any drive build in the last twenty years or more includes a checksum in addition to the data. On every read, the drive compares the block's checksum to its data. Read errors occur when the checksum doesn't match the value computed from the data, which can only be done by reading all the block's data. In fact, modern drives write error correcting codes that (as the name suggests) allow the drive to correct "soft" read errors that occur occasionally even on perfect drives.

In the second place, modern ATA drives don't normally read the data it has just written to a block at all. (This is often called "read after write," or "RAW" for short.) If the drive did this, it would show up in manufacturers' performance specifications as write operations taking about twice as long as read-only operations. (Clue: they don't.) Some older drives, particularly high end "enterprise class" SCSI drives, did in fact have RAW enabled. These drives were intended for applications in which data retention accuracy was more important than performance. These days, largely because of error correcting codes & to some extent because competition among brands for high performance requires it, modern ATA drives do not enable RAW at all, or if they do it is automatically & permanently switched off shortly after the drive is put into service. (This is why sites like Bare Feats used to "break in" drives before testing them, to insure that a new drive with RAW temporarily switched on would not score poorly in benchmarks vs. a drive that did not do that.)

In the third place, even if the secure erase did reliably map out bad sectors that otherwise had not been detected & automatically taken care of by the drive, it means the drive is defective & should be replaced. Period. A modern drive in good working order can & does spare out sectors without any help from outside sources. They usually can detect that a sector is going bad before its data becomes unrecoverable & (using repeated retries & error correcting codes) move it to a spare one. When it runs out of spares or is no longer able to detect a sector going bad before its data is recoverable, it is time to replace it.

Bad blocks are obviously being mapped off, as the zero process works, some I've read use the 7x process as it's more reliable method...

First of all, how do know these bad blocks are being mapped out? The only way there would be any external signs of that is if the drive's capacity is reduced by the number of blocks mapped out, & if that is happening it means the drive has run out of spare sectors, since spares are not included in its capacity. If that's what's happening, see above -- the drive is dying & should be replaced.

Second, if a 7x pass is more reliable, then a 1x pass must not be completely reliable, right? How do you explain that? More of your nonsense about less-than-complete reads, perhaps?

I'm glad you finally realized that the zero erase process may map off bad sectors ...

So now, are you finally admitting that this isn't a reliable procedure for mapping out bad sectors? 😉

Hi, I'm having a very similar problem. In a few words:

Safe mode and Startup Disk mode end up on a grey screen with the apple and "clock" frozen. Meaning, I can't boot from the Mac OS Installation Disk (Leopard)

Even though I booted to Single-User and ran fsck twice until the "drive is ok" message pop up, Startup Disk doesn't boot.

Didn't tried yet but apparently, booting from Target mode, wiping out the Local Drive and installing the OS from scratch does not allow the Mac to boot anyways.

Is the Local HDD completely useless? Or is this, as I read in other forums, a RAM failure?

Tom Selleck, could you finally solve it?

Start a new thread and state out your problem in more detail please

(machine version, OS X version, what you did etc etc)

This thread is old, polluted and we can't track it unless the original poster is involved, nor can we get credit.

thanks. 🙂

****, I could swear I've updated here the results:

Well, deleting and writing zeros over them did the trick. Put the installation disc there, repaired and worked. It must be the disc of the os system snow leopard if this was updated to that, and I was using the original one.

Oh, now I know why I did not reply! Can't remember my passworld for the username "Tom Selleck". I'm Tom Selleck by the way. 🙂

Thank you guys for helping me out, this is an awesome support forum.