dmg unable to mount in 10.3.9

[RockHound]

I recently upgraded to DropDMG 2.8.2, and I noticed a change in our software distribution that may coincide with that new release. Sometimes our customers are now unable to mount our dmg file they download from our server. The problematic Macs all have 10.3.9, though I can't say that Panther can never mount our dmg.

We've had no problems with the dmg prior to 2.8.2, on Panther, Tiger or Leopard.

The preference settings I use are:

Format: .dmg zlib-compressed
Encoding: none (the mount on 10.3.9 also failed with BinHex and MacBinary encoding on one customer's mac)
Auto-open image window after mounting

Is it possible that 2.8.2 changed something that could cause this? What can I do to correct this problem?

Thank you.

[Michael Tsai]

Is it possible that 2.8.2 changed something that could cause this?

I don’t think so. There were no changes to the way it creates disk images.

What can I do to correct this problem?

What happens when they try to mount the image on 10.3.9? Has anything else changed on the Mac that you use to create the images?

[RockHound]

I don’t think so. There were no changes to the way it creates disk images.

Okay, it must be something else.

What happens when they try to mount the image on 10.3.9?

The reported error is something like "The following disk images failed to mount Mac_timezattack: no mountable file system". The dmg in question is Mac_timezattack.dmg (among others).

Has anything else changed on the Mac that you use to create the images?

That may be about the time when I upgraded from 10.5 to 10.5.1.

Is there a way to validate the mountability of a dmg for all versions of 10.3.9+?

And, is there anything that a user can do to his/her 10.3.9 Mac that would cause an otherwise mountable dmg to generate the given error message?

I realize that these questions are getting outside the realm of DropDMG. Thanks for any advice you can give me.

[Michael Tsai]

Is there a way to validate the mountability of a dmg for all versions of 10.3.9+?

Not that I’m aware of. I’ve never heard of an image that mounts on some OS versions but not others (except where the format is too new, which isn’t the case here).

And, is there anything that a user can do to his/her 10.3.9 Mac that would cause an otherwise mountable dmg to generate the given error message?

It’s certainly possible that there’s something wrong with a given user’s OS installation. That I’ve seen. But it seems unlikely to affect multiple customers.

The only time I’ve seen that particular error message is when trying to make an image of a read-write volume/image while it was mounted/in use.

[Red Marble Games]

I'm getting exactly the same behavior from multiple users who are on 10.3.9 -- "no mountable file systems." This started happening to me when I upgraded to Leopard -- could be 10.5 or after I upgraded to 10.5.1, I'm not sure. But it's not a fluke that is unique to the OP -- I've had several reports of this behavior from 10.3.9 users of my software.

Thanks,

Mark

[Michael Tsai]

I'm getting exactly the same behavior from multiple users who are on 10.3.9 -- "no mountable file systems."

What disk image settings are you using? How are you creating the images? Do you have a URL where I could download one of these images to investigate further?

[Red Marble Games]

Settings are the same I have always used, so I think it's a Leopard issue:

-- zlib-compressed (Mac OS X 10.1)
-- no encryption, no limit to segments, no encoding, no license agreement
-- use custom icon
-- auto-open
-- Internet-enabled

Is there an email address where I can send you a link to one of the images people are having trouble with? Would rather not post publicly.

Thanks.

[Michael Tsai]

Is there an email address where I can send you a link to one of the images people are having trouble with?

Please send it to dropdmg@c-command.com.

[Michael Tsai]

Is there an email address where I can send you a link to one of the images people are having trouble with?

Thanks for sending me the .dmg file. Indeed, when I try to mount it on Mac OS X 10.3.9 it verifies and then reports that there are no mountable filesystems.

DropDMG’s Get Image Info… command shows that the image uses a GPT partitioning scheme. This is a new disk format that Apple introduced for the Intel Macs, and it’s only supported by Mac OS X 10.4 and later. DropDMG does not use GPT when creating a new image from a file or folder, so my guess is that you created this image by converting an existing image or drive that was already in GPT format. To get an image that works on 10.3, you could create a folder, copy the contents of your existing image into it, and then drag the folder onto DropDMG.

[Red Marble Games]

Actually, I created the image in DropDMG -- first as a read-write volume, to which I made some changes in the Finder (resizing icons, etc.); then I ejected and dropped the read-write volume onto DropDMG to convert it into a compressed dmg. So I guess the Finder rewrote the read-write image with GPT when I made changes to it? That seems odd, but I guess it's the only explanation -- I don't create disk images with any other tool. ...

Thanks for looking into it. I'll try doing the compressed dmg to start with, without the interim steps, and see what happens.

[Red Marble Games]

Actually, here's an interesting thing: out of curiousity I just created a disk image with DropDMG, nothing funky, just the settings listed in my post above, a simple compressed (10.1) image. Then I did a Get Image Info command on it, as you did, and in the window that appears there are a number of references to a GPT Header and GPT Partition Data.

I created the image on a MacBook Pro using Leopard. So is it possible that DropDMG is using GPT without meaning to, perhaps just a default setting when running hdiutil on an Intel Mac under Leopard? That does seem to be the problem.

[Michael Tsai]

Actually, here's an interesting thing: out of curiousity I just created a disk image with DropDMG, nothing funky, just the settings listed in my post above, a simple compressed (10.1) image. Then I did a Get Image Info command on it, as you did, and in the window that appears there are a number of references to a GPT Header and GPT Partition Data.

Thanks for the follow-up. However, I was not able to duplicate that behavior here. What did you drop on DropDMG?

So is it possible that DropDMG is using GPT without meaning to, perhaps just a default setting when running hdiutil on an Intel Mac under Leopard?

Yes, I guess the root problem is that hdiutil’s default settings have changed, and it now uses the GPT partition layout for new blank disk images when you’re running Leopard on an Intel-based Mac. With a PowerPC-based Mac or when using Tiger it does not use GPT.

I haven’t yet found a case where this causes a problem with DropDMG, however. Does it help if you put whatever you were imaging in an empty folder and then drop the folder onto DropDMG?

[Red Marble Games]

I just dropped an application bundle on DropDMG, nothing funky.

Dropping the application in a folder first does produce a disk image with no references to GPT in the Get Image Info... window, so I guess that image likely would open on 10.3.9 ... that's not a great permanent solution, though, of course -- hope you'll consider finding a way to get the old behavior back. ... :)

[Michael Tsai]

I just dropped an application bundle on DropDMG, nothing funky.

That’s what I suspected, and why I suggested putting it in a folder, but it turns out that my test earlier today to see whether it worked was faulty. I used Get Image Info… on the wrong image. :-(

Now that I know where the problem is, I should be able to fix it soon.

[Michael Tsai]

So is it possible that DropDMG is using GPT without meaning to, perhaps just a default setting when running hdiutil on an Intel Mac under Leopard? That does seem to be the problem.

This is fixed in DropDMG 2.8.3.