[larkost]

The two issues at the moment are going to be:

1) Lack of FireWire and built in ethernet. The natural solutions here are: USB-Ethernet adapter and a NetBoot set (made for this computer) or a bootable USB drive (probably even the USB key they ship with).

2) As you mention, this is going to be a custom build of the OS, and until a dot-upgrade that supports it comes our your images (and NetBoot sets) are going to have to be custom to suport them.

Other than that these are just the latest iteration of the MacBook Air line. Treat them like you would any other MacBook Air.

Oh… and I have had my hands on a couple, and they are really nice looking.

[larkost]

A bit of advice if you are going to be working on imaging: get used to blowing away volumes and treating volumes as disposable. Once you get used to that your workflow will be much faster.

[larkost]

Yes, those sizes sound correct. We use compression to keep the file size as low as possible (but still large). A better check would be to make sure that the image looks good by restoring it to a volume and see if it works as expected.

[larkost]

[QUOTE][u]Quote by: golbiga[/u][p]With the new code coming out, will you be able to build an image for say the Mac Mini 2010 or Mac Pro 2010 on another machine? Just importDisk.py the grey disk form the Mini or Mac Pro and then have the catalog file associated with that build? Or will I still have to run that specifically on the MacMini/MacPro until 10.6.5? [/p][/QUOTE]

Nothing is really changing in this area. There is nothing in the code that will stop this from working, and it probably will work just fine. The only issue is that the involved installers MIGHT have things in them that will only install when run on the hardware they are made for. The last instance of this that I know about is the DVD Player will only install when the computer that it is installing on has a DVD player. I don’t think that this has happened since then, but I have no way of knowing if the situation will pop up again.

[larkost]

With the new code I put in, you don’t need two InstaDMG setups, just separate catalog files and two BaseOS images. Up till now I have been telling people to use the “–legacy” flag with importDisk.py, but starting with this weekends checkin I am reversing this: don’t use the “–legacy” flag and it will import it with a naming convention to allow multiple discs to be kept, and the name will even include the build number. They will also be stored in the newer location.

Then in the catalog files for each you have the build numbers that they apply to, along with the updates for that sort of machine. I take care of the vanilla ones for you, so you just have to supply the version for your “special” computers. Then when you call the catalog for that machine it will find the correct installer image for that build.

And while you can probably copy a lot out of the vanilla catalog file, I have serious reservations about recommending that people start with a copy of that file to build the special images. That is going to lead people to assuming that they are going to be the same, when the special versions of MacOS X that come with new computers can have very different requirements. It is better to assume that they are completely different, and walk through the installs looking them up on [url]http://apple.com/support/downloads[/url]. Where they are the same you can certainly copy them from the vanilla catalog.

Oh… and the tin-foil-hatter in me does want to put out the slight note of caution: it is possible that Apple could put in some thing in an machine-specific installer that only install on an image when run from that class of hardware. It has been a while since they did it (the last was with the DVD player software), but it is something to be aware of.

[larkost]

This is SVN telling you that it has noticed that you made a modification to that file locally, one that does not match the new version that is on the server (or the version you are coming from).

This is really timely, as I have been thinking over a better way for most people to keep their base catalog files up-to-date without requiring them to know how svn works. I plan to add a part of this as the last bit to 1.6, and then do some more with it for 1.7.

Oh, and the vast majority of the time you probably should not made modifications to the vanilla catalog files, but rather if you are building on top of them create your own catalog file, and link-in the vanilla.catalog file using a line like:
[code]include-file: 10.6_vanilla[/code]

It should not really matter where you put that line in order, but logically it should probably be first.

[larkost]

[QUOTE][u]Quote by: Allister[/u][p]And reference builds, definitively:
http://support.apple.com/kb/HT1633
Grey discs, definitively:
http://support.apple.com/kb/HT1159%5B/p%5D%5B/QUOTE%5D

Unfortunately I am not sure that that is a list of reference releases. Apple usually only has a couple of reference releases per major version. I think that this is a list of versions that Software Update will get you to. The list for 10.5 looks more like reference releases.

[larkost]

[QUOTE][u]Quote by: golbiga[/u][p]So I’m a bit confused. I’ve always used Retail/Reference, but my brand new 27″ iMac that I’m now using to run InstaDMG came w/ a 10.6.4 disc build 10F2061. So i decided to use that instead of the 10.6.3 retail. When doing that should I just build a separate catalog file? Or if I do use 10.6.3, just reference http://support.apple.com/kb/DL1065 in the catalog?[/p][/QUOTE]

Because the brand new iMac use special builds you should absolutely be using the grey discs that came with them for now, but you should not be using the vanilla catalogs. The updates that are applied in the vanilla catalog are not (all) the ones needed for the new iMacs. For the moment those computers (as well as the new Mac mini’s and the new Mac Pro’s) have to be treated specially, and you need to build your own catalog files for them.

If the pattern that Apple has kept for a very long time now holds, then when 10.6.5 comes out it will support all of the computers that were out when it came out, which will presumably include these new iMacs (and the Mac mini’s and the Mac Pros, as well as the LED displays).

This new feature is actually doing exactly what it is supposed to do: keep people from running non-reail/reference discs when they are using the vanilla catalogs. So this has saved you from making a mistake that you didn’t know about. I have just this case already worked in to my MacSysAdmin presentation, and will see if I can’t get a few parts of the slides posted after the conference.

[larkost]

I got my list from MacTracker… not exactly the most comprehensive place, but it is what I had available while coding (and everything I had at home fit that list). If you have a reference disc (not a grey one), and can tell me the source for it, and the build number I will probably add it to the list on the vanilla catalog file. The information that I am reading out is in:

/System/Library/CoreServices/SystemVersion.plist

and I also glance over at

/System/Library/CoreServices/ServerVersion.plist

One of the changes that I have planned for 1.7 will change the conversation a bit with regards to how to package scripts. I am going to further relax the “everything has to be a package” idea, but I think I can do so in a way that will make it easy to also re-use things in packages if you want to also use the same tools in places like DeployStudio or Munki.

And stand by, there will be a big announcement at MacSysAdmin, and I am hoping to have 1.7 done in time for MacTech. So if you are going to be at either of those, I should have some things to show you.

[larkost]

Exactly where did your instal disc come from? You should not be using grey discs with the vanilla catalog files.

[larkost]

Picking and choosing:

1) The Mac minis and the iMacs were both released on the same day that 10.6.4 came out. They were released as 10.6.3 machines, but the 10.6.4 updates for each of them (note: separate updates) came out either that same day or within a day or two. So the “rule” that each “dot update” covers all of the previously released hardware is still (mostly*) intact.

5) I have become a huge fan of Python… I rarely write scripts in other languages now when I can help it (not always possible). But the downside is that you still have to learn a good chunk of bash because that is what you use on the command line.

I will say that knowing multiple languages is a must for serious IT work. In the last month I have had to work in projects in: C, Obj-C, Python (most of them), bash, and Perl… with a little JavaScript thrown at me when a college needed some help. Once you get into the rhythm and ideas of programming/scripting moving languages becomes easier.

6) Any work you put into a “Golden Master” image is pretty much lost for the next one. If you have to do it, you have to do it. But you have not gained anything for the next round.

* From memory the only case I know where something was not supported was with a single group of iMacs that used a new family of graphics cards that were not otherwise supported by 10.4.x. My guess is that they used a new graphics system that came out with 10.5. Since 10.5 came out a bit late they probably had to back-port the drivers for 10.4.x and thus were never compatible with generic 10.4.x images (since they were not going to do all that work for other computers).

[larkost]

1) While those discs might be useable, those are exactly the discs that I was warning people off in the video (and other places). Go buy a copy of the retail disc (ie: the discs you buy in a store with no computer attached). The “reference” discs are ones that Apple will sometimes give out through special channels, like the old developer program.

2) Splitting this one up:

– PackageMaker comes with Apple’s Developer Tools (XCode), and can be download free (with registration) from Apple. I am split on whether to recommend using PackageMager or [url=http://s.sudre.free.fr/Software/Iceberg.html]Iceberg[/url]/[url=http://s.sudre.free.fr/Software/Packages/about.html]Packages[/url] instead. I like the latter tools better, but PacakgeMaker is the one from Apple…

– The complexity of bundling applications varies a lot by the application. Final Cut Pro and things from Adobe take some real care and feeding (despite a lot of feedback form the community).

– FireFox is absolutely trivial, you don’t have to do anything special with it, only provide InstaUp2Date with the url it need to target your package. Since it is just a “naked .app” in a dmg InstaDMG already knows what to do with it.

3) Apple does offer a pre-imaging solution if you put in a big enough order. Your University should have a Sales Engineer assigned to it, and between that person and the assigned sales person they should be able to walk you through those options. When I have talked through the option in the past they always have asked us to provide installers with the packages and settings that we want. This dovetails nicely into a more generic image creation with InstaDMG.

4) There are a lot of options, but those are probably the two best out there a the moment.

5) Without any scripting at all you can build basic images. If you need more complex things in your images, then the need for scripting increases. Regardless, being familiar with a least a few scripting languages is really helpful in IT.

[larkost]

When InstaUp2Date looks for files it finds them in a number of ways:

1) an absolute path

2) relative to PWD

3) relative to any of the caches

4) by the checksum string in the names in the caches

5) a name guessed from the name/path supplied (could be full paths or URLs)

6) the display name (the human readable name)

7) opens a connection the the http server and grabs the headers to see if there is something there that would give a clue (content-disposition)

8) tries to guess the name from the URL that the connection settles on (may times these things bounce around a bit before finding the final url)

9) finally it will download the item

You happen to be seeing #5 in that path. I recently changed things so that each point is clearer. Before things were a bit more wound through two different methods and confused me at times.

[larkost]

This is purely a guess, but I am pulling on a little bit of information that came up in a question on the MacEnterprise mailing list: it seems that the Bluetooth pairings are both in preference settings, and also stored on some bit of hardware in the system (the sucessor to PRAM maybe). This came up because Apple has started shipping some units pre-paired with the bluetooth mouse and keyboard that comes with them, and imaging the computer does not get rid of this.

So my guess about what has happened:

1) Your old image had the settings in it as a plist.

2) When the computes booted they took this preference and put it down in flash memory, duplicating the information in the plist.

3) The new image got applied to the computers, but the information was still in the flash memory, so got picked back up (maybe into the plist again).

My guess is that imaging systems (meaning things like DeployStudio) are going to have to start addressing this issue. But like I said, this is mostly guesswork. Can anyone out there take a whack at confirming this? I don’t think I have any time in the lab this week to do so.

[larkost]

I have just checked in some changes that may have some impact on the problem. After 3 re-installs of 10.5 on a system I managed to re-create the problem. I think it has to do with lengths of a few paths, so have reduced the lengths, and switched to a python mounting system that should be a little more reliable (and more verbose when failing). I can’t guarantee anything, because I can’t point at a smoking gun (and the path length limitations listed in the man page don’t quite match what I am getting). There is theoretically one more thing I could do, but implementing that would have to wait until after conference season at least.

[Author]

Posts