[larkost]

I don’t know what you are running into, but I can assure you that it generically works. I have put a number of InstaDMG-created images into DeployStudio this was very successfully. You do have to start up the client after you make the move since DeployStudio does not refresh the list after it has started up (meaning the clients, not the server).

[larkost]

I recently made a less-than vanilla Intel 10.4.11 image, and can say that when creating it while standing on 10.5.8 things went fine. So it is possible, but I was not aiming for a vanilla image, so did not record anything (just base + 10.4.11 combo). My similar try with PPC was unbootable, but I have not given it a second go to see if I can figure that out.

[larkost]

I have done this a few times recently, and it is really simple:

1) Make sure that you are running on 10.5.8. I have only done this from Intel machines (but have verified that the images work on PPC hardware).

2) Get your 10.5.x installer disk in place (use the importDisk.py tool with the –legacy option if you have not already created you dmg copy).

3) sudo path/to/instaUp2Date.py –process 10.5_vanilla

It is really that easy.

[larkost]

The chances that InstaDMG is going to get you any different result is near zero.

Try this:

1) Reboot (just to be certain you don’t have things open)

2) Run: sudo instaUp2Date.py –process 10.5_vanilla

If that works, then you know the problem is with your modifications. And I am pretty sure that it is going to work, since I have run it a few times in the last couple of days.

[larkost]

I think I finally see a possible difference: you are running on PPC hardware. My only PPC hardware is running an old server, so no testing has been done. I will see if I can find some PPC hardware to try things out on.

I have just confirmed that 10.5.8 image creation seems to be working fine on Intel, including the iLife updaters.

[larkost]

The debug log is going to have more details, try perusing that near the line from “17:37:34”. My guess is that a .dmg failed to mount, and a wild guess from there is that the .dmg was already mounted. Right now InstaDMG does not handle that case well.

[larkost]

[QUOTE][u]Quote by: Gary+Bernstein[/u][p]So, are you saying that the 1.6 release should work fine if I put it on a 10.5.8 machine to create a 10.5 disk image?[/p][/QUOTE]

In a word, yes.

[larkost]

A few comments:

– It does not really matter if this is in “System Settings” or another section, I would put it in “System Settings” but in this case it is unlikely to interfere with other things (or be relied upon by others).

– If you are getting a message about an error in the config file, the problem might well be the spaces-vs-tabs issue. To emphasize this the format is:
[code][tab][tab][tab][/code]

The user-visible-name can have spaces, or anything else (other than tabs in it).

– Rather than change the vanilla catalog file, create your own and include the vanilla catalog file. That way when the vanilla file gets updated you don’t have to make changes to your file to egt the updates. A line like this would work:

[code]include-file: 10.6_vanilla[/code]

[larkost]

The latest 10.5 requires the chroot that I put in for 10.5, but that same system will not work for 10.6, the installer changed, and Apple has recently told me that they don’t consider this a bug/problem that they are going to fix. Without changes from Apple there is probably no chance that I can fix this.

So if you are building 10.5 or 10.4 images then you need to be running from 10.5 (the latest version please). If you are making 10.6 images, then run 10.6 (once again: latest version). I should probably code this restriction in, like I have the one for not being able to create a newer version on an older OS.

[larkost]

For the record: the probable issue was that 10.5.6 did not support this model of computer, and 10.5.8 did. It was probably close enough to that was supported under 10.5.6, but minus some drivers to properly support the sound system.

[larkost]

Where is the world did you get a .cdr image? In any case, if you need to use this one, then your best bet is to convert it to a main-line .dmg file. For sanity reasons I have put in the check you are running into to track what base disk image is in use, and we are going to be going farther in that direction later, so it is a good idea to get lined up for that (most people should not have to worry about this, you are in a weird case).

Assuming that this is a .cdr that hdiutil can recognize (you are hosed otherwise), you can use a command line this to convert it:
[code]hdiutil convert /path/to/image.cdr -format UDBZ -o ‘Mac OS X Install DVD.dmg'[/code]

I do want to sound the note of caution here: the .cdr format is a really strange bit. It makes me think that there is something odd going on here, namely that it is a “hackintosh” image (they are the only ones using that format… for whatever reason). I would be really leery of trying anything involvine “hackintosh” images with InstaDMG. There are real chances that you are not going to get what you expect, no matter what it is you are trying to do.

[larkost]

I use a FireWire 800 external 2 disk RAID (so the box is what provides the RAID) in stripe (RAID 0) mode, and see a nice 40% speedup. It cost me less than $200 for 2TB (not that I use any of the space, this is only used for InstaDMG development). I did a bunch of benchmarking and came out with the idea that the FW800 buss was the limiting factor. I am happy with that, as it means I am doing the best I can with the hardware I have. Oh… and the external disk actually benchmarks faster than my internal disk, something I was not expecting. Letting InstaDMG work on both is what gets me the nice speed boost.

[larkost]

2 drives is the fastest configuration. InstaDMG is always reading from one source, and writing to a second, and at one point reverses the direction. So 2 disks is the optimal solution, you just want to make each one as fast as possible.

[larkost]

To amplify this, InstaDMG is almost entirely limited by the speed of the disks. CPU and memory almost don’t come into play at all. An older computer with faster disks can produce an image faster than a newer computer that is more limited by its disks.

I don’t have any solid-state drives to play with at the moment, but I suspect that these would make really disks for image creation.

[larkost]

There is no such thing as normal. It all depends on how fast your second drive is. You don’t talk at all about what your second drive is. If it is a second volume on the same drive, then that is exactly what I would expect (ie: no difference), or if it was a second drive on the same IDE channel. If you tried to use a bus-power drive (ie: a laptop drive), or something over USB then you could actually make things slower.

I will take a look over the code again tonight, to confirm that nothing has messed up that setting, but you have not given enough information to determine if this expected or not.

[Author]

Posts