- Joined
- Oct 2, 2011
- Messages
- 62
- Motherboard
- Gigabyte GA-H67N-USB3-B3 H67
- CPU
- i5-2500k
- Graphics
- nVidia GeForce 210, Intel HD 3000 (on mobo-unused)
jaymonkey, thank you for answering my questions.
That was NOT correct, that was just a case of me sitting here composing a message while I was tired and frustrated, and copying the wrong filename and block of text to my message. I actually made a couple other mistakes when I wrote that message but fixed them after my son caught them, but we still both missed that. As I said the day we did this, my son and I were both sitting here working through the instructions, and I remember checking SMBIOS.plist to make sure that string that's not supposed to be there was not in fact there (and it wasn't), then closing that file and moving on to org.chameleon.Boot.plist and adding the string there:
<key>SystemId</key>
<string>********-****-****-****-************</string>
But when you are tired and trying to write a message, it's easy to copy-paste the wrong filename and block of text from another post, and that's what happened here. When we actually did this process, we were both here and both wide awake and alert, so I'm sure we didn't use the wrong string or put it in the wrong place.
Anyway that key and string are GONE now, so my real question is, how is the boot sequence still finding them? If I could get rid of that it would be very helpful. But I wonder if this is the key...
That confirms that right now IORegistryExplorer is reporting my "old" SystemId, not the new one, which I can confirm because it's the same number that was used the filename of an older nvram.********-****-****-****-************.plist file (and that same name is on the same file currently in the Extras directory, though that is probably because we restored the directory from a Time Machine backup). So if I put that OLD value into org.chameleon.Boot.plist under the SystemID key temporarily, that should clean up any places where the "new" value might be lingering, right? I figure it is worth a try and have already added it using TextWrangler, just in case my system unexpectedly crashes or something. If it still picks up any other SystemID during boot then I have no idea where it is getting it.
I wouldn't be adverse to trying it again with another generated number if I wasn't afraid it would mess up the ability of Mail and Messages to interact with Google. That was the #1 reason this project was abandoned and we tried to revert to what we originally had; not being able to POP mail from Gmail would be a REALLY big problem. And the issue was that it simply would not recognize our valid passwords; even re-entering them simply produced another request for the same password.
If thats the case and your statement in post #480 is correct :-
Then you have not followed the instructions correctly, Path A states to remove any SystemId injection code in SMBIOS and add code to inject SystemId via the chameleon.plist, you have done the opposite.
That was NOT correct, that was just a case of me sitting here composing a message while I was tired and frustrated, and copying the wrong filename and block of text to my message. I actually made a couple other mistakes when I wrote that message but fixed them after my son caught them, but we still both missed that. As I said the day we did this, my son and I were both sitting here working through the instructions, and I remember checking SMBIOS.plist to make sure that string that's not supposed to be there was not in fact there (and it wasn't), then closing that file and moving on to org.chameleon.Boot.plist and adding the string there:
<key>SystemId</key>
<string>********-****-****-****-************</string>
But when you are tired and trying to write a message, it's easy to copy-paste the wrong filename and block of text from another post, and that's what happened here. When we actually did this process, we were both here and both wide awake and alert, so I'm sure we didn't use the wrong string or put it in the wrong place.
Anyway that key and string are GONE now, so my real question is, how is the boot sequence still finding them? If I could get rid of that it would be very helpful. But I wonder if this is the key...
You don't need to convert the value in the ioreg, the 16 numbers should match the injected UUUD in the same sequence, you just need to add the dashes. Once you inject SystemId via the chameleon.plist it should work.
That confirms that right now IORegistryExplorer is reporting my "old" SystemId, not the new one, which I can confirm because it's the same number that was used the filename of an older nvram.********-****-****-****-************.plist file (and that same name is on the same file currently in the Extras directory, though that is probably because we restored the directory from a Time Machine backup). So if I put that OLD value into org.chameleon.Boot.plist under the SystemID key temporarily, that should clean up any places where the "new" value might be lingering, right? I figure it is worth a try and have already added it using TextWrangler, just in case my system unexpectedly crashes or something. If it still picks up any other SystemID during boot then I have no idea where it is getting it.
I wouldn't be adverse to trying it again with another generated number if I wasn't afraid it would mess up the ability of Mail and Messages to interact with Google. That was the #1 reason this project was abandoned and we tried to revert to what we originally had; not being able to POP mail from Gmail would be a REALLY big problem. And the issue was that it simply would not recognize our valid passwords; even re-entering them simply produced another request for the same password.