[ktappe]

[QUOTE][u]Quote by: Confusion[/u][p]Hey Allister, that link provided my some help and then i found what i needed back on one of greys pages in the comments.

I have tested this and it works perfectly

[i]Don’t forget the ability to disable the Import Wizard: create a file [code]/Applications/Firefox.app/Contents/MacOS/override.ini[/code]. The contents should be as follows:

[code][XRE]
EnableProfileMigrator=false[/i][/code]

Thanks for the link if i had not followed it i wouldn’t have known about override.ini and wouldn’t have searched for it for OSX[/p][/QUOTE]

Followup tip: I initially tried this and it didn’t work. But the permissions on override.ini were 644. I then changed them to 755 and the Import Wizard was then disabled. Hope this helps someone else!

[ktappe]

Per this thread [url]https://www.afp548.com/forum/viewtopic.php?forum=45&showtopic=29910[/url], several of us have seen this problem. It’s solved by rebooting the Mac you’re running InstaDMG on. Not sure of the cause.

[ktappe]

$3 did the trick, Thanks!

[ktappe]

Updating to the latest revision (439) of InstaDMG and using the 10.7.3 reference build instead of patching 10.7.0 did fix the problem; older iMacs boot fine now.

[ktappe]

[QUOTE][u]Quote by: elvisizer[/u][p]reboot fixed it . . . anyone know why a reboot fixes installer disc identification issues? i seem to remember having this happen occasionally in the past, too.[/p][/QUOTE]

Wow, you’re right. Rebooting (or in my case, kernel panicking) did fix the problem.

[ktappe]

I am seeing the same behavior [b]but only on older Macs[/b]. I develop our 10.7.3 image using InstaDMG on a 2011 iMac. The image produced by instaUp2Date boots 2011 iMacs, 2011 MacBook Pros, and 2011 MacBook Airs.

But on 2008 iMacs it produces the non-booting scenario you describe.

Try this to see if your scenario exactly matches mine: Boot the misbehaving Mac with the shift key held down to induce Safe Boot. On mine this did allow the Mac to boot, though doing so (by design) prevents firstboot.sh from executing. Once the Mac boots to the login screen, reboot it. Then firstboot should execute and you’ll see your image.

My working theory is that instaUp2Date removes some boot caches that newer Macs’ firmware are able to recreate but older Macs need Safe Boot to be induced to recreate. But I’m not good enough with Python to poke around instaUp2Date.py and disable the cache removal step to prove my theory.

Allister: Any thoughts on this?
-Kurt

[ktappe]

[QUOTE][u]Quote by: larkost[/u][p]>I have nowhere to test out proxied systems. A quick look indicated that the documentation on the python urllib2 module (what InstaUp2Date uses) seems to indicate that it should be reading the proxy information from the configuration framework. So in theory this should already be working. If you can figure out what has to be done to get urllib2 to work through your proxies, then I can try to add it, but short of that I don’t know what to do.[/p][/QUOTE]
I can’t get InstaUp2Date to work through our proxy servers either. Researching urllib2 reveals it does have parameters that must be passed in for it to go through proxies, which seems to imply it does not honor the Mac system’s proxy configuration.
Specifically, when you build the parameters for urllib, you should do so via: urllib2.build_opener(proxy_support, authinfo), where proxy_support = urllib2.ProxyHandler({“http” : “http://proxy:8080”})

What would be sweet if there were a way to suck the Mac system’s proxy info into this parameter. How about using:

system_profiler | grep “HTTP Proxy Server”
and
system_profiler | grep “HTTP Proxy Port”

I’m no Python jockey so I have to leave it to the experts to assemble these pieces into a working whole. But I hope I’ve helped the process along somehow. I’m stuck building OS X by hand until we can get this fixed.

[Author]

Posts