No Drag'n'Drop in Disk Utility?!

I've done it from the DVD in Disk Utility. Could it be that the volume you're trying to drag into the restore from field is unmounted?

1. Are you sure your backup is a disk image file? By default, SuperDuper makes bootable clones of volumes on some other volume, not image files. Did you select the "Disk Image" option in SuperDuper for the original destination?

2. If you have made an image file with SuperDuper, does it appear in the list of disks in Disk Utility when you have started up from the installer DVD, or do just "real" volumes appear in the list?

3. Are you sure you are selecting a volume in the list & not its parent drive? Only volumes can be dragged to source or target fields in Disk Utility.

Sounds like a solution is to use the command line 'asr' utility, but I'm still working out how to use it.

http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/asr.8.ht ml

(Same problem here btw)

Hmmm. I had another reason to boot from my installer disks & run Disk Utility last night. While so booted, I also tried dragging various volumes to the source & destination fields of its "Restore" window. I had no trouble doing so, although I did not actually do a restore.

Perhaps this is something specific to Intel Macs?

I came across this exact problem this morning when trying to use restore to make a backup. The glidepad mouse on my Macbook refuses to allow me to select a line and drag and drop to either source or destination fields, when I'm booted from the install disk. When I drag, it simply widens the selection in the volumes window.

I've not (yet) tried this on another Intel mac, but will do so this evening and report back.

Bug in the Glidepad driver under install boot ?

Paul

I'm having the IDENTICAL problem on an Intel iMac. Has there been any resolution on this or any kind of a workaround?

I have a MacBook Pro and will try to confirm this in a minute.

I'll add that it is entirely possible that a bug can be specific only to one platform, since a universal application is essentially two completely different applications depending on which platform it's running on. Something as simple as dividing by zero on a PowerPC Mac will give you zero, yet on an Intel Mac, it will crash the application.

Dual 2.7GHz PowerPC G5 w/ 2.5 GB RAM; 17" MacBook Pro w/ 2 GB RAM - Mac OS X (10.4.6)

Wow, I tried it just now and you are right. It's really weird because I compared the version of Disk Utility on the Install Disc with the one that's on the hard drive and I can't see any differences. The main executable file, all of the plugins, and all of the nibs are exactly the same. I opened the nibs and found that it's the "DUOutlineView" that appears to only use the default table view behavior when it was running from the install disc. The default behavior in a table view when you drag is to select the rows. To get drag and drop behavior, you have to implement a couple of methods to conform to NSDraggingSource protocol.

Hah, that's it. I was wondering if Disk Utility was checking whether it was running from the DVD or whether it was running from the hard drive, and doing different things depending on what it found. For example, I noticed that the Preferences menu item isn't shown when you're running it from the DVD.

I did a class dump on the Disk Utility executable and found the following:

@interface DUAppDelegate : NSObject {
BOOL runningFromCD;
}
- (BOOL)runningFromCD;
- (BOOL)checkRunningFromCD;
@end

So, sure enough, it looks like it's checking to see whether it's running off the CD, and if so, will set itself up differently. (Translated to "English", that stuff above basically means that that main helper/controller object has a true/false property for whether or not Disk Utility is running from the CD, and two "methods", or functions that it executes, that set/get the value of that property).

I'll submit an official bug against this when I get a chance, and I'd encourage you to send feedback about it as well. If you want, you can copy and paste the information above and include it as more technical information that might help the engineers know what's going on.

Not sure what to suggest in the meantime....


Dual 2.7GHz PowerPC G5 w/ 2.5 GB RAM; 17" MacBook Pro w/ 2 GB RAM - Mac OS X (10.4.6)

I experienced this exact same problem this weekend while trying to upgrade the HD in my Macbook. I had backed up my original 60GB drive to an external firewire drive, and was trying to restore from it when I ran into this bug.

I called Apple and spoke to two front-line technicians and two prodcut specialists, and neither of them believed what I was telling them. I then went to the Apple store yesterday to at least show someone how this could possibly happen. After trying to explain a few alternate things that I was supposedly doing wrong, he believed me.

Here's the workaround we created:

1) Use a second Mac, in this case my son's Mac Mini
2) Boot the second Mac
3) Connect the firewire drive to the second Mac
4) Connect the Macbook to the second Mac via firewire (or if you have a firelite drive you can daisy-chain them
5) Boot the Macbook in Target/Firewire mode
6) Run Disk Utility on the second Mac and choose Restore
7) Choose the Firewire drive as the source and the Macbook as the target
8) Run (and wait two hours for all the data to copy)
9) Disconnect and reboot

This worked for me as I am typing this message now on the upgraded Mac. It seems stupid that I had to essentially "borrow" someone else's Mac to do this, but I suppose I could have done it if I had another external drive which was bootable, like an iPod or another Firelite. In any event, it's lame but it works.

-Andrew

MacBook 2Ghz Mac OS X (10.4.6) 2GB, 120GB HD

Yeah, there's no doubt about it, this is a true bug. And a fairly significant one, I would think. Until they get it fixed, they'll be shipping thousands of Macs whose install DVDs won't have that Restore capability available in Disk Utility.

Even if they get it resolved it's not going to help us, since I doubt they're going to send us a new software restore DVD that has that bug fixed.

Dual 2.7GHz PowerPC G5 w/ 2.5 GB RAM; 17" MacBook Pro w/ 2 GB RAM - Mac OS X (10.4.6)

OK, this has been filed as 4602376 .

I'd encourage you to submit feedback as well.

Dual 2.7GHz PowerPC G5 w/ 2.5 GB RAM; 17" MacBook Pro w/ 2 GB RAM - Mac OS X (10.4.6)

Is there a command line way to do a restore of an image?
I have to do a new install to check if my Mac is panicing because of hardware or software :((



MacBook Pro Intel Mac OS X (10.4.7)

Where does one send feedback. What is the link?

Same problem here on 2.0Ghz MacBook

I am trying to use the asr command via cmd prompt while booted to the OS Install DVD. Command I have used:

asr restore --source [source dev entry] --target [target dev entry] --erase

(to find your /dev entries, type mount at the command prompt to get a list)

See above post for more info on asr function (use at your own risk).

So far it is 15% done so looks promising.

my exact command (will be different on your machine): asr restore --source /dev/disk7s2 --target /dev/disk0s2 --erase

Not sure how, but it looks like it knows where my MacBook restore image file (sparse image created with SuperDuper!) . Probably because I first went into Disk Utility and File>Mount Image, mounted the image file first.

HTH, YMMV, yada yada..

Update: Using the asr function worked perfectly. Remember to first mount your image using Disc Utility on the Install DVD, then quit Disk Utility and go to Terminal (also on the DVD).

Type in "mount" to see the mounted disks and their /dev points.

I had to use the option --erase because without it, it would not copy (not enough disk space), but it may work either way for you. Now knowing that it works 100% perfect (and fairily fast for ~56GB restore image) I would recommend using --erase to erase the target disk before restoring.

asr restore --source [source dev entry] --target [target dev entry] --erase