[larkost]

1) On the documentation front, sadly this has not been kept up, and it could be argued that it is my fault, since I am the one who is making chances to the process without creating end-user documentation for it. But most of the time I have put into documentation has been creating slides for conferences. We did have a few people along the way talk about doing documentation, but nothing has ever happened from it. The most recent work of documentation was John DeTroy’s [url http://web.me.com/johnd/JohnDs_Site/Tips_%26_Tricks/Entries/2009/4/29_Sys_Mgmt_Add-ons.html%5DTips & Tricks[/url] on it, but that is not exactly comprehensive. There is also some written about it in Kevin White’s [url http://www.peachpit.com/store/product.aspx?isbn=0321684524&rll=1%5Dbook on deploying MacOS X[/url]. But I have not seen the latter, so can’t say anything more than it is in the index.

2) InstaUp2Date auto-numbers things, and if there are going to be less than 10 items in a folder does not bother with the leading 0 (if there are 100 or more it uses 2 0’s etc…). You can go ahead and add them if you are using InstaUp2Date only to set things up, then make manual changes. But a better solution would be to create your own catalog file with the additions you want to make, and then allow InstaUp2Date to incorporate those. That when when a new update gets added to the vanilla catalog files (iLife Support 9.0.4 looks like it is finally coming out), it can be integrated without changing your setup.

I should also note that at some point the folders are going to go away and things are going to go in a more InstaUp2Date-like direction… whenever I can get to it… *sigh*.

[larkost]

There is nothing about those folders that can’t be copied to places. Although InstaUp2Date might not be happy if you have missing updates and it can’t go out on the net looking for them. But InstaDMG itself should work fine. So you should be able to take the folder from one computer to the other after populating it with updates, and it will work fine.

I am surprised that there are places that are this locked down. I guess I am just used to working for places that sit on very large internet connections, and trust their employees.

[larkost]

I am pretty sure that it does not work, since there are some things that need to happen durring the instal that we are not doing. I will say simply that MacOS X Server is not in my list of things to work on, but I am open to submissions from anyone who would like to get it working. I just have no need for it myself, and lots of itches that need scratching already.

I do know that one person was working on this for a while, and his code is still in the repository, but don’t really have much more to offer than that.

[larkost]

Absolutely, it should be pre-scanned and ready to go. You can use anything that uses the ASR system to restore it, so: command line asr, Disk Utility, Bombich’s NetRestore, Apple’s NetRestore, DeployStudio, Caspar’s system, PSU Blast, etc… Since everyone is using the same underlying system to deploy full images it creates a nice nitch for tools like InstaDMG.

[larkost]

It could be your firewall messing with your outbound connection, especially if they filter things and/or have a proxy in place. I have never worked in an environment like that so don’t know what to say.

– Yes, if you are trying for a 10.6 image, then you need to be booted from 10.6.

– Yes, the “svn” line pulls down the latest version.

– The first half of the final line creates an image of the Installer DVD that is in your DVD drive, so that only needs to be run once.

– The second half of the final line (everything after the &&) uses InstaUp2Date to setup the BaseUpdates and CustomPKG folders for a “vanilla 10.6” run. At the moment that is all the updates for a 10.6.2 image that should not have anything waiting for it in Software Update (except computer specific stuff and iLife Support Update 9.04, since they have not released it otherwise). Since you don’t have all of those packages already setup it will download them for you.

– The second half of that last line also include the “–process” flag which tells InstaUp2Date that once it has things setup it should go ahead and run InstaDMG with the settings it has.

– The design of InstaDMG is to make an image that is not dependent on your hardware. At the moment everything works great since there really is no “special” hardware out there. The last bit of this (overlooking the iMacs that came out right before 10.5 that were brought back into the flock with 10.5) was when some computers had DVD drives and some did not: the DVD software would only install if you had the DVD drive on the hardware you were on. The only other thing to be wary of is new hardware. If it shipped after the last “dot update” then it has special support for that hardware in the OS it came with (which is a special build). Almost always (except for cases like those iMacs) you just have to wait for the next “dot update” and everything is back to normal.

– And there is an important note: what this produces is an “image” not an “installer”. The distinction is that installers apply over the files that are already there (“upgrading” it), where as a restore replaces what is there completely (destroying all data) but is much, much faster (and a bit cleaner).

[larkost]

So there are a lot of point to cover, and I am not going to cover everything:

1) The “-I” (capital i) specifies a specific image to use as the base image. The “-b” option specifies a folder to look for the first disc image and additional ones. Think of the former as the “new style”. The “-J” option allows you to specify the other disc that you want open the whole time (to round out the behavior that was in the “-b” option). I don’t actually expect people to be using the “-J” option very much.

2) A similar story goes for the “-K” option. The old way of thinking is that the was the “BaseUpdates” folder (-u) and the “CustomPKGs” folder (-c), I am moving away from having these folder hard-coded and towards having an arbitrary number given in the order you want installed from with the “-K” option. InstaUp2Date does not yet drive InstaDMG this way, but I would like to get to that.

3) The “restore after build” code was rather leftover. Other than touching it when I changed variable names it was pretty much exactly as I inherited it, and I have never run it. I am not sure if anyone else has used it at all, as this is the first bug-report on it. Since someone evidently is using it, I just to a pass through it tonight and made a bunch of changes to it. As it happens the project that I am playing hooky from with these changes is all about restoring images, so my mind was already primed for it. If you wouldn’t mind running it to see if it works, as I am not setup for it, so the code is un-tested. It will probably be checked in as rev257. The two main fixes:

a) Changed to using the /dev/ entry for the volume you are restoring to. You can provide the volume as a mount point, as a full dev entry (/dev/disk0s2), or as a partial dev entry (disk0s2). It will sanity check that there is a block device there, and that it is not the current root volume. This should take care of

b) I changed the bless system to better handle things (such as using /dev/ entries), and putting on the label. I also removed the -nocheck altogether, as a little longer restore is worth the verification for things like this (you don’t want a disk error messing with you).

4) The best way to install the developer tools is to just download them from ADC, then use the dmg directly. Since everything is in the right place on the dmg it will be in the right place durring the install. I only look in the first level of a dmg for installers to make sure I can handle the dev tools. Note that my imaging needs have not included the dev tools for a while, so I am not sure that everything is kosher with that install on 10.6. You might want to include an InstallerChoices file to get things right for your environment.

5) iWork installs cleanly. It is iLife that has all the problems (needs chroot, the iLife Updates have bigger problems and need InstallerChoices files to work).

[larkost]

First off the reason you are running into this problem is that on 10.6 I am disabling the chroot jail because it was killing the process. I have a very good idea of what is going on now, and durring Macworld had an odd thought about how to fix it, but need to put in some time testing it, but I am working on another InstaDMG project at the moment (maybe that one will be out this weekend). So for 10.6 your command winds up getting run against your boot volume.

While this sort of thing is why I put in the chroot jail in the first place, I do consider this sort of thing bad scripting on the package maker’s part. But the solution is really easy: you just have to reference the “target” drive that the installer is feeding you as the “$3” (third) argument to your script.

And you are also being a bit creative with the SetFile command, and there is a better way: include SetFile in the resources of your package, then reference it using the “$2” argument provided to your script. With this setup you don’t have to take care of deleting anything (something I am always scared of doing), and you don’t have to play weird games with the chroot environment: it will always be where you expect it to be.

So here is your modified script (assuming that you put SetFile in resources):
[code]#!/bin/sh
“$2/Contents/Resources/SetFile” -a V “$3/Library/Scripts/script.sh”[/code]

Note that I am quoting both paths in case they have spaces in them. This is also off-the-cuff and untested, so you might need to do some troubleshooting.

Overall I would say that you probably should not be trying to hide this. Smart users are going to find it anyways, and not-so-smart users are probably not going to be looking in /Library/Scripts in the first place. If you are hiding things in this script, then there is probably a better way.

[larkost]

Your problem with the svn command sounds like you were not connected to the internet at the time. In case you missed it, that command brings down the latest version of InstaDMG from the code.google site. So if you don’t have a working internet connection at the time it is going to fail like that.

You never need to move any files at all around from the Installer DVD, I don’t quite understand how you got that idea. Much better idea: connect to the internet, put your 10.6.0 installer DVD in the drive (that is the only 10.6 retail disk available to my knowledge), open Terminal.app, and run the following commands:

[code]cd ~/Desktop
svn checkout http://instadmg.googlecode.com/svn/trunk/ instadmg
sudo -s ‘./instadmg/AddOns/InstaUp2Date/importDisk.py –legacy –automatic && ./instadmg/AddOns/InstaUp2Date/instaUp2Date.py –process 10.6_vanilla'[/code]

You will have to type your password for the second command. And I should note that the whole process is going to take 2+ hours (depending on the speed of your disks and internet connection for downloading all the updates).

At the end of the process you will have a nicely baked “slipstreamed” 10.6.2 image with all the latest updates. The “importDisk.py” part of this is only necessary the first time, as that will suck in a copy of your installer disk to be used on subsequent runs.

[larkost]

I think that there are multiple problems here, and most of them are not InstaDMG related:

1) InstaDMG at the moment requires you to be booted from 10.5 if you are installing 10.5. This is because of changes in the installer. I would like to see if I can relax this, but don’t have the time to fiddle with this at the moment, let alone do the testing to prove that it worked.

2) InstaDMG is for creating images that are going to go on a lot of computers. It sounds like you are only working on one, so it is really pointless to use InstaDMG. Just use the installer if you are only working on one computer.

3) There is a decent chance that your computer is not compatible with 10.5.anything if it came with 10.6. Every new computer has its own quirks in regards to graphics systems and cooling, and the OS that came with it is usually the first one to support that combination. In some cases you can get away with it, but I would have serious worries about performance and heat problems.

[larkost]

The closest thing to an archive at the moment is on the MacEnterprise site:

http://www.macenterprise.org/macworld-2010-slides

I am trying to encourage other presenters to put their slides up, but you get what you get.

[larkost]

Thank you to everyone who responded, the presentation went really well (a bit long…) and the slide turned out really well. If anyone wants to see the slides my co-presenter has posted them at this link:

http://clc.its.psu.edu/Labs/Mac/Resources/Presentations/MW2010-IT871.zip

I did remove the “who’s using” slide form this version of the slides (among other changes) as I hadn’t asked for explicit permission to have it anywhere other then on-screen for the conference. I don’t think I am going to go back and review that decision, but at some point we should have a place where companies can put their names as users.

[larkost]

A big problem with the current createuser system is that you wind up reusing the same package id (CFBundleIdentifier) for each one you use. The installer can get a bit particular about this and will start deleting things from the first one when you install the second if you don’t change the package id of the second. Compounding that is how the packages don’t work under the chroot tricks I have to pull for 10.5 (and wish I could pull for 10.6). I have started and abandoned a few replacements, and will try again for something that works a bit better in this regard.

For the moment I would do two things:

1) In the second pacage open it back up and change the “CFBundleIdentifier” (in PlistEditor this will be the “Bundle identifier” line) to something other than “edu.uc.daap.createuser.pkg”. In the example below I use “edu.uc.daap.createuserNumberTwo.pkg”)

2) Change the line that looks like this:
[code]CHROOT_EXCLUDED_CODES=(“edu.uc.daap.createuser.pkg”)[/code]
to something like this:
[code]CHROOT_EXCLUDED_CODES=(“edu.uc.daap.createuser.pkg” “edu.uc.daap.createuserNumberTwo.pkg”)[/code]

note that there is a space, and nothing else between those two entries.

Additionally, please always post the following information when asking for help:
1) The version of the OS you are running
2) The version of the OS that you are installing
3) The version (including revision) of instaDMG you are running

Without those bits it can be difficult to figure things out that seem obvious to me.

[larkost]

Ok , rev147 has InstaUp2Date using the new checksumming code. The only difference (other than for folders) right now is that you get a progress meter while it checksums things.

[larkost]

Thanks guys! I will put both your organizations on the slide. I am getting a really nice response from the three places I put out this notice, and so it looks like I will have a nice slide there.

If others would like to put their names on the slide, I can make changes up to the day of the presentation, so the Saturday the 13th.

[larkost]

The iLife support bit is a nasty one, and something I have not been able to figure out how to handle without making changes to the installer. The problem is that it looks at the root volume, and if that does not need the update it skips it. Unfortunately this is hard-coded to look at the root volume and the only way I have to skip that is to use chroot, and the installer does not work with that on 10.6. I suspect that Bonjour is the same problem.

[Author]

Posts