Failure if Output disk name not Macintosh HD

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Change Output disk name to something like Mac_HD in the catalog file.
2. Try to build an image with sudo ./instaUp2Date.py -p catalogfile

What is the expected output? What do you see instead?

Most of the time the build fails after a while since it is looking for 
Macintosh HD. I have gotten it to work sometimes but no idea why.

What version of InstaDMG are you running? What revision number (this should
be the second line of your package log)?

InstaDMG version 1.6rc1 (svn revision: 459)

What OS are you running on (booted from)?

Host OS: Mac OS X 10.7.5 but I have the problem with Mac OS X 10.8.2 as well.

What OS are you installing?

Mac OS X 10.7.5 (Mac OS X 10.8.2 as well).

Please provide any additional information below.

Debug log enclosed.

Original issue reported on code.google.com by anders.s...@universalmail.com on 16 Oct 2012 at 7:20

Attachments:

• 12.10.15-16.45.debug.log

[GoogleCodeExporter]

This is because you made the cache with any other name, to be specific, I've 
hard-coded it on line 666. You can workaround for now by just creating a cache 
once with the default name and I'll work on this as soon as I can (probably by 
reusing the image name variable at the end of the targetDiskMount var). Pardon 
the disruption, Allister

Original comment by a...@aru-b.com on 17 Oct 2012 at 10:52

• Changed state: Started

[GoogleCodeExporter]

I grabbed the latest SVN (462) and did the following with no cache:

sudo ./instadmg.bash -r -s -I /Volumes/Data/Mountain\ Lion\ 
Bits/10.8.2/Install\ OS\ X\ Mountain\ 
Lion.app/Contents/SharedSupport/InstallESD.dmg

And discovered the script stopped working around line 670 ("defaults read" for 
TARGET_OS_REV among other things).  I added a line at 674 to pause the script 
and examined the mountpoints:

bash-3.2# df
Filesystem    512-blocks      Used Available Capacity  iused    ifree %iused  
Mounted on
/dev/disk0s2   311390576  31373104 279505472    11%  3985636 34938184   10%   /
/dev/disk0s4   312135832 103894912 208240920    34% 12986862 26030115   33%   
/Volumes/Data
/dev/disk0s5   311763208  22526304 289236904     8%  2815786 36154613    7%   
/Volumes/Test Partition
/dev/disk1s2     9340080   8609560    730520    93%  1076193    91315   92%   
/private/tmp/idmg.6Tm8/idmg_temp.DoGTBL
/dev/disk2s2   627466384 347962960 279503424    56% 43495368 34937928   55%   
/private/tmp/idmg.6Tm8/idmg_mp.wqBR/InstaDMG
/dev/disk2s3     1269536    953056    316480    76%   119130    39560   75%   
/private/tmp/idmg.6Tm8/idmg_mp.wqBR/Recovery HD

It appears out of the box that line 666 set to:
TARGET_IMAGE_MOUNT="$TARGET_IMAGE_MOUNT/Macintosh HD"

causes a failure since the cached image is named "InstaDMG".  Changing line 666 
to:
TARGET_IMAGE_MOUNT="$TARGET_IMAGE_MOUNT/InstaDMG"

makes things run correctly.

Really appreciate all your help on maintaining InstaDMG.

- Patrick

Original comment by fergu...@gmail.com on 1 Nov 2012 at 4:45

[GoogleCodeExporter]

Yeah, this hard-coding-business is no good, I need to just variable-ize 
whatever's NOT 'Recovery HD'.

Original comment by a...@aru-b.com on 2 Nov 2012 at 6:16

[GoogleCodeExporter]

Hi,

 I too had the same issue while building OS X 10.8.2 Image. Changing the 666 line to
TARGET_IMAGE_MOUNT="$TARGET_IMAGE_MOUNT/InstaDMG"   does not work for me.

So I changed the 666 line to :- 

TARGET_IMAGE_MOUNT="$TARGET_IMAGE_MOUNT/$ASR_FILESYSTEM_NAME"

Thanks,
Karthikeyan M

Original comment by karthike...@gmail.com on 15 Mar 2013 at 12:53

[GoogleCodeExporter]

Better test it first, so
        if /bin/test -d "$TARGET_IMAGE_MOUNT/$ASR_FILESYSTEM_NAME" ; then
            TARGET_IMAGE_MOUNT="$TARGET_IMAGE_MOUNT/$ASR_FILESYSTEM_NAME"
        else
            TARGET_IMAGE_MOUNT="$TARGET_IMAGE_MOUNT/Macintosh HD"
        fi    

But use Macintosh HD as a fallback. If not for correctness, then for making 
sure you get an error if there is an error ;)

Original comment by will...@gmail.com on 8 Apr 2013 at 3:20

[GoogleCodeExporter]

Issue 117 has been merged into this issue.

Original comment by n8felton on 29 Dec 2013 at 2:21