[psaux]

Originally Posted by sirtronics

No , I did type sudo -s was propmted for password ( there is none)
and then typed the rest.

Hokay ... I skipped a step and made a couple typos writing things out. Mea culpa.

Here's the errata:

Step 4b) "umount -f /dev/disk1s1" (or whatever the disk from step 3b was)

Step 5's command like should be changed so that /dev/disk[whatever] is instead /dev/rdisk[whatever]

so .. for me to do it, the rundown is like this:
(asterisks denote non-command-line actions)

*connect USB disk*
*open terminal from applications->utilities*
sudo -s
mount
*find the drive line in the mount output*
umount -f /dev/disk1s1
dd if=/dev/rdisk0 of=/dev/rdisk1
*wait*
exit
exit

So, anyway, sorry about inadvertently leading you astray. This should do it, but again, be careful.

---------- Post added at 10:21 PM ---------- Previous post was at 10:13 PM ----------

From the playing I've done so far, I think the devfs abstraction in use here sidesteps some of the traditional problems such a cloning operation would have in older-school unixes. Additionally, since it's purely outbound data, and isn't privy to FS-level stuff, it's not going to go down a rabbit hole when it hits special inodes, etc.... As for bootability, this may possibly need extra args passed in at startup to select the right drive, depending on the bootloader, you're right about that. However, altering it so that it doesn't would then leave him with something that was no-longer an exact/restorable clone, so it's probably best for him to leave it this way and just add boot args if necessary when using it.

Originally Posted by reflex

I expect you're getting ''permission denied" because the target drive needs to be unmounted before it can be copied to. I don't use OSX, but from what I've read, it looks like the terminal command would be "diskutil unmountDisk /dev/diskX" (with sudo/root permissions, and where diskX is your target disk). Unmounting it from the GUI may work, too.



I've used a procedure similar to the one recommended by psaux to create drive images on Linux. But I'd recommend performing the clone after booting off a another drive (like a LiveCD), because it can be problematic to image/clone at a low-level when the drive is in use.

I'm also not sure if the end result will be bootable. It will be a perfect copy, but the move to an external drive may make it unbootable. For example, in Linux, traditionally the root filesystem was specified by a device name like "/dev/sda1", but those device names change, depending on how drives are hooked up. And a changed device name means an unbootable system. I don't know how OSX would deal with the situation.

You might be better off just saving an image of the hackintosh install, then it can be restored if needed. You can use a similar "dd" command, except the output file will be a file.

To create a drive image, I'd boot off a Linux Live CD, then issue a command like "sudo dd if=/dev/sda of=drive.img", that'll save an image of the drive to a file named "drive.img" in the current directory (change the current dir to a USB drive or something prior to the command). The image will be uncompressed (a 16GB image file for a 16GB SSD). You can compress as the image is created, but if you have the disk space, you can leave the compression for later (the Atom makes compression slow, so when I imaged my drive, I compressed the image afterwards on my Core 2).


...and if you want to proceed with a clone anyway:

I'd boot off a Linux LiveCD, then issue a command like this "sudo dd if=/dev/disk/by-id/ata-WDC_WD2000BJKT-00F4T0_XXXXXXXXXX of=/dev/disk/by-id/usb-WD_2500BEVExternal_XXXXXXXXXXX".

The "/dev/disk/by-id" directory has a list of drives and partitions by interface, then id, then serial number. It makes the device names long, but there's little chance of screwing them up (my example unambiguously images a internal (ata prefix) Western Digital 200GB drive to a USB 250GB). You could use a simpler command, like "sudo if=/dev/sda of=/dev/sdb", but that's easier to screw up. It might also be a good idea to mount the source drive (readonly), before proceeding with the imaging, because the system should prevent you from writing to a mounted drive (say if you mixup the source and target drives).

Also, be aware that this technique performs no filesystem or partition resizing. So, the target drive has to be at least as big as the source, and in the end, the partitions on the target drive might be undersized. For example, cloning a 16GB SSD to a 120GB HDD will leave you with 100+ GB of unpartitioned space. It's possible to grow filesystems/partitions into unpartitioned space, but it's gonna be more awkward on a hackintosh.

---------- Post added at 10:22 PM ---------- Previous post was at 10:21 PM ----------

Odd .. Why is the forum concatenating my posts?

[reflex]

Originally Posted by psaux

From the playing I've done so far, I think the devfs abstraction in use here sidesteps some of the traditional problems such a cloning operation would have in older-school unixes. Additionally, since it's purely outbound data, and isn't privy to FS-level stuff, it's not going to go down a rabbit hole when it hits special inodes, etc....

Yes, it's purely "outbound" data, but any writes to the source drive during the process may screw up the image*, so to be safe, NO data can be written to the source drive during the process. The only way to ensure that no data is written to an entire drive is to unmount its partitions, and you can't unmount a system partition. So, that's why I suggested booting off a LiveCD.

* Imagine a pair of files created during the imaging process. One beyond the current progress of the imaging process and one behind. The file ahead will get written to the target drive, the file behind will not get written to the target drive. It's not hard to imagine this breaking something.

Originally Posted by psaux

Odd .. Why is the forum concatenating my posts?

It's not uncommon for webforums to merge sequential posts from a single user. I think the setting might have changed around here at some point, but you'll have to ask an admin to be sure.

[psaux]

Originally Posted by reflex

Yes, it's purely "outbound" data, but any writes to the source drive during the process may screw up the image*, so to be safe, NO data can be written to the source drive during the process. The only way to ensure that no data is written to an entire drive is to unmount its partitions, and you can't unmount a system partition. So, that's why I suggested booting off a LiveCD.

* Imagine a pair of files created during the imaging process. One beyond the current progress of the imaging process and one behind. The file ahead will get written to the target drive, the file behind will not get written to the target drive. It's not hard to imagine this breaking something.

It's not uncommon for webforums to merge sequential posts from a single user. I think the setting might have changed around here at some point, but you'll have to ask an admin to be sure.

You do have a point about ongoing disk writes during the clone... I wonder how much activity in that regard OSX has going behind the scenes if your usage is confined to this one operation.... Also, wouldn't a boot with the system drive mounted read-only be feasible? I know with some linux and Solaris versions I used to do that ... Still, generally speaking, an external boot would be simpler to get completely right, quite true.

[harakiri]

here is my way to do this:

Boot from stick that I used to install.
After the installer comes up start disk utility from the menu
Add external drive. Unmount the system drive that you want to image
Make image of system drive to external disc using Apples Disk Utility

That image can also be restored this way. After restore the mini boots from recovered image.
I have tried that several times successfully ( have images of 10.5.7, 10.6 and now 10.6.2)

Never tried this on a dual boot system though as my mini9 only has 8GB SSD :-)

Cheers!

[reflex]

Originally Posted by psaux

You do have a point about ongoing disk writes during the clone... I wonder how much activity in that regard OSX has going behind the scenes if your usage is confined to this one operation.... Also, wouldn't a boot with the system drive mounted read-only be feasible? I know with some linux and Solaris versions I used to do that ... Still, generally speaking, an external boot would be simpler to get completely right, quite true.

I dunno how much write activity a idle OSX system performs. The less activity, the less chance an image of the live system will get screwed up, but I prefer the near perfect guarantee of an image/clone created while the system is offline.

Yes, if the system drive mounted read-only, everything should be fine, but I figure it's easier to boot to a separate drive, like a LiveCD.

---------- Post added at 07:43 AM ---------- Previous post was at 07:41 AM ----------

Originally Posted by harakiri

here is my way to do this:

Boot from stick that I used to install.
After the installer comes up start disk utility from the menu
Add external drive. Unmount the system drive that you want to image
Make image of system drive to external disc using Apples Disk Utility

That image can also be restored this way. After restore the mini boots from recovered image.
I have tried that several times successfully ( have images of 10.5.7, 10.6 and now 10.6.2)

Never tried this on a dual boot system though as my mini9 only has 8GB SSD :-)

Cheers!

As long as you make sure that you're creating a drive image, not a partition image, this sounds like a good technique. (You want a complete drive image, so that all the hackintosh stuff gets preserved)

[SnakeGirl]

Originally Posted by psaux

Okay ... assuming for some reason you don't want to just use Time Machine ....

psaux,

Are you saying that Time Machine can make a BOOTABLE external clone copy of the internal drive? i have zero experience w/Time Machine so far & have only ever used SuperDuper! to make bootable system clones (OS X 10.5.7) on external drives for my MacBook, but i was also wondering if an external clone copy made w/SuperDuper! on a Dell Mini 9 Hackintosh would be directly bootable on the Dell? Or would the external copy itself not be bootable but would it have to be restored back to the internal drive before it is bootable? (if anyone knows ... ?) So far, i have made 1 SuperDuper! external backup of my Dell Mini 9 internal drive, but have not yet tested it by attempting to boot the Dell from the external clone.

Thanx,

[sirtronics]

actually I used superduble and made a copy.
It was a bootable copy but for some reason it worked "funny" .
When I installed the "copied" drive some of the drivers(airport) were not working????

Originally Posted by SnakeGirl

psaux,

Are you saying that Time Machine can make a BOOTABLE external clone copy of the internal drive? i have zero experience w/Time Machine so far & have only ever used SuperDuper! to make bootable system clones (OS X 10.5.7) on external drives for my MacBook, but i was also wondering if an external clone copy made w/SuperDuper! on a Dell Mini 9 Hackintosh would be directly bootable on the Dell? Or would the external copy itself not be bootable but would it have to be restored back to the internal drive before it is bootable? (if anyone knows ... ?) So far, i have made 1 SuperDuper! external backup of my Dell Mini 9 internal drive, but have not yet tested it by attempting to boot the Dell from the external clone.

Thanx,