Hackintosh to new HDD

[Kurto2021]

I did an install using Psystars RebelEFI and I have to say it was super easy. I was just testing it out and overall was pretty happy with it and my HDD started going beserk. I went ahead and used Carbon copy cloner to get all the data over to a new HDD but I know I will not be able to boot off of this.

 

Is there any app I can use to get the install from the HDD that is failing to a new one and keeping the drive bootable?

[srs5694]

There's always the brute-force approach: Make a bit-for-bit copy of every sector on the original disk. If you can boot an OS X installer and get to a Terminal prompt, you can do this like so:

 

dd if=/dev/disk0 of=/dev/disk1

 

This assumes the original disk is /dev/disk0 and the destination is /dev/disk1. Verify that this is so; if it's not, you'll wipe out your OS X installation! A similar command issued from a Linux emergency disk (such as System Rescue CD or PartedMagic will work, but you'd change /dev/disk0 and /dev/disk1 to Linux device identifiers, such as /dev/sda and /dev/sdb or possibly /dev/hda and /dev/hdb or something else in the /dev/hd* range.

 

This will work if the new drive is as large as or larger than the original. It will not work if the new driver is smaller than the original. Even a one-sector difference could render such a copy useless. If the new disk is larger than the original and you used a GUID Partition Table (GPT) configuration, it's advisable to adjust the GPT backup data structure locations. (GPT is a method of disk partitioning. Check it out on Wikipedia and compare it to the Master Boot Record entry, then use Disk Utility or other tools to figure out what you've got.) I don't know offhand how Apple's utilities handle "misplaced" GPT backup data structures. I do know that Linux's GNU Parted and related tools will move the backup GPT when it sees them in such a changed location, but these tools are also likely to wipe out your boot loader. My own GPT fdisk can do the repair, but only in version 0.5.1; 0.5.0 and earlier have a bug that cause them to mishandle such disks. In theory, you should be able to boot your OS X system from the backup and then run GPT fdisk to do the repair, but I've not tested this; it could fail if OS X itself doesn't like this configuration. None of this post-copying mucking about should be required with MBR disks, which don't store data on the disk size in their data structures.

 

Less brute-force approaches will also work. You should be able to use Carbon Copy Cloner or similar backup tools to make a backup and then restore your boot loader to the backup disk. This approach is more elegant, won't require any changes related to disk size and GPT data structures, and will probably be faster, but you'll need to figure out how to re-install the boot loader to the backup disk. Details of that operation vary depending on the boot loader you're using, so you should figure that out and track down the relevant documentation. It's usually just a matter of running one automatic program or typing one or two text-mode commands.