If you are receiving the “Apple ID is valid but is not an iCloud account.” error after upgrading to 10.7.2 on your Hackintosh when attempting to logon to iCloud, you most likely just need to update your Chameleon or Chimera to the latest (I recommend Chimera).
For me, just the Chimera update fixed my logon problems. However, if the Chimera update does not solve your issues, you may have an issue with your built in network interfaces or a bad serial number. If you cannot logon to iCloud after the Chimera update, try the following to reset your network settings on your Hackintosh:
1. Remove all network devices from System Preferences > Network. It should look like this when you are done (and you will have no Internet access until completing the next steps):
2. If they don’t exist, add the following lines to the <dict> section of your boot plist in /Extra/org.chameleon.Boot.plist (for newer versions of Chameleon/Chimera):
Others have reported that you need to add the following lines as well, but I don’t have them present and my iCloud works:
My <dict> portion of my com.chameleon.Boot.plist looks like this:
<dict> <key>Kernel</key> <string>mach_kernel</string> <key>Kernel Flags</key> <string>arch=i386</string> <key>GraphicsEnabler</key> <string>Yes</string> <key>Timeout</key> <string>2</string> <key>Legacy Logo</key> <string>Yes</string> <key>EthernetBuiltIn</key> <string>Yes</string> </dict>
3. Delete /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
4. Delete /Library/Preferences/SystemConfiguration/com.apple.network.identification.plist
5. Reboot your computer. Both the files deleted above will be automatically recreated.
6. Go back to System Preferences > Network and add your network devices, STARTING with Ethernet type as the first Ethernet interface (do not use WiFi as the first interface!).
After you hit “Apply”, your top interface should be the wired interface at en0:
Hopefully your iCloud and App Store is working at this point.
If you are still having issues (most likely due to a bad system type/serial):
Download and run Multibeast for Lion and update your system definition (Customization, System Definitions):
For good measure here’s my System Report so you can compare your system type, etc.:
Recently a client of mine who has an Audi A7 couldn’t get his HTC Thunderbolt’s address book/contacts to sync with the Audi MMI over Bluetooth.
The workaround, which I found here:
- Unpair/Delete the phone from the Audi MMI
- Remove the Audi pairing from the HTC Droid (unpair)
- Re-pair the Audi to the HTC Droid
- When the phone pops up with the “Audi MMI wants to access your contact lists, Allow or Deny?”
Hit DENY numerous times. After the 5-6th DENY all your contacts will sync.
Makes no sense and is totally counter-intuitive, but it works!
I use Apple Time Machine to backup my MacBook to a Mac Pro over my LAN/WiFi network using the Snow Leopard AFP time machine hack. Recently the MacBook’s hard disk totally failed and I needed to mount the disk image on the Mac Pro to pull a few critical files off immediately. The sparsebundle appeared in Finder as a folder with a small red minus sign, meaning my user account didn’t have permission to access it.
When I attempted to open the backup image I received an error stating “You do not have permission to open the document MacBook”. Note: “MacBook” was the name of the system Time Machine was backing up.
After approximately an hour of experimentation and research, I found the fix:
Open Terminal in Applications/System Utilities.
“cd” to the folder where your sparsebundle file resides.
(i.e. cd “/Volumes/Media/Time Machine”)
sudo chown -R `id -un`:`id -gn` MyTimeMachineBackup.sparsebundle
Enter your password.
Note the “`” quotes above are the slant-quote on your tilde key
on the top left of your Apple keyboard below the “esc” key.
You should now be able to access and mount the image.
Took me several hours to figure this out, but here are the configuration items you’ll need below to get your Cisco 7940 or 7960 working with Vitelity’s SIP service. This configuration is for a phone that is behind NAT. You do not need to specify your external NAT address as long as the NAT entries in the second part are included in the configuration – this is important if you have an ISP that changes your public/Internet IP at regular intervals (DHCP addressing, not static). Vitelity’s proxy will figure out your public address.
Note the “vitelity_username” can be either your Main account or a sub-account off the primary. I created two identical appearances on two lines (although only line1 is displayed in the config example below). You will need to change the username/password/proxy to whatever your Vitelity settings are for your account.
line1_name : “vitelity_username”
line1_authname : “vitelity_username”
line1_password : “vitelitypasswordhere”
line1_shortname : “LineName”
line1_displayname : “8881112222”
proxy1_address : “sipXX.vitelity.net”
proxy1_port : 5060
outbound_proxy : UNPROVISIONED
outbound_proxy_port : 5060
nat_received_processing : 1
nat_enable : 1
nat_address : “”
start_media_port : 16384
end_media_port : 20000
preferred_codec : g711ulaw
dtmf_outofband : avt
dtmf_avt_payload : 101
dtmf_db_level : 3
dtmf_inband : 1
Assign your Cisco 7940 or 7960 a static IP on your LAN and forward 5060 TCP and 10000-20000 UDP to that IP from your firewall.
A client of mine has eight Verizon FIOS analog lines that are delivered to two Avaya IP Office analog ATM4 trunk cards. All of their calls are picked up/answered live, so no attendant pickup during working hours. We deliver these analog calls to a hunt group to ring several users in the front office.
Because of a very specific issue with FIOS handling of caller ID in combination with IP office analog cards, the following occurs:
- The analog port, set to Loop Start ICLID picks up the ring.
- The call is delivered directly to a “main” hunt group.
- If a member of the hunt group picks up the call on the second ring, they will hear a loud buzzing/flutter for 1 second. It sounds like this (recorded from speakerphone). The sound is inaudible to the remote caller, FYI.
There is no real “fix” per se without completely disabling caller id on the carrier or IPO side, but there is a workaround which requires Embedded Voicemail, Voicemail Lite, or Voicemail Pro by utilizing “announcements.”
- Enable Announcements for your “main” hunt group (or extension if not using hunt groups), but don’t record one.
- Set announcement wait time to 0
- Set post announcement tone to “Ringing”
- Turn off 2nd and repeat announcements.
Because the call is picked up by the attendant and then routed, the crackle usually heard by the person picking up the call is intercepted by the “fake” attendant announcement. Note that this workaround will occupy a single VM channel for about .5 secs when the call is picked up. Also, caller ID continues to work well with the fix above.
Yet another alternative is to disable caller ID at the Verizon side, or set your IP Office analog lines to “Loop Start” with no CID. Of course this will disable caller ID which is usually a dealbreaker in this day and age.