Updated to r422, can’t find any installer discs

[snk]

So, I updated to r422 today, and instaup2date errors out every time when trying to find the installer disk.

The disk I’m trying to use is a 10.6.6 disk, which I have just imported today, and I’ve added the build number to my catalog file.

Did something change with the way I have to declare which disk to use? I don’t recall having to do this with a previous revision…

Any help appreciated!

[bw38]

I think the issue is that you’re trying to use the gray restore disk which you’re not supposed to be using. Doesn’t mean it won’t work, but it’s not recommended. You need to use a retail disc or a reference disc. The latest reference disc is 10.6.3 that I know of. Now in theory, I suppose a 10.6.6 disc should work if you apply 10.6.8 combo update. Is the machine you’re running up to date with the latest combo update? Try applying the combo update, not the delta.

Also try to download r423. Seems it came out just today.

[snk]

I’ll give 423 a shot.

I’m seeing the error of being unable to find the installer disc, even with the 10.6.3 retail disk (both the grey 10.6.6 disk and the 10.6.3 retail disk were recently imported with a fresh copy of instadmg).

[snk]

Okay, so I’ve updated to a clean checkout of revision 423, imported a fresh retail 10.6.3 DVD, and have attempted to run it with the instructions in the readme (10.6_vanilla), here’s the output from beginning, to the eventual failure:

[code]
sudo ./instadmg-read-only/AddOns/InstaUp2Date/instaUp2Date.py 10.6_vanilla –process

Parsing the catalog files for 10.6_vanilla
Remote Desktop Client 3.4
AirPort Utility 5.5.3
iLife Support 9.0.4
Mac OS X 10.6.8 Combo Update
iTunes 10.3.1
Java For Mac OS X 10.6 Update 5

Finding and validating the sources for 10.6_vanilla
Remote Desktop Client 3.4 – downloaded and verified 4.2 Megabytes in 2 seconds (3.3 Megabytes/sec)
AirPort Utility 5.5.3 – downloaded and verified 10.3 Megabytes in 1 second (19.0 Megabytes/sec)
iLife Support 9.0.4 – downloaded and verified 67.1 Megabytes in 10 seconds (6.6 Megabytes/sec)
Mac OS X 10.6.8 Combo Update – downloaded and verified 1.0 Gigabytes in 48 seconds (21.4 Megabytes/sec)
iTunes 10.3.1 – downloaded and verified 74.0 Megabytes in 3 seconds (23.5 Megabytes/sec)
Java For Mac OS X 10.6 Update 5 – downloaded and verified 75.5 Megabytes in 4 seconds (29.5 Megabytes/sec)

Finding the Installer disc for 10.6_vanilla
Traceback (most recent call last):
File “./instadmg-read-only/AddOns/InstaUp2Date/instaUp2Date.py”, line 716, in
main()
File “./instadmg-read-only/AddOns/InstaUp2Date/instaUp2Date.py”, line 678, in main
foundInstallerDiscs = findInstallerDisc.findInstallerDisc(allowedBuilds=thisController.installerDiscBuilds)
File “/Volumes/SSD/instadmg-read-only/AddOns/InstaUp2Date/Resources/findInstallerDisc.py”, line 201, in findInstallerDisc
raise commonExceptions.FileNotFoundException(‘Unable to find OS Installer disc in any provided folder: %s%s’ % (str(searchItems), folderString))
Resources.commonExceptions.FileNotFoundException: Unable to find OS Installer disc in any provided folder: [‘/Volumes/SSD/instadmg-read-only/InstallerFiles/InstallerDiscs’, ‘/Volumes/SSD/instadmg-read-only/InstallerFiles/BaseOS’] ([‘.svn’, ‘MacOS X Client 10.6.3 10D575.dmg’], [‘.svn’])[/code]

[snk]

Hmm, Disregard 🙂

Gave my host Mac a reboot, and things seem to be working fine now. *shrugs*

[Tim Sutton]

[QUOTE][u]Quote by: bw38[/u][p]I think the issue is that you’re trying to use the gray restore disk which you’re not supposed to be using. Doesn’t mean it won’t work, but it’s not recommended. You need to use a retail disc or a reference disc. The latest reference disc is 10.6.3 that I know of. Now in theory, I suppose a 10.6.6 disc should work if you apply 10.6.8 combo update. Is the machine you’re running up to date with the latest combo update? Try applying the combo update, not the delta.

Also try to download r423. Seems it came out just today.[/p][/QUOTE]

Using grey discs is fully supported, for when you need to build your image for new hardware models whose drivers have not yet been included in the mainstream OS builds. Freely-available presentations have been given on how to do this, as have numerous forum posts you can find here. Of course, one mustn’t use these discs for general images, but running importDisc.py on a grey disc will parse the appropriate version and build no. just lie it would for a retail disc.

The issue is the most common one faced by new users. I find that with using a dedicated build machine, I run into this issue very rarely.

[freepms]

I have r388, because that’s what’s in the downloadable .zip, and svn can’t get through my company’s proxy even after putting proxy settings into ~/.subversion/servers. Having the same problem; output follows.

15:46:13 ###### InstaDMG build initiated ######
InstaDMG version 1.6rc1 (svn revision: 388)
Host OS: Mac OS X 10.6.8
Host Hardware: MacBookPro8,1
Output file name: 11-09-12.dmg
Output disk name: InstaDMG
15:46:13 ###### Finding main MacOS X installer disk ######
###### Unable to find primary installer disk ######
15:46:13 ###### Cleaning up ######
Restoring normal installd daemon
Ejecting images

This happens no matter where I put the retail 10.6.0 image imported by InstaUp2Date.

[freepms]

Got outside the company firewall, updated to 425. It still can’t find the installer disks.

[Allister Banks]

Hey freepms,

It is almost impossible these two symptoms are related. Failure to find the disk is almost always due to glitches with the disk arbitration framework, which usually can be solved by a reboot or logout/in, and making sure the disk its trying to find(or something with the same volume label/name) isn’t already mounted.

Allister

[freepms]

Ditched the installer disk image created with 388. Restarted.

Created a fresh installer disk image with InstaUp2Date. Restarted.

Ran instadmg.bash. Unable to find primary installer disk.

Moved image from InstallerFiles/InstallerDisks (where InstaUp2Date puts it) to InstallerFiles/BaseOS. Restarted.

Ran instadmg.bash. Unable to find primary installer disk.

Nothing else is mounted except for my internal HD. It has four partitions, none of which contain any of Mac, Macintosh, HD, or Installer in their names.

[Allister Banks]

I’m curious about your system python, and if you could, please use the svn checkout, as described here:
[url]http://code.google.com/p/instadmg/source/checkout[/url]

It would also be great if you could jump into IRC with us so you could give feedback in real time…

Allister

[freepms]

Today’s post: all steps done after taking computer outside company firewall and using svn to get 425.

Fully updated OS X 10.6.8, Python 2.3, 2.5 and 2.6.

I’ll see what I can do about IRC. Thanks!

[Allister Banks]

Who’s got two thumbs and is relieved you can finally see it working? THIS GUY.

Allister 😀

[freepms]

Sorry to be unclear. Still not working; I was just replying to your post asking me to svn -checkout the latest, which I did manage to do.

[freepms]

Latest status:

Moved entire InstaDMG folder to a different box. No change.

Took that box outside the company firewall, svn’ed v.425. InstaDMG.bash still cannot find installer disk.

Rebooted. Trashed installer disk image, imported a fresh one. Rebooted. InstaDMG.bash still cannot find installer disk.

Ran InstaUp2Date.py 10.6_Vanilla –process (still outside the firewall). This succeeded. I don’t understand why InstaDMG will find the Base OS image when called by InstaUp2Date but not when run directly.

Took the resulting image and restored it to a partition of my original build box. Created fresh admin account. Everything from here down was done on this freshly-imaged partition.

Copied over the InstaDMG folder from the other box. InstaDMG.bash still cannot find installer disk.

Rebooted. Trashed installer disk image, imported a fresh one. Rebooted. InstaDMG.bash still cannot find installer disk.

Moved InstadDMG folder aside and svn’ed v.428. Trashed installer disk image, imported a fresh one. Rebooted. InstaDMG.bash still cannot find installer disk.

Ran InstaUp2Date.py 10.6_Vanilla –process (still outside the firewall). This succeeded (though process, and logs, say that it’s still v.425)

So as of v.428, on two different boxes, one freshly imaged, InstaDMG.bash still cannot find a Base OS image when run on its own, but when called by InstaUp2Date, it can.

Here are my donuts. I await your dollars. 😀

[Author]

Posts