InstaUp2Date — saves me a step and gives me an extra step…or?

[typofonic]

Hi,

I’m new to InstaUp2Date.

I’ve created a catalog file (see the end of my post), where I’ve included the iLife and iWork update vanilla catalogs that comes with InstaUp2Date.

Usually I’ve just kept all of my custom packages in the CustomPKGs folder and numbered them manually in order to install them in the proper order. Now with InstaUp2Date it seems that I have to put the full path to my custom packages in the catalog file as well, when I add a new custom package to my build train, instead of just putting them in the CustomPKG folder prefixed with a number. That seems like an extra step compared to just using InstaUp2Date

So I saved a step and I got an extra. Or am I missing something?

I would like to install iWork for instance, before running the iWork update (which is in the iWork09_Updates.catalog).

Catalog file:
——————
include-file: 10.6_vanilla.catalog

OS Updates:

Apple Updates:

System Settings:

Third Party Software:

Software Settings:

include-file: iLife09_Updates.catalog
include-file: iWork09_Updates.catalog

[dead2sin]

You want everything in the InstaUp2DatePackages folder. If they are there, you do not need the full path.

Not sure if you checked it out already or not, but [url]http://www.osxdeployment.info/wiki/InstaUp2Date_Guide[/url] has some good info on best practice for using InstaDMG, etc.

Nate

[typofonic]

Thanks for your answer Nate! Actually the guide you linked to, as well as a podcast from University of Utah about instadmg, was the basis for my setup.

Ok, so I don’t need the full path in the catalog. But DO I need to add the file names of packages to the catalog, in order for the packages to install?
Or put another way, is it enough to ONLY put every new custom package in the InstaUp2DatePackages folder, or do I ALSO have to add the filename to the catalog at the same time, in order for InstaUp2Date to install them?

[typofonic]

From the example below it does seem that it’s necessary to put the filenames of each package in the catalog:

I’m surprised though that the iLife upgrades in the example are put directly in the catalog, and not just included in the end of the file with “include-file: iLife09_Updates.catalog” – isn’t it possible to do it that way instead, to make the setup more modular ore does the includes always install before the rest of the packages in the file?
—–
# This is the catalog for the Base Leopard Image

include-file: Base.catalog

Output Volume Name = Macintosh HD
Output File Name = Snowleopard-1.0.0

System Settings:

Third Party Software:

Office 2008 SP2 Office Installer.mpkg sha1:021a599899d12958bc9aa02d0b9a5002c0b8d79f

Office 12.2.5 Office 2008 12.2.5 Update.mpkg sha1:c742570712129dfc4534de08a4250c41f9c83a59

iLife 09 iLife09.mpkg sha1:d58806ffbea052b45f0826d25ff41322333f6305

iPhoto_81 http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/061-6710.20090818.Cwe4R/iPhoto_81.dmg sha1:e6b1bf494881ba3b357f7d023e2c434e8caf06c8
GarageBand51 http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/061-6633.20090803.fr0Pp/GarageBand51.dmg sha1:7c771583c826c8c70e5c5f01d925e28636d0364d
iDVD704 http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/061-6153.20090604.FqicZ/iDVD704.dmg sha1:d9b6fd4b1a4c8f875dc1a8ca3c8dd31ebae5e1c0
iLifeSupport904 http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/061-7595.20100209.vgbyh/iLifeSupport904.dmg sha1:7cda1492d1bab91383b5738a7cda2cde24f72d2c
iWeb301 http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/061-5977.20090626.B8952/iWeb301.dmg sha1:90a1616428c56f086a41e29528a84971f35f3842
iMovie806 http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/061-7979.20100325.Mbnyh/iMovie_806.dmg sha1:5b63ad631d7a9b9e668db5cb1edf4d421c8af87f
iPhoto_812 http://supportdownload.apple.com/download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/Mac_OS_X/downloads/061-7747.20100330.xSwe3/iPhoto812.dmg sha1:b7cdf308a45a2ce5b8e1cbf3a78cbaa17dc62c28

Apple Updates:

Software Settings:

[dead2sin]

The minimum you need in a catalog is as follows:

Description Filename Hash

So for example, as you see in that example:

Office 2008 SP2 Office Installer.mpkg sha1:021a599899d12958bc9aa02d0b9a5002c0b8d79f

Office 2008 SP2 is the description, then there is a tab, Office Installer.mpkg is the file name and of course sha1:021a599899d12958bc9aa02d0b9a5002c0b8d79f is the hash. This is something each item in a catalog needs.

As far as modularality is concerned, you accomplish that via chaining catalogs together using includes. If you plan wisely, you end up with a very modular InstaUp2Date setup.

For instance, my setup at work for a staff image is as follows:

10.6_vanilla.catalog–>common.catalog–>basesnowleopard.catalog–>facultystaff.catalog

10.6_vanilla I always leave as is from the repo, or I update it if the repo isn’t most recent (which isn’t very often).

common contains things EVERY image I make will get. This includes Office, ClearReg and various other settings that every image I build contains.

basesnowleopard is the basis for my facultystaff image and this is stuff that every staff image gets. I make 2 flavors of staff image, so anything both need go here.

finally faculty staff has stuff taht only faculty staff get. This is specific to this image alone.

Now for a computer lab image, I use different admin passwords and various other software packages, so its build chain looks like this:

10.6_vanilla.catalog–>common.catalog–>labbasesnowleopard–>dhavidlab
or
10.6_vanilla.catalog–>common.catalog–>labbasesnowleopard–>dhimaclab

These builds are identical except for the last catalog. dhimaclab is 10gb and dhavid lab is 70gb. The last catalog makes all the difference (It has Avid, Final Cut and Pro Tools LE).

You will notice, they use the exact same first two catalogs. It took me a while to weed all the images down to their common items, but now that I have, I only need to update it once and all the images have the updates. I am guilty of manually placing the iLife updates in the catalogs manually for each image. I do this for my own sanity, but I am sure there is a better way to do it (I have not gotten there yet).

Nate

[typofonic]

Thanks a lot for your answer Nate. Now I think I understand how it’s supposed to work. I have set up a chain of catalog files, however InstaUp2Date wont recognize my OS X Install DVDs.

I’ve tried putting discs named
“Mac OS X Install DVD.dmg” in both the BaseOS folder and the InstallerDiscs folder, but I get one of two errors each time I run InstaUp2Date:
———————————
Finding the Installer disc for setup
Traceback (most recent call last):
File “./instaUp2Date.py”, line 665, in
main()
File “./instaUp2Date.py”, line 627, in main
foundInstallerDiscs = findInstallerDisc.findInstallerDisc(allowedBuilds=thisController.catalogFileSettings[‘Installer Disc Builds’])
File “/Volumes/Lacie/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc.py”, line 190, in findInstallerDisc
raise commonExceptions.FileNotFoundException(‘Unable to find OS Installer disc in any provided folder: ‘ + str(searchItems))
Resources.commonExceptions.FileNotFoundException: Unable to find OS Installer disc in any provided folder: [‘/Volumes/Lacie/instadmg/InstallerFiles/InstallerDiscs’, ‘/Volumes/Lacie/instadmg/InstallerFiles/BaseOS’]
——————————–
OR
——————————–
Finding the Installer disc for setup
Traceback (most recent call last):
File “./instaUp2Date.py”, line 665, in
main()
File “./instaUp2Date.py”, line 629, in main
foundInstallerDiscs = findInstallerDisc.findInstallerDisc()
File “/Volumes/Lacie/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc.py”, line 115, in findInstallerDisc
raise ValueError(‘In legacy mode the item “%s” was named like an installer disc, but was not a dmg’ % thisItem)
ValueError: In legacy mode the item “/Volumes/Lacie/instadmg/InstallerFiles/BaseOS/Mac OS X Install DVD.dmg” was named like an installer disc, but was not a dmg
———————————

I have tried with both a retail 10.6.3 disc saved manually using Disk Utility and one saved using the importDisc InstaUp2Date script.

The weird thing is that both discs work just fine with InstaDMG by itself, just not InstaUp2Date.

I’ve run “svn update” so I’m on the newest version.

Also I have tried commenting out the build number in the catalog files as suggested on the forums. No luck yet.

Any ideas?

Also, isn’t there an option to skip the checksum part of InstaUp2Date completely?

[dead2sin]

[QUOTE][u]Quote by: typofonic[/u][p]Thanks a lot for your answer Nate. Now I think I understand how it’s supposed to work. I have set up a chain of catalog files, however InstaUp2Date wont recognize my OS X Install DVDs.

I’ve tried putting discs named
“Mac OS X Install DVD.dmg” in both the BaseOS folder and the InstallerDiscs folder, but I get one of two errors each time I run InstaUp2Date:
———————————
Finding the Installer disc for setup
Traceback (most recent call last):
File “./instaUp2Date.py”, line 665, in
main()
File “./instaUp2Date.py”, line 627, in main
foundInstallerDiscs = findInstallerDisc.findInstallerDisc(allowedBuilds=thisController.catalogFileSettings[‘Installer Disc Builds’])
File “/Volumes/Lacie/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc.py”, line 190, in findInstallerDisc
raise commonExceptions.FileNotFoundException(‘Unable to find OS Installer disc in any provided folder: ‘ + str(searchItems))
Resources.commonExceptions.FileNotFoundException: Unable to find OS Installer disc in any provided folder: [‘/Volumes/Lacie/instadmg/InstallerFiles/InstallerDiscs’, ‘/Volumes/Lacie/instadmg/InstallerFiles/BaseOS’]
——————————–
OR
——————————–
Finding the Installer disc for setup
Traceback (most recent call last):
File “./instaUp2Date.py”, line 665, in
main()
File “./instaUp2Date.py”, line 629, in main
foundInstallerDiscs = findInstallerDisc.findInstallerDisc()
File “/Volumes/Lacie/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc.py”, line 115, in findInstallerDisc
raise ValueError(‘In legacy mode the item “%s” was named like an installer disc, but was not a dmg’ % thisItem)
ValueError: In legacy mode the item “/Volumes/Lacie/instadmg/InstallerFiles/BaseOS/Mac OS X Install DVD.dmg” was named like an installer disc, but was not a dmg
———————————

I have tried with both a retail 10.6.3 disc saved manually using Disk Utility and one saved using the importDisc InstaUp2Date script.

The weird thing is that both discs work just fine with InstaDMG by itself, just not InstaUp2Date.

I’ve run “svn update” so I’m on the newest version.

Also I have tried commenting out the build number in the catalog files as suggested on the forums. No luck yet.

Any ideas?

Also, isn’t there an option to skip the checksum part of InstaUp2Date completely?[/p][/QUOTE]

Import a disc using only –automatic (leave out –legacy) like so:
[code]sudo ./importDisk.py –automatic[/code]

This will put the build # in the disc name. Then, in 10.6_vanill.catalog, you can place your build # into the tag at the top if it doesn’t match any of them (ONLY do this if your 10.6.3 disc is a retail disc). I had to add my retail disc because it didn’t match any.

[code]Installer Disc Builds = 10A432, 10B504, 10C540, 10D573, 10D575, 10F569[/code]

Then try it again and see what happens.

Nate

[dead2sin]

Also, I am not sure of a way of disabling checksums, but I don’t suggest you do that anyways. It is an extremely helpful feature and assures that everything really IS identical every time you run it.

Nate

[typofonic]

Thanks! I actually followed this guide to the letter:
“http://www.osxdeployment.info/wiki/InstaUp2Date_Guide” and imported the image using “sudo ./importDisk.py –automatic”.

And I got a build number in the image file name. I just renamed it to Mac OS X Install DVD.dmg.
I added in the line “Installer Disc Builds = 10A432, 10B504, 10C540, 10D573, 10D575, 10F569” in all the catalogs and renamed the image back to “MacOS X Client 10.6.3 10D575.dmg” and it does the same.

When I run InstaUp2Date with the sample.catalog it finishes just fine, but with my own catalogs they error out like this:
[code]Finding the Installer disc for setup
Traceback (most recent call last):
File “./instaUp2Date.py”, line 665, in
main()
File “./instaUp2Date.py”, line 627, in main
foundInstallerDiscs = findInstallerDisc.findInstallerDisc(allowedBuilds=thisController.catalogFileSettings[‘Installer Disc Builds’])
File “/Volumes/Lacie/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc.py”, line 190, in findInstallerDisc
raise commonExceptions.FileNotFoundException(‘Unable to find OS Installer disc in any provided folder: ‘ + str(searchItems))
Resources.commonExceptions.FileNotFoundException: Unable to find OS Installer disc in any provided folder: [‘/Volumes/Lacie/instadmg/InstallerFiles/InstallerDiscs’, ‘/Volumes/Lacie/instadmg/InstallerFiles/BaseOS’][/code]

This is how the beginning of my catalogs look (I have three catalogs chained together with include):

[code]# Description

Installer Disc Builds = 10A432, 10B504, 10C540, 10D573, 10D575, 10F569

#Output Volume Name = Volume Name
#Output File Name = File Name

include-file: basic.catalog[/code]

I edit all of my catalog files with Textmate b.t.w.

I simply can’t figure out what I’m doing wrong here (I am using a retail build 10D573)?

P.S. I think it would be excellent to make an option to disable the checksum to save time. For the type of of small scale deployment I do, it’s not really worth the time, especially when troubleshooting (if that makes sense). Consider this a feature request — maybe a flag to be added to InstaUp2Date.py?

[dead2sin]

Are you using the untouched 10.6_vanilla.catalog, or were changes made to it other then the build number? If it can’t find the installer disc, it is not even getting past 10.6_vanilla then. I would grab a fresh copy of 10.6_vanilla.catalog from the svn, rename your current one or move it out of the way. Then, add your specific build to 10.6_vanilla’s build section at the top and try running just the vanilla catalog. If that works, then try one catalog up in the chain. You don’t have run a full build, just get to the point where it has found the installer disc and is about to build then control-C it to terminate. I suspect there is something wrong in the 10.6_vanilla catalog if it works for you in the example but not with your own catalogs. You should *never* edit the 10.6_vanilla catalog except for the build numbers and volume name if you want to change it. All the other items there are exactly what you need. No extra packages should be added to 10.6_vanilla that are non-Apple updates (normally 10.6_vanilla is updated pretty rapidly, so I have never had to really worry about this before).

Let me know what that does. You could also post your 10.6_vanilla catalog so we can see it. We might be able to pick out what is causing it to not find the installer. Make sure your catalogs are all linked correctly as well. 10.6_vanilla should not have any “include-file:” entries on it and I’d imagine basic.catalog would include 10.6_vanilla and on from there.

Nate

[typofonic]

[QUOTE][u]Quote by: dead2sin[/u][p]Are you using the untouched 10.6_vanilla.catalog, or were changes made to it other then the build number? If it can’t find the installer disc, it is not even getting past 10.6_vanilla then. I would grab a fresh copy of 10.6_vanilla.catalog from the svn, rename your current one or move it out of the way. Then, add your specific build to 10.6_vanilla’s build section at the top and try running just the vanilla catalog.

If that works, then try one catalog up in the chain. You don’t have run a full build, just get to the point where it has found the installer disc and is about to build then control-C it to terminate. I suspect there is something wrong in the 10.6_vanilla catalog if it works for you in the example but not with your own catalogs. You should *never* edit the 10.6_vanilla catalog except for the build numbers and volume name if you want to change it. All the other items there are exactly what you need. No extra packages should be added to 10.6_vanilla that are non-Apple updates (normally 10.6_vanilla is updated pretty rapidly, so I have never had to really worry about this before).

Let me know what that does. You could also post your 10.6_vanilla catalog so we can see it. We might be able to pick out what is causing it to not find the installer. Make sure your catalogs are all linked correctly as well. 10.6_vanilla should not have any “include-file:” entries on it and I’d imagine basic.catalog would include 10.6_vanilla and on from there
[/p][/QUOTE]
No changes were made to the 10.6_vanilla file. Actually the default 10.6_vanilla file contains the build number of my Install DVD.

I must have done something though to the 10.6_vanilla file though, because after I ran svn update, as you suggested, it was able to find the installer disc – succes! 🙂 Thanks!

Or maybe a fix was checked in within the last 3 days.

Because svn updated all of these files:
[code]U AddOns/InstaUp2Date/Resources/tempFolderManager.py
U AddOns/InstaUp2Date/Resources/containerTypes/volume.py
U AddOns/InstaUp2Date/Resources/containerTypes/dmg.py
U AddOns/InstaUp2Date/importDisk.py[/code]

Really appreciate all of your help Nate!
Crossing my fingers that it will work now.

[dead2sin]

Anytime! I’m glad it is working for you now. If you run into any more roadblocks, feel free to ask.

I spent several months getting my InstaDMG build chain working well and I’m still tweaking it every couple of months to make it more efficient as far as my workflow is concerned. Your build chain and workflow will really evolve as you go on. I now install some things on first boot that tend to not be packaged correctly and as a result don’t work well with InstaDMG (Adobe Flash is a good example, along with some inventory software we use). My basic philosophy is install anything that is large (more then 100mb or so) using InstaDMG. Anything that gets updated frequently or is rather small (Firefox, Flash, Air, Flip4Mac) I now install upon first boot using Munki. I find this to be a good balance between baked into an image vs install on first boot. I am pretty obsessive about making sure my images are completely up to date and by doing it this way, I can make sure flash is the latest version possible, yet not have to rebuild the whole image just for a Flash update. You’ll figure out what is best for you as you build more images and run into issues.

Nate

[bosemachine]

I hope this thread isn’t too old to resurrect but I’m having similar errors as the OP but simply using svn to update didn’t resolve the issue.

I’m using a retail 10.6.3 disk (10D575) and an InstallerChoices.xml file in the same folder. Regardless of whether I go with the legacy tagged Install DVD or not, I get the same errors as the OP.

I’m using instaup2date.py rev 392 and based on the advice dead2sin has given, I can confirm that I’m not getting past the 10.6_vanilla.

B

[Allister Banks]

Hey B,

It’s not your fault that InstaDMG was working, you heard there was a better add-on project you wanted to take advantage of, and now the workflow is funky. The bad news is it has changed from earlier documentation and will continue to change. I can only guess what you’re issue is, though. Please follow the current best practice:

1. InstallerChoices.xml files need to be checksummed like everything else and included, with their path, in catalog files after InstallerBuild. The xml file can live in the InstallerDisks folder, which is where all Disks should be from now on.
2. The BaseOS belongs in the InstallerDisks folder, specified in your catalog file by build number.
3. Custom pkgs fit best in InstaUp2Date Packages, although the full POSIX path to either there or Cache/InstaUp2DateCache works fine(which is where DMG’s fit best). I haven’t tried using stuff in CustomPkgs directory with InstaUp2Date in a while, but BaseOS and BaseUpdates along with CustomPkgs may as well go away once we get everybody thinking about the instaUp2Date workflow.
If anything I’ve described above does not work for you, please file an issue on the googlecode site.
In addition to osxdeployment here is an instaUp2Date wiki page with a workflow example on googlecode that has been updated to hopefully give a sneak peek of what the majority of people will want to use.
Please specify any questions or lack of functionality you’re experiencing so we can assist. Thanks,

Allister

[bosemachine]

I sent a PM because the spam detector hates me. 😯

…I tried to send a PM but apparently I wrote too much and it’s spam worthy. Nuts

[Author]

Posts