[Patrick Gallagher]

I prevent root logins with:

[code]/usr/bin/dscl . -create /Users/root UserShell /usr/bin/false
[/code]

This will stop most users from using root, at least those who don’t know how to check the shell that root is using. 😀

[Patrick Gallagher]

[QUOTE][u]Quote by: jochsner[/u][p]
dyld: Symbol not found: _kJVMInfoHomePathKey
Referenced from: /Applications/Utilities/Java/Java Web Start.app/Contents/MacOS/Java Web Start
Expected in: /System/Library/Frameworks/JavaVM.framework/Versions/A/JavaVM
Exited abnormally: Trace/BPT trap

Anyone else seeing this?[/p][/QUOTE]

I saw an error similar to this yesterday (dyld: symbol not found, I don’t remember the rest) on a freshly imaged Tiger machine (non-InstaDMG). The problem in my case was that the machine kernel panicked while installing updates. This killed Installer.app and the cli version. I just reimaged it to fix it.

[Patrick Gallagher]

[QUOTE][u]Quote by: userosx[/u][p]I’ve been using the referenced command (systemsetup -setremotelogin on) for some time now, but I need to specify “Allow access for:”, “Only these users:”, Administrators. Is it possible to specify which user/group has ssh access via the command line? I found the plist file (/var/db/dslocal/nodes/Default/groups/com.apple.access_ssh.plist), but it appears dynamic and not something I could rewrite using defaults or plistbuddy. I’m guessing there’s a simpler way. [/p][/QUOTE]

Try this:

[code]dseditgroup -o create -q com.apple.access_ssh
dseditgroup -o edit -a eccsadmin -t user com.apple.access_ssh[/code]

[Patrick Gallagher]

The allow relocation would cause the app to just get reinstalled on the system you running the package from (if it was installed). So the package would be installed on the image, except for the actual .app which is what may be causing the incomplete install.

I grown to dislike Package Maker for this and several other reasons. I’ve had better luck with Iceberg and don’t see real reason to use PM for our repackaging purposes.

[Patrick Gallagher]

Eventually for me has been no more than 10 or 15 minutes on that one step. If yours is truly taking more than an hour, then yes, I would be concerned. Have you used the Office Patcher <[url]https://www.afp548.com/filemgmt/index.php?id=84&comments=1[/url]> on your Office updates?

[Patrick Gallagher]

I frequently see status stuck on SLT too, but it’s always progressed eventually. I’ve never had to ctrl-c to get past it, and probably wouldn’t trust the install if I had to.

[Patrick Gallagher]

Correction. If I delete the inactive Airport interface and re-add Airport, it works. But still need to figure out what is causing this.

[Patrick Gallagher]

I have had similar problems with applescripts saved as .app’s. Something can get striped from the file (resource fork?) that prevents it from working on Leopard Intel systems. This wasn’t just pkg related, I also had the same thing happen if I had my applescripts hanging out on our NAS which is access via SMB. I resorted to putting my applescript in a disk image. You could do something similar to work around it, zip it up, lay it down with the package like before, then in your script you can unzip it.

[Patrick Gallagher]

MODEL=`/usr/sbin/sysctl -n hw.model 2> /dev/null`

Then if the result contains “book”, it’s a laptop.

[Patrick Gallagher]

[QUOTE][u]Quote by: dagger2b[/u][p][quote]How would (could?) you get the 2nd disc to use an InstallerChoices.xml file?[/quote]

Couldn’t you copy the package to the BaseUpdates folder and install with an InstallerChoices.xml file from there?[/p][/QUOTE]

That’s what I ended up doing (though to custompkgs since they’re not part of the base) but there were about 15 packages. There was no single mpkg or dist that could be copied unless the child packages were relatively accessible but I don’t think that would work in InstaDMG yet. Though instead of using an installerchoices for iLife stuff, I just remove the specific packages I didn’t want installed like GB Loops and iDVDExtraCrap.pkg.

[Patrick Gallagher]

There is no one place they keep their license files. You will have to investigate each app. Some store them in /Library/Preferences, some in /Library/Application\ Support. Also, you will (should) only be capturing the licensing on apps that are volume licensed and use the same serial #. Otherwise, you’re not in compliance.

[Patrick Gallagher]

The language choice shouldn’t matter. OS X client asks this as well. That’s only the language choice for displaying the installer, not what languages would be installed.

[Patrick Gallagher]

[QUOTE][u]Quote by: chilcote[/u][p]Better yet I just let InstaDMG mount the second disk image and added a one liner after the initial system installer code and before the part where it saves off a cached version:

[code]installer -pkg “/Volumes/Applications Install Disc/Install Bundled Software.mpkg” -target “$CURRENT_IMAGE_MOUNT” -verbose[/code]

Incidentally, I ran this build on a MacBookPro4,1 (Early 2008), using the installer disk images from the Late 2008 MacBook Pro, and so far don’t have any problems.

–joe[/p][/QUOTE]

How would (could?) you get the 2nd disc to use an InstallerChoices.xml file?

[Patrick Gallagher]

[QUOTE][u]Quote by: knowmad[/u][p]So … it did work with just 01,02,03…?
ie, is your issue resolved?
[/p][/QUOTE]

Yes, it is working now after renaming the folders like that.

[Patrick Gallagher]

I renamed all my baseupdates and custompkg folders to only be 01,02,03, etc. It wasn’t working with “01 packagename” or “01-packagename”. This naming used to work in b2, correct?

[Author]

Posts