dmg unable to mount in 10.3.9

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.

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

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?

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.

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).

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.

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

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?

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.

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

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.

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.

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.

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

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?

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. … :slight_smile:

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. :frowning:

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

This is fixed in DropDMG 2.8.3.