Hello everybody,
I’m not a photographer but an Apple Consultant and got faced to this installer problem at a client’s studio. It was really difficult to find any solution on the web other than „run the installer logged in into a newly created user account“.
This was the all satisfying solution for us:
- Go to System Preferences -> Language & Region
- Change the primary language (I chose „English“)
- Quit System Preferences
That’s it. The installer should run now. And it still should after changing the language settings back to its original state (for me it was „Deutsch/German“).
This is how I got there:
I found this entry in the console log looking like
<timestamp> UniversalInstaller[pid]: objc[pid]: Class CmdUtil is implemented in both /var/folders/**/******************************/*/CanonOFI_TEMP/Data/Software/In stall/UniversalInstaller.app/Contents/MacOS/UniversalInstaller and /var/folders/**/******************************/*/CanonOFI_TEMP/Data/Software/In stall/UniversalInstaller.app/Contents/Frameworks/UIx.framework/UIx. One of the two will be used. Which one is undefined.
I observed the directory /var/folders/ during my installation attempts and noticed a directory CanonOFI_TEMP was created and deleted again after just a second. (By the way „OFI“ stands for „OneFileInstaller“).
Logged into a clean user account when running the installer, the above entry about „CmdUtil“ has been generated, too. So this might indeed be a hint to something nasty, but was not causing the installer to work.
I removed the corresponding subdirectory of /var/folders/ and restarted the machine. Nearly everything has been recreated immediately after login into the „bad“ user account.
We already gave booting into Safe Mode a try, I examined the user specific preference files in ~/Library/Caches, ~/Library/Containers, ~/Library/Fonts, ~/Library/Group Containers, ~/Library/Preferences – all that stuff. I did not get any further.
Shortly before I was determined to give up I noticed that in /Users/Shared Items several text/log files had been created that must belong to the several installation attempts we made. These text or log files pointed out the reason for the malfunction of the installer:
These log files contain information about the account the installer had been invoked with. So I was able to assign each file. The log files created by the „bad“ login session stopped recording installation events (because of the crash of the installer) exactly at the point where the log files created by the „good“ login session show information about the installation language.
Thereof I concluded that the installer must have problems to determine the system’s language and I changed its settings to reset it some way. And: It worked.
Hope this helps anyone.
Greetings from Hamburg
