Forum Replies Created
-
AuthorPosts
-
pteeter
ParticipantDebug Log Example #1:
[code]Working on folder 01 AirPortUtility (08:54:40)
Copying folder /Volumes/zzz_Dev500GB/Mac_Imaging/build_directory/instadmg-r405/InstallerFiles/InstaUp2DatePackages/AirPortUtility.pkg into the target at /private/tmp/idmg.BTFj/idmg_mp.ezkT/private/tmp/idmg_pkg.AZw0
Installing AirPortUtility.pkg inside a chroot jail
PFPkg: No file found at path: /private/tmp/idmg_pkg.AZw0/AirPortUtility.pkg
PFPackage::packageWithURL – can’t instantiate package: /private/tmp/idmg_pkg.AZw0/AirPortUtility.pkg
Error the package path specified was invalid: ‘/private/tmp/idmg_pkg.AZw0/AirPortUtility.pkg’.
Removing the copied folder: /private/tmp/idmg.BTFj/idmg_mp.ezkT/private/tmp/idmg_pkg.AZw0
Folder 01 AirPortUtility done (08:54:57)[/code]
Debug Log Example #2:
[code] Working on folder 02 FrontRowUpdate2.1.7 (08:54:57)
Copying folder /Volumes/zzz_Dev500GB/Mac_Imaging/build_directory/instadmg-r405/InstallerFiles/InstaUp2DatePackages/FrontRowUpdate2.1.7.pkg into the target at /private/tmp/idmg.BTFj/idmg_mp.ezkT/private/tmp/idmg_pkg.ucMP
cp: /Volumes/zzz_Dev500GB/Mac_Imaging/build_directory/instadmg-r405/InstallerFiles/InstaUp2DatePackages/FrontRowUpdate2.1.7.pkg//Contents/Resources/FrontRowUpdate2.1.7.sizes: No such file or directory
Installing FrontRowUpdate2.1.7.pkg inside a chroot jail
PFPkg: No file found at path: /private/tmp/idmg_pkg.ucMP/FrontRowUpdate2.1.7.pkg
PFPackage::packageWithURL – can’t instantiate package: /private/tmp/idmg_pkg.ucMP/FrontRowUpdate2.1.7.pkg
Error the package path specified was invalid: ‘/private/tmp/idmg_pkg.ucMP/FrontRowUpdate2.1.7.pkg’.
Removing the copied folder: /private/tmp/idmg.BTFj/idmg_mp.ezkT/private/tmp/idmg_pkg.ucMP
Folder 02 FrontRowUpdate2.1.7 done (08:55:11)[/code]
The cp error with FrontRowUpdate2.1.7 seems bogus, find on the file in the pkg bundle:
[code]% pwd
/Volumes/zzz_Dev500GB/Mac_Imaging/build_directory/Current/InstallerFiles/InstaUp2DatePackages/FrontRowUpdate2.1.7.pkg
% find . -name \*.sizes
./Contents/Resources/FrontRowUpdate2.1.7.sizes[/code]
Debug Log Example #3:
[code] Working on folder 10 RemoteDesktopClient (09:10:55)
Copying folder /Volumes/zzz_Dev500GB/Mac_Imaging/build_directory/instadmg-r405/InstallerFiles/InstaUp2DatePackages/RemoteDesktopClient.pkg into the target at /private/tmp/idmg.BTFj/idmg_mp.ezkT/private/tmp/idmg_pkg.7pIR
cp: /Volumes/zzz_Dev500GB/Mac_Imaging/build_directory/instadmg-r405/InstallerFiles/InstaUp2DatePackages/RemoteDesktopClient.pkg//Contents/Resources/RemoteDesktopClient.sizes: No such file or directory
Installing RemoteDesktopClient.pkg inside a chroot jail
PFPkg: No file found at path: /private/tmp/idmg_pkg.7pIR/RemoteDesktopClient.pkg
PFPackage::packageWithURL – can’t instantiate package: /private/tmp/idmg_pkg.7pIR/RemoteDesktopClient.pkg
Error the package path specified was invalid: ‘/private/tmp/idmg_pkg.7pIR/RemoteDesktopClient.pkg’.
Removing the copied folder: /private/tmp/idmg.BTFj/idmg_mp.ezkT/private/tmp/idmg_pkg.7pIR
Folder 10 RemoteDesktopClient done (09:11:01)[/code]
Same result with this .sizes file.As for line 85 in instadmg.bash, very interesting. In my Leopard InstaUp2Date catalogs, the *only* non-flat pkg installer that has worked and continues to work is a customized createUser pkg installer. Surely I can append to the list of CHROOT_EXCLUDED_CODES & maybe that’s the intent of the variable.
Has anyone interested in this thread explicitly tried a non-flat/old style pkg installer with a Leopard-based instadmg run – download any of the 3 mentioned in the logs above? I admit my attention to that detail was remiss until now, I used to use Iceberg and that was the tool used to create many of the custom packages that were breaking with r405. I have been using Packages for quite some time and used it to re-pkg the offending non-flat pkg installers.
Next step is to exclude the FrontRow, AirPortUtility, & RemoteDesktopClient installers.
pteeter
ParticipantServer vs client image isn’t the issue, however it’s quite simple to ‘trick’ instadmg into making server images (link in a server install DMG as ‘Mac OS X Install.dmg’, skip InstallerChoices.xml, and don’t run any custom pkgs to clear out the registration information). Have been building them successfully for a while.
When the failures have occurred it’s been 10.5 client on 10.5 client.
Am generating those logs right now. Will look at line 85 in bash script.
Thanks.
pteeter
Participant[QUOTE][u]Quote by: Allister[/u][p]Are you using instaUp2Date? Without a doubt, any type of package works in 10.5.8 – I tested every vanilla catalog file in r407 myself on a MacPro and a MacBookPro from 2008.
For 10.5 custom packages modifying line 85 for your custom pkgs bundle identifier is necessary, but not for Apple pkgs.
How ‘pristine’ an install are you building from? I remember you mentioning an issue in the past, can you post the relevant parts of your debug log again please? Could it have anything to do with your installer binary, have you tried installing the same pkgs from the shell?
If you aren’t using(or aren’t interested in using) instaup2date, could you please run [code]openssl sha1 /path/to/each/pkg[/code] and post the results here? Thanks,Allister[/p][/QUOTE]
Always use InstaUp2Date. Not sure what you mean about ‘line 85’? Using either 10.5.6 install media from MacBookPro, 10.5.4 install media for Leo Server, build 10A432 of 10.6, or build 10A433 of 10.6 Server.
Have to re-rerun on Leopard with the non-flat packages to generate new logs.
Same non-flat packages work from CLI, with SnowLeopard host OS / target image + r405, & work with older r236 or r272 of instadmg.
It’s less of an issue now as re-pkg’ing the 3 updates worked.
But would like to get to the bottom of the issue.
pteeter
Participant[QUOTE][u]Quote by: foilpan[/u][p]do they work if you wrap them in a dmg? worth a shot…[/p][/QUOTE]
Not sure how it would make a difference.
pteeter
ParticipantI will add that 2 of the 3 packages I mentioned are also required for SnowLeopard.
The non-flat/old style pkg installers for the Airport and Remote Desktop Client updates both install just fine when InstaDMG is run on a 10.6.5 machine when trying to build a 10.6 image.
Gonna pull some logs from a Leopard build and look through the bash code for instadmg.bash.
pteeter
ParticipantAnd the recent 9.0.3 update appears to behave the exact same way.
June 1, 2009 at 9:03 pm in reply to: Re-packaging Adobe CS4 Design Premium with logGen, pkgGen, and Iceberg #376351pteeter
ParticipantPlease now download files from the My Downloads section of AFP548.com.
The same diff files and scripts are now available here.
Thanks.
June 1, 2009 at 4:18 pm in reply to: Re-packaging Adobe CS4 Design Premium with logGen, pkgGen, and Iceberg #376346pteeter
ParticipantI think posting my diff files will help A LOT.
Look in the My Downloads section of AFP548.com for the latest/newest addition.
Pull the zip archive down and find these files:
[quote]
Adobe AIR with CS4-diff.txt
Adobe Acrobat 9 CS4-diff.txt
Adobe Bridge CS4-diff.txt
Adobe Device Central CS4-diff.txt
Adobe Dreamweaver CS4-diff.txt
Adobe Extension Manager CS4-diff.txt
Adobe Fireworks CS4-diff.txt
Adobe Flash CS4-diff.txt
Adobe Fonts with CS4-diff.txt
Adobe Illustrator CS4-diff.txt
Adobe InDesign CS4-diff.txt
Adobe Media Encoder CS4-diff.txt
Adobe Media Player with CS4-diff.txt
Adobe Photoshop CS4-diff.txt
Adobe Shared Files CS4-diff.txt
CS4-update1-diff.txt
CS4-update1-preflight.sh
[/quote]This will help clarify steps 4-5 I think.
Step 6 works kind of like this.
sudo pkgGen /path/to/diff/file/diff.txt /path/to/created/pkg/root/pkg-root
pkgGen will parse the contents of the diff.txt file and copy the heirarchy of necessary files, preserving ownership/permissions/etc, into the specified pkg-root folder.
Make sense?
The postflight script and diff file for the 1st CS4 update is also included. I’m pretty sure more CS4 updates have come out since I re-packaged that group of updates. I’m without a development environment at the moment so can’t really investigate updating the CS4 Updater package.
I hope this is helpful. Please reply with more questions if you have them.
May 14, 2009 at 8:30 pm in reply to: Re-packaging Adobe CS4 Design Premium with logGen, pkgGen, and Iceberg #376176pteeter
ParticipantI’m a unix/cli guy.
loggen and pkggen just feel better to me.
I admit the gui tools work – Composer, InstallEase, etc.
It’s just comfort that’s all.
pteeter
ParticipantGood stuff.
I’ll be trying to boot a new MBP with a 10.5.6 image that was created with disparate install media.
We’ll see how it goes.
pteeter
ParticipantGood to know Josh. Thanks, your input is valuable.
pteeter
Participantmissed it sorry.
pteeter
ParticipantFYI.
The installer does not prevent itself from being installed on a PPC machine.
It installs and, from what I can tell, does not prevent the hardware from booting Leopard.
My test case was a dual G5 PowerMac.
We shall see.
pteeter
ParticipantI think we are missing something.
/etc/kcpassword has to be created with the password of the user for this to work.
For deployment, it might be easiest to create the correct kcpassword file, drop it in /etc with a pkg, then do the PlistBuddy command in a postflight script.
Anyone else care to comment?
pteeter
ParticipantFigured it out just yesterday.
One of my build trains ends up with a VERY limited set of local fonts. In the process, he Helvetica.dfont is removed from /System/Library/Fonts. Font replacement/auto-fixing is disabled too.
As soon as that dfont stops living in /System/Library/Fonts, Firefox crashes on launch.
I’m still researching but for some reason the removal of Helvetica.dfont from that folder does not effect the root account?
More to come.
-
AuthorPosts
Recent Comments