Updated to r422, can’t find any installer discs

[Allister Banks]

Current status would be ‘we believe there’s a bug with either:
a. importdisk(lightly used)
b. instadmg.bash(commonly used by tweakers, who may very well have altered their local checkout)’
So I booted into my Snow test partition, checked out the newest svn, and dropped in a 10.6.3 build I’ve been using since I can’t recall. Immediately picked it up. Found an image of 10.6.0(10A432), mounted and imported it with importdisk.py..17 minutes and 14 seconds later ran instadmg.bash… surprise, unable to find primary installer disk
…
doh. Two problems here:
1. default naming from importdisk
2. default directory it drops the disk in

Once I renamed it(Mac OS X Install Disc 1.dmg’, ‘Mac OS X Install DVD.dmg’, and ‘InstallESD.dmg’ are all valid) and moved it to the InstallerFiles/BaseOS folder it worked just fine.

I’ll file the bug, it’s kindof a documentation issue that I should have left the –legacy flag on for importdisk in the guide, sorry it took me a bit to realize.

Allister

[freepms]

That nailed it.

I had done the reimage – svn – import sequence again and had run through some of the flags (-b and -I, with and without -f) to no effect. But renamed the imported image to “Mac OS X Install DVD.dmg” and it’s running.

Thanks for working through this with me!

[freepms]

GRRRR. Spoke too soon.

It found the BaseOS, and wrote a cache image from it. But then:

09:59:19 ###### Beginning Update Installs from ./InstallerFiles/BaseUpdates ######
Working on folder 01 (09:59:19)
###### There were no items to install in: /Users/exadmin/instadmg/InstallerFiles/BaseUpdates/01 ######
09:59:19 ###### Cleaning up ######

…even though MacOSXUpdCombo10.6.8.dmg is sitting in that exact folder.

[Allister Banks]

doh again, have you tried packages instead of dmg’s?

Allister

(BTW, totally not putting you through all of this to force you to use instaUp2Date, but… doesn’t it seem a lot nicer?)

[freepms]

Extracted the packages from the dmg’s, and then then it ran to conclusion. Haven’t tested a restore with the resultant image yet but I have good confidence in it.

It’s possible I truly don’t get it about InstaUp2Date. But it seems to me that it imposes *extra* work. Instead of just downloading packages, putting them into the requisite folders and kicking off the build, I have to download the dmg’s, checksum them, add them to a catalog file, then throw them away and let InstaUp2Date re-download them.

Or is that just for stuff from Apple? And everything else goes into CustomPGK regardless of InstaUp2Date or not? Sorry to be a noob, but I’m a noob.

[Allister Banks]

Do not be wary of noobdom, I needed this perspective to see how lacking the docs I made are. InstaUp2Date will not redownload the patches, or ever again, if it finds the dmg/pkg in a ‘guessed’ location(e.g. /Caches/instaUp2DateCache). This means when it runs, if it sees a dmg at either:
a. the filesystem path as specified in a line in the catalog file if you manually added one(or optionally generated it with the checksum.py tool to spit out the proper syntax for you)
or(commonly for a URL path)b. in the /Caches/instaUp2DateCache folder with a matching filename/checksum
, it knows to use that local one.

A drawback is when you’re rapidly developing packages to include you do need to generate a new checksum each time, but the rest of the info would stay the same.

Instadmg.bash exhibits slightly different behavior by default(as you noticed, due in part to the lack of the flags up2date uses in its handoff), but the premise is the same: you follow convention and patch the OS before any additional apps and then the settings would get laid on top at the end. The vanilla catalog files means you don’t have to care what the current patches are for any models in your fleet(I’m even covering the new, forked ones) – trust the crowd-sourced versions I happen to curate. And using up2date means you don’t have to manually download those patches, since the python process fetches them for you. On top of that, you don’t have to move folders around when you want to build a different combination of software, either.

Another enhancement is to take advantage of the branch-able nature of the catalog files. You can use the ‘include-file [i]path/to/my/specific/catalog/file[/i]’ syntax to have one base catalog file incorporate others, and then you only need to update the things specific to your builds in one place, but the referenced, continually-updated vanilla catalog files(and/or, additionally, the forked models catalog file) that are included for you take care of the rest and stay current. There are a number of variables you can configure in a base catalog file as well, which means you don’t need to pass as many flags to the command-line process at runtime, and it becomes a more scriptable(or less manual thought) process.

Please let me know what else could be clearer or better described. Thanks, Allister

[Author]

Posts