[nobrainer]

Okay, so I did a bunch of searching.. but I can’t figure how to actually check the logs 😳

[nobrainer]

I have been having the same problems as referenced in other threads with 10.5, I’d like to help narrow down the problem, but my knowledge is a little vague on how. Would allowing you to remote into a machine help or would the log / debug files help?

[nobrainer]

We’re behind a proxy too…you can try copy / pasting the links from the catalog to a web browser and see if that gets you out..

[nobrainer]

VNC – so a Windows system can connect.

[nobrainer]

Yeah, I saw the perl script, fought with it for about 2 weeks before I realized the encrypted PW was being sent as clear text (first 8 characters of the output of that file) rather than converting back to the actual PW.
wasn’t sure if I tried a different encryption method if it would work…

[nobrainer]

These guys have been outstanding, and your question was answered in another thread. I’ve used their recommendations several times to build 10.5.x boxes.

To make it a little easier, here is the thread…

[url]https://www.afp548.com/forum/viewtopic.php?showtopic=27149[/url]

[nobrainer]

I think that was it!

Seems like it’s working now! Thank you so much! I’ve manage to deploy it across the intel based machines we have w/o issue and all the settings seem to be working properly!

Thank you so much!

[nobrainer]

[QUOTE][u]Quote by: dead2sin[/u][p][QUOTE][u]Quote by: nobrainer[/u][p]Okay, so I followed precisely the instructions ([url]http://www.osxdeployment.info/wiki/InstaUp2Date_Guide[/url]) (and created the 3 catalog files), and I don’t think the firstboot ran. It didn’t enable the remote desktop (ARD / VNC), time server wasn’t set (because we ship all over, I left the timezone out), IPV6 is still enabled, etc.

I added it to instadmg, which said the pkg was loaded successfully, and there was no errors in the build logs or anything that I could tell…

What am I missing? I’m so close I can taste it! Oh wait… that was leftover from lunch.

[/p][/QUOTE]

Check your system.log for errors. If any of the commands didn’t work, many times you can find a hint of what went wrong there. It sounds to me like the firstboot files didn’t get put there at all, or perhaps the permissions on the launchd item were incorrect and it didn’t run.

Nate[/p][/QUOTE]

Permissions? I didn’t change any, I set the scripts to +x but didn’t change anything else…

I looked through any log I thought might have something to do with it, and all I could find was was that the pkg was installed… nothing (successful or unsuccessful) about actually running the firstboot or scripts or anything. I did find the time server was off, but that was supposed to be taken care of via the script….

[nobrainer]

Okay, so I followed precisely the instructions ([url]http://www.osxdeployment.info/wiki/InstaUp2Date_Guide[/url]) (and created the 3 catalog files), and I don’t think the firstboot ran. It didn’t enable the remote desktop (ARD / VNC), time server wasn’t set (because we ship all over, I left the timezone out), IPV6 is still enabled, etc.

I added it to instadmg, which said the pkg was loaded successfully, and there was no errors in the build logs or anything that I could tell…

What am I missing? I’m so close I can taste it! Oh wait… that was leftover from lunch.

[nobrainer]

pretty much, used the mini’s cd to import, then ran through insta up2date which had the original 10.6.4 update, then in 3rd party software I added the mini’s 10.6.4.

I just built the mini using casper, seemed to work as well..

[nobrainer]

Just as a heads up, I was able to set the create a mini NBI by using the mini cd, layering the 10.6.4 off the catalog file and adding the 10.6.4 mini on top of it.

I was about to start the main image now.

[nobrainer]

I actually just ran into this too yesterday afternoon as well. Theoretically, I can replace the catalog file with the linked 10.6.4 update for the mini’s and not loose anything – but gain the mini support? What about if the person maintaining the script just updates to that update rather than the original? hen you won’t need to maintain separate builds and … stuff..

EDIT: As a note, we had problems with our netboot image as well, since it was never updated since 10.6.3 came out originally… so if you’re using an “old” netboot that will need to be updated too.

[nobrainer]

[QUOTE][u]Quote by: dead2sin[/u][p]If you ever intend upon doing more then one image, I would highly suggest seperating stuff out from the beginning with future images in mind (so it would need to be a logical seperation, stuff that you know ALL images will get goes in common.catalog, etc).

If you only have one image and will always have only one image, then you could definitely put it in to one catalog and not worry about it. At the very least, I would leave 10.6_vanilla alone and make your image.catalog include 10.6_vanilla. That way, you can grab an updated vanilla from the instadmg google code site and not have to sieve through the changes and figure out what needs to be updated and what doesn’t, etc.

So at the least, 10.6_vanilla.catalog –> MyImage.catalog and at the most (and for multiple images) I would do 10.6_vanilla–>Common.catalog–>BaseLab.catalog (Shared between several lab images for instance)–>SpecificImage.catalog (Specific software beyond the base.catalog).

Again, that is my preference. I’m always looking for ways to make it less painful for myself in the future and I find that splitting things out in a smart manner saves a bunch of cutting and pasting between catalogs down the road.

Nate[/p][/QUOTE]

Oh, makes sense. We do have 2 images… 10.5 for PPCs and 10.6.x for Intel. I wasn’t sure if the multiple catalog files was due to the the extra pkg files, or if the img needed to be closed and opened in between (like a reboot type thing), and for just my general knowledge (if I know why I’m doing something, it’s easier for me to process in my mind).

[nobrainer]

The more I work on this, the more questions I have, thank you for your continued patience with me!

——————————-

These catalogs are all set up and ready to go. Using the include-file: part of the catalogs chains them all together. When we call Snowleopard.catalog with InstaUp2Date, it will process them in the following order:
10.6_Vanilla.catalog –> Common.catalog –> Base.catalog –> Snowleopard.catalog

This ensures that everything gets installed in the correct order throughout the process.
[edit]

——————————-

I’m workin through the tutorial on this, and I was wondering if there is any benefit to do it this way vs just modifying the 1 catalog for 10.6_Vanilla?

I’m not loading iLife, or anything like that…basically, I have it running the Updates from instaup2date + clearreg, 2 admin accounts… and now this firstboot….

Would it behoove me to layer stuff as recommended via catalogs?

Would it make sense to put the firstboot.pkg separate from InstaDMG and do it as part of the Casper workflow? My thinking is then I can have a firstboot that will set the proper timezone for where the machine will ultimately be located (PST, MST, CST, or EST)?

[nobrainer]

I have been finding the quirks of kickstart for a while… scouring trying to find each and every piece of information I can find on the topic. This has really only managed to successfully give me a migraine headache every day for the last week or two…

We do have ARD, but due to cost we don’t deploy it to the support staff, that and they don’t have a mac to use themselves, they need to remote in from a pc.

Anyway, I’ve tested the firstboot.sh script w/ the cleartext password and seemed to work fine.

[Author]

Posts