Forum Replies Created
-
AuthorPosts
-
larkost
ParticipantThe CS4 installer looks to be only a small change from the CS3 one. You can create a couple of files that will allow installer to run in automated mode (where the license files are put in for you, and you can kill the auto-updates). The only change I have seen in the docs from CS3 is that you don’t have to fish out the files from /Library/Application Support. It still does not disable Acrobat self-heal.
larkost
ParticipantI don’t know what version you are using, but there are the -m and -n flags that can set the dmg and volume names respectively. If you surround the input with quotes or escape the spaces they should work just fine with that. These have been in there for a while.
larkost
ParticipantYou just have to target all of the write commands against the target disk ($3), and give the (almost *) full path to the plist file, and that will work fine.
* You need to omit the “.plist” from the end of the path…. That reminds me to file that bug against defaults…
larkost
ParticipantAt this point I am still using the InstaUp2DateInstallers as a flat repository. It might be (but I have not tried this at all, and was not thinking this direction when writing code) that you could just use relative references (ie: “bob/filename.dmg”). At one point I was using some absolute references for things, but that was a lot of versions of code ago.
And the building blocks idea is exactly what I had in mind, and exactly the way I am using it. I have multiple build trains that reference the “Base” catalog file, and that in turn references the vanilla.catalog that is included. When I add something to the Base image it is easy (but takes a long time) to kick off the production on all the others.
larkost
ParticipantThe solution I am using to handle Office 2008 is that I make a disk image with the installer and the InstallerChoices.xml file in it, and then reference that. At one point I had folders in there, but that got bumped out when DMG’s got bumped in. I have some ideas about how to handle things so that things like this would be possible, but those are a long way off.
September 15, 2008 at 2:23 pm in reply to: Changing the location of the tmp files when building InstaDMG images #374103larkost
ParticipantAnd for the record… I can’t reproduce it (and can’t fix what I can’t reproduce).
larkost
ParticipantYes… but it was written for a beta of MacOS X 10.5.3, and does not work on the final version… plus it only was ever tested for one type of 802.1X. I switched jobs (and away from networks I could test on) before 10.5.3 came out. However, anyone who wants to can raid it:
The code is located at:
http COLON SLASH SLASH code.google.com/p/macenterprise8021x/ (sorry… anti-spam filter hates me)
And if anyone ever wants to put together a hacked WAP that I could test thing on and were to send it to me, I would be willing to finish up the work on it. Alternately, I am willing to hand over the project to someone who could complete it.
larkost
ParticipantGoing to the Network Preference pane does not tell you if you already had the network ports setup because by going to the Network Pane the first thing it does is to set up ports that were missing. So that does not mean that they were setup. Checking on the command line will get you better information.
larkost
ParticipantAre you sure that your network interfaces are setup when you go to do this? Going to the GUI automatically does this, but InstaDMG packages do not do this by default if you manually avoid the apple setup.
larkost
ParticipantI have not yet run the QuickTime 7.5.5 installer in InstaDMG (hopefully I will be doing that tomorrow), but it probably is looking for one or both of these settings before letting you do this:
[code]export COMMAND_LINE_INSTALL=1
export CM_BUILD=CM_BUILD[/code]InstaDMG automatically does this, but if you are doing this by yourself, then you should try those two.
September 10, 2008 at 12:48 am in reply to: How to make a netbootinstall from an instadmg image? #374036larkost
ParticipantThis is really funny… over the weekend I found some code to do exactly that (instaNBI), and we (the InstaDMG developers) are talking with the author of that code to bring it into the InstaDMG repository. I have already done some work to get the code in sync with InstaDMG, and will continue on with that (I just got my version with a lot more working). So this will probably be out in a few weeks (the developer seems very receptive to this move).
September 8, 2008 at 9:25 pm in reply to: Why do pkg’s install on / instead of $CURRENT_IMAGE_MOUNT #374027larkost
ParticipantI think that knowmad has hit upon the problem: pmset does not work on the filesystem, rather it works on the information that is stored in the power management unit. That has its own little bit of battery-backed RAM, and has nothing to do with the files on the virtual disk that InstaDMG builds (nor anything to do with the files on the boot drive). Using MCX would be a much better way of creating these settings. Alternately you could create something that was run once the computer first booted from the image, but that is a little more work.
Is there another reason you think that things are getting run against your booted drive?
larkost
ParticipantI don’t believe that the warning came from MacOS X, but was something you added in. It is relatively easy to do this in a login-hook.
http://www.macosxhints.com/article.php?story=20060925114138223
For some reason I thought that Keychain Minder (it is on http://www.apf548.com) had this functionality, but it does not. I might volunteer to put that in sometime in the near future. But in the mean time, you can do it with a fairly simple loginhook.
larkost
ParticipantSince InstaDMG output only goes on computes that are wiped out, you can always just push in any Keychain you want, so you might be able to get by by pushing out a Keychain with the values you want already filled in, and the rest of the configuration files.
September 6, 2008 at 7:40 pm in reply to: Changing the location of the tmp files when building InstaDMG images #374007larkost
ParticipantI suspect that the assertion errors you are seeing might be because you are using a non-HFS+ (Journaled, case-preserving-but-insensitive) volume. Please be aware that none of the developers use anything but plain-jane HFS+ volumes at this point, and that is unlikely to change anytime soon [1].
I have made some changed to the code, and just checked them in to do two things:
1) Sanitize all of the paths that come in to make sure that they don’t end in “/”
2) Make sure that the temp folder path is always enclosed to take care of spaces in names. I missed a couple of spots before.
[1] – I am looking forward to testing ZFS in the Snow Leopard timeframe, and in about a month I will be adding additional (non boot) drives to my main machine that will allow me more room to play with things like that.
-
AuthorPosts
Recent Comments