Owners disabled on restore

[jaharmi]

I’m creating both Snow Leopard and Leopard images with InstaDMG and InstaUp2Date (r414 up until this morning). I have been having a problem with owners being disabled with my Leopard images when they are restored using either Disk Utility or the asr utility.

The drawback of this is that I can bless or boot from the restored volumes on the second computer. They do not show up in the Startup Disk System Preferences or in the startup boot menu.

Toggling the “ignore ownership” behavior in the Get Info window on that computer has no effect; I still cannot bless or boot from the affected volumes.

The volumes are bootable before I restore my InstaDMG Leopard image to them. Immediately thereafter, Disk Utility et. al. report that owners are disabled.

I am typically restoring from my InstaDMG build system (a Mac Pro) over target disk mode to a disk partition on a second computer. I have also duplicated this finding with the same image file while restoring with Disk Utility on the second computer (while it is booted from a working system partition).

My images are almost entirely used for testing purposes, not for deployment to actual end user computers. They are based on the 10.6_vanilla and 10.5_vanilla catalog files for InstaUp2Date, with a few other updates — only one, my organization’s certificate authority, is unique to my site. I’m including the _vanilla catalogs in a parent catalog. So, my images are very close to a stock Apple OS install that has been fully patched via Software Update.

I am trying to duplicate the problem while booted from a working system partition on the affected second computer, using the same InstaUp2Date catalogs and build process there that I use on the first computer.

I haven’t noticed the same problem with my Snow Leopard images; last I checked, they seem to restore to other partitions and are bootable afterwards.

Note that I’m building all of the Leopard images under Snow Leopard right now. If this is part of the problem, then I will have to set up a dedicated Leopard build Mac. InstaDMG seems increasingly intolerant to using a different OS for the build process than the one you are building. (In the ~1.4 days, I was able to build images for multiple older OSes, maybe all the way back to 10.1, from a Mac Pro.) I use InstaDMG only occasionally, so it’s hard to keep up with whether the different-OS-than-build practice is frowned upon today.

[jaharmi]

When I rebuild the same image with the same Leopard source system disk and InstaUp2Date catalog files on a Power Mac G5 running Leopard, I do get an InstaDMG image that restores to a target volume and is bootable.

If I may ask, what (besides chrooting) has been added since the 1.4 days that would cause problems with building images for older systems on a newer Mac? I’m really curious.

It is likely I will always have older Macs to support. With Apple changing the supported systems on a pretty regular basis in the last few releases, that may mean keeping several Macs of appropriate vintage around just for building images. That is in addition to possibly keeping older Macs as test units and spares.

If InstaDMG could successfully build restorable images for older OSes on a newer OS, that would mean real savings to my organization.

[Author]

Posts