PDA

View Full Version : Scheduled backup fails with "Failed to mount.." error


cortina
04-02-2007, 09:55 AM
Hi,
My scheduled backups have running happily every night for several months. About a week ago they started to fail with the same log message:

| 09:28:00 PM | Info | SuperDuper!, 2.1.4 (82), path: /Applications/SuperDuper!.app, Mac OS 10.4.9 build 8P135 (ppc)
| 09:28:00 PM | Info | Started on Mon, Apr 2, 2007 at 2:28 PM
| 09:28:00 PM | Info | Source Volume: Macintosh HD, mount: /, device: /dev/disk0s3, media: WDC WD2500JD-41HBC0, interconnect: Internal ATA, file system: "Journaled HFS+", OS: 10.4.9 (8P135), capacity: 232.76 GB, used: 36.89 GB, directories: 125244, files: 568321, ejectable: NO, ACLs: Disabled
| 09:28:00 PM | Info | Target Image: /Volumes/Backup/G5 Backup/G5-backup-full.sparseimage, name: G5-backup-full
| 09:28:00 PM | Info | Copy Mode : Smart Update
| 09:28:00 PM | Info | Copy Script : Backup - all files.dset
| 09:28:00 PM | Info | Transcript : BuildTranscript.plist
| 09:28:00 PM | Info | PHASE: 1. Prepare to Copy Files
| 09:28:00 PM | Info | ...ACTION: Preparing Macintosh HD
| 09:28:00 PM | Info | ......COMMAND => Verifying the integrity of volinfo.database
| 09:28:00 PM | Info | volinfo.database OK
| 09:28:00 PM | Info | ......COMMAND => Enabling permissions on Macintosh HD
| 09:28:00 PM | Info | Refreshing Disk Arbitration ...
| 09:28:00 PM | Info | ......COMMAND => Verifying that permissions are enabled for Macintosh HD
| 09:28:00 PM | Info | Permissions on '/' are enabled.
| 09:28:00 PM | Info | ...ACTION: Mounting G5-backup-full
| 09:28:00 PM | Info | ......COMMAND => Preparing G5-backup-full
| 09:28:00 PM | Info | ......COMMAND => Setting ownership and access modes for '/Volumes/Backup/G5 Backup/G5-backup-full.sparseimage'
| 09:28:00 PM | Info | ......COMMAND => Mounting G5-backup-full
| 09:28:05 PM | Error | load_hdi: IOHDIXControllerArrivalCallback: timed out waiting for IOKit to finish matching.

I can manually mount my backup image and run the backup but this isn't really a long term solution :p
Any thoughts or advice much appreciated.
TIA
Rob

dnanian
04-02-2007, 10:18 AM
Try restarting your Mac, Rob. This is a problem in the low-level IOKit that starts to generate errors, but restarting usually clears it up.

cortina
04-02-2007, 10:44 AM
Try restarting your Mac, Rob. This is a problem in the low-level IOKit that starts to generate errors, but restarting usually clears it up.
Hmm. I thought I'd rebooted recently, but not being a WinDoze box it's difficult to remember :rolleyes:
I'll give it a try & report back.
Thanks Dave
Cheers
Rob

cortina
04-05-2007, 03:15 AM
... I thought I'd rebooted recently ... I'll give it a try & report back.
Unfortunately, no joy there Dave. I've rebooted a couple of times & my nightly backup is still failing for the same reason. I guess I'm going to have to create a new image & start again :(
Any other thoughts?
Cheers
Rob

dnanian
04-05-2007, 08:36 AM
There are a very few systems out there where restarting doesn't resolve the issue, and yours looks to be one. What I'd suggest, rather than recreating the image, is opening it with Finder. Then, change your schedule to point to the mounted volume, rather than the image file itself. That will use a different method to mount, and should work. The only downside is that it won't eject the image when the copy is done.

billcole
04-09-2007, 11:47 PM
I started having the same problem, and as I am reluctant to reboot for this I did a little poking around and found that "hdiutil attach /path/to/image.spargeimage" kicks out the exact same error message as SD is logging, *but it does not fail* and a subsequent "hdiutil mountvol $devicename" mounts the image just fine.

Lacking a solution inside SD, I am following your suggestion of pointing to the mounted image, and having my post-backup script look for the image and unmount it if it is present.

dnanian
04-10-2007, 08:07 AM
Well, the thing is, it is indicating failure, since that message is coming out on "stderr", Bill. (We use hdiutil internally to do the mount.)

billcole
04-11-2007, 11:22 PM
Emitting a message on stderr is not necessarily an indication of failure. If you are actually running /usr/bin/hdiutil with system() or some other sort of callout, then the right check for success or failure would be the return code, not whether stderr gets some text. I can't speak to all cases, but at least in my case hdiutil emits a message on stderr even as the 'attach' actually succeeds (a disk device node is created) and hdiutil returns a zero (success) return code.

dnanian
04-12-2007, 07:36 AM
We recognize that, Bill. :)

rossb
04-17-2007, 01:03 PM
I am having the same "failed to mount" error on a 2.16Ghz Intel iMac 21", OS X 10.4.9

I can't use the alternative method suggester either, as after selecting the mounted volume instead of the disk image, it disappears from the Target menu when you eject it.

Any other solutions?

Ross

dnanian
04-17-2007, 01:49 PM
I don't understand, Ross. Don't eject it...

otter
05-08-2007, 11:12 PM
Unfortunately, no joy there Dave. I've rebooted a couple of times & my nightly backup is still failing for the same reason. I guess I'm going to have to create a new image & start again :(
Any other thoughts?
Cheers
RobHaving the same problem. Could this be due to using a specific drive to store the backup? I'm using a Buffalo 250GB Firewire drive and it's been consistently slow waking up for anything.

dnanian
05-09-2007, 07:06 AM
As far as I know, it has nothing to do with the drives, how long it takes to wake up, or anything similar. It's a weird, low-level issue with the IOKit that only hits some users. The alternative method above should work for you if restarting your Mac does not.