[hkim823]

Since posting this, my AD admin turned on a feature that “magically” made this start to work. I forget the exact wording, but it has to do with AD groups being able to view permissions of AD groups (something that by default is not turned on it seems in a standard AD setup). Next time I see my AD guy I’ll ask him exactly what it is.

[hkim823]

[QUOTE][u]Quote by: dead2sin[/u][p]Supporting disc isn’t meant to be used for the installer disc. So long as the installer disc is where importDisk.py puts it (InstaDMG/InstallerFiles/InstallerDiscs) it should find it and use it. So long as it is there, it has the build # in the file name and that build number is present in vanilla, it *should* work.

Nate[/p][/QUOTE]

I took out the Supporting Disc line and now it works. Thank you both for the help.

[hkim823]

[QUOTE][u]Quote by: Allister[/u][p](I don’t think you [b]need[/b] need to, but it should work with all hardware once combo updated past 10.6.5, since no hardware was released more recently)

Allister[/p][/QUOTE]

So I was talking to my Apple System Engineer, and he flat out told me Combo Updates do not include hardware information. I told him that Combo Updates have always helped me out to support new hardware, but he basically said that I was just getting lucky.

The only way to support hardware is to use reference discs (10.6, 10.6.3 retail) and if a computer shipped after that point, to use the machine specific media. I haven’t had to resort to this with the models I support, but I just thought I’d throw it out there.

[hkim823]

Definitely using the retail disc itself. Since I’m new to the new catalog file format, I didn’t state to use the file inside of InstallerDiscs. I put it in as such,

Installer Disc Builds: 10A432
Supporting Disc: /Shared Items/instadmg/InstallerFiles/InstallerDiscs/MacOS X Client 10.6 10A432.dmg sha1:632a14627f8e72f2f5ab4f8bde950d0b02b6f6a9
Installer Choices File: /Shared Items/instadmg/InstallerChoices/InstallerChoices.xml sha1:b5adc1e9cc96ae737ce58ba923771094cec6ad04

But it’s still failing saying that it’s missing the DMG file inside of the BaseOS folder, where traditionally I had a Mac OS X Install Disc.dmg (which was just a DMG of the retail install DVD).

[hkim823]

I’m new to importdisk.py …

I ran it, it grabbed the disc, I noticed that there’s a new catalog file style where you can choose different disc styles and such, but I’m having a hard time finding documentation on how to use this properly. It copied the file to InstallerFiles/InstallerDiscs but didn’t put anything in BaseOS and when I run InstaUp2Date, I get

Finding the Installer disc for base-template
Traceback (most recent call last):
File “./instaUp2Date.py”, line 716, in
main()
File “./instaUp2Date.py”, line 680, in main
foundInstallerDiscs = findInstallerDisc.findInstallerDisc()
File “/Users/client/instadmg/AddOns/InstaUp2Date/Resources/findInstallerDisc.py”, line 201, in findInstallerDisc
raise commonExceptions.FileNotFoundException(‘Unable to find OS Installer disc in any provided folder: %s%s’ % (str(searchItems), folderString))
Resources.commonExceptions.FileNotFoundException: Unable to find OS Installer disc in any provided folder: [‘/Users/client/instadmg/InstallerFiles/BaseOS’] ([‘.svn’])

[hkim823]

I will try that, and report back.

[hkim823]

Commenting out that line has gotten InstaUp2Date to work. Very weird stuff.

[hkim823]

This is a prod server but I’ve used it in the past (I know it’s not recommended but since it also hosts deploystudio and ARD and all the PKG files, it’s just so much easier than to copy all the PKG files onto a test box that keeps getting reimaged every other day)

That being said here’s the debug log

11:32:03 ###### InstaDMG build initiated ######
InstaDMG version 1.6rc1 (svn revision: 388)
Host OS: Mac OS X Server 10.6.4
Host Hardware: MacPro4,1
Output file name: MacintoshHD.dmg
.dmg
Output disk name: Macintosh HD

###### The ISO language code en
is not recognized by the Apple installer ######

ISO language code en not recognized? That’s a new one.

[hkim823]

Although maybe totally unrelated, with InstaDMG and DeployStudio, I’ve found that if I don’t use the DSRuntime to “grab” the InstaDMG created image and let DeployStudio actually import the image in itself, I find that weird things can occur. I’ve never had the problem your seeing, I’ve always been able to just drag and drop images into DS, but I’ve had networking issues for some reason when deploying.

So on the computer you built the InstaDMG image on, mount said DMG file, open up DeployStudio Runtime, and then let the DeployStudio server grab the image. It seems redundent and takes a long time, but it certainly has fixed weird issues I was having.

[hkim823]

I built my PKG using Composer and looking for file system changes. I’ll post the list of files you need to make a custom package tomorrow when I get into the office.

[hkim823]

For those in my boat where PKG files no longer seem to work using InstaUp2Date, and not as handy with the command line to wrap those PKG files into a DMG, I found this drag and drop tool to do it for me.

http://www.kelleycomputing.net/freedmg/

[hkim823]

I’m going to spend the afternoon converting my current workflow and adapt it to the InstaUp2Date workflow. It’s probably better in the long run since development really seem to be going in that direction anyway.

[hkim823]

Office 2008 was always a pain for me trying to use the native mpkg file.

I’ve resorted to using a snapshot based pkg maker like JAMF Composer to make my Office 2008 pkg file. I setup a computer with Office 08 the way I want it, and then have Composer pick it up, make some edits to the pkg files (i.e. move the user library and documents files to System/Library/User Template/English.lproj instead, so on image creation and when a new user logs in for the first time, those settings will stick with the new user).

To me it’s worth many times the $99 that it costs. $79 I think for educational institutions. Whenever I come across a pkg that just doesn’t work right, I use Composer to make my own custom one.

[hkim823]

I maybe to blame. I was having problems working with InstaUp2Date and XCode 3.2.2, and the modifications made to the code basically made other functionality fubar (well hopefully not fubar).

I’ve decided not to use InstaUp2Date with XCode, but rather create my own custom XCode 3.2.2 pkg file myself using Composer. I’m sure we can go back to rev 293 where none of the mucking around was done on my behalf.

[hkim823]

I direct my users to just press Apple + Q to get past that screen.

[Author]

Posts