Jump to content

FileNVRAM 1.1.3 Released

chameleon module nvram xzenue messages

  • Please log in to reply
59 replies to this topic

#41
nyolc8

nyolc8

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 802 posts
  • Gender:Male
  • Location:Budapest, Hungary

Yes, the test version which is created by ErmaC to inject boardserial number. But nvram worked for me before with older chameleon builds, I think the 2266 normal build had some bug which blocked the filenvram module from working properly.



#42
Bungo

Bungo

    InsanelyMac Sage

  • Coders
  • 296 posts
  • Gender:Male

Hi cosmo1t,

I'm using Enoch 2266, FileNVRAM module loading and saving values to file nvram.000 ... 00018.plist. On next boot it doesn't retrieve last brightness level, should it?



#43
nyolc8

nyolc8

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 802 posts
  • Gender:Male
  • Location:Budapest, Hungary

I had NVRAM value retrieve problems with 2266 & FileNVRAM module too. Try the 2267 test2 chameleon, with that, it's retrieving datas from NVRAM after reboot nicely.



#44
sebkulu

sebkulu

    InsanelyMac Protégé

  • Members
  • Pip
  • 22 posts
  • Gender:Male
  • Location:France

Hello Guys, don't know if that can help, but I still have problems login into iMessage, with the 'Call Apple Support' error messsage...

 

So, what I tested so far:

1. 
-Boot, and try to login to iMessage, receive 'Call Apple Support'
-Change NVRam MLB Value to a 18 digits number instead of a 17 digits number (or the contrary depending on the SMSerial you're using)
-Try to login to iMessage, first attemp NO-GO (seems to wait for some anwser from the server which never comes...)
-Try to login to iMessage, second attemp, Message is telling me I'm connected, I can see all the addresses I can be reached at (also my Phone Number), I can add/delete any address I want, BUT GUESS WHAT? -> I CAN'T SEND A BLOODY MESSAGE!

2.
-Change SystemId key in org.chameleon.boot.plist to a custom made one, as to change the NVRam IOPlatormUUID register to a "non-blacklisted" one (at least that's what I thought)
-Reboot, verifiy changes have been made into NVRam registers
-Try to login to iMessage, receive the bloody 'Call Apple Support' message

BTW: I think iMessage, or ANY other Apple service, cannot be bound by Hardware UUID, because if it was so, I could login for example on any other iMessage working Hackintosh... and THAT'S NOT THE CASE.
There definitely IS something between "AppleID/NVRam MLB register/IOPlatformUUID"...

I setup 3 different Hackintoshes (including mine) for the last month, the two others having a 100% working iMessage (with NVRam 1.1.3 BTW) with a different AppleID than mine, with perfectly set NVRAM registers (all different from each other Hackintosh), and I STILL CAN'T LOGIN WITH MY AppleID! (could be on any other Hackintosh, still the same)

I also tried the flollowing famous "fixes":
-Removing/re-Adding credit Card
-Log out from iMessage on all my other Apple devices, then log back in on those devices, then log back in with the Hack

The ONLY thing I didn't try was to change my password... I don't want to change it wihtout being SURE it REALLY DOES something... (yeah I've 3 other Apple Devices, it's a bit annoying...)

the weird thing is that if I use the iMessage_debug script, which displays some NVRAM content (such as MLB, IOPlatformUUID, IOPowerState, etc...), the RIGHT values are displayed even by using Chameleon 2266 and FileNVRam 1.1.3, meaning that Chameleon DID read the correct NVRam register values at boot time... but you're saying that it's Chameleon that have problem reading FileNVRam content?

 

Even so, how can I explain the fact I stil cannot login to iMessage from any other hackintosh, which IS NOT running Chameleon 2266 (but a previous version), and which is using FileNVRam 1.1.3?

 

 

-Probable Solutions left:

1. Change AppleID Password

2. Use older or newer version than Chameleon 2266 rev which cannot correctly read NVRam registers

3. Use FileNVRam 1.1.2 (for tests purposes)

4. Delete FileNVRam.dylib AND FileNVram file, reboot twice, reinstall FileNVRam 1.1.3 to generate a new fresh&clean NVRam

 

Edit:

OS X 10.9

Chameleon 2266

FileNVRam 1.1.3

 

 

Edit2:

On my MacBook Air, after having upgraded to 10.9, I have seen that the MLB does NOT match the SMserial on its first 11 digits...

Could that be that now it's calculated from various NVRam registers, using some algorithm?



#45
The Real Deal

The Real Deal

    InsanelyMac Legend

  • Donators
  • 858 posts
  • Gender:Not Telling

So the inability to update aperture to 3.5 version via AppStore, i mean the error (update not available for this userID...) message is due to fileNVRam? A fix is on the way?



#46
sebkulu

sebkulu

    InsanelyMac Protégé

  • Members
  • Pip
  • 22 posts
  • Gender:Male
  • Location:France

So the inability to update aperture to 3.5 version via AppStore, i mean the error (update not available for this userID...) message is due to fileNVRam? A fix is on the way?


It seems I'm actually a bit wrong in what I'm saying.

My reasoning is invalid. Actually problem lies in boot loader, so problem lies in Chameleon not in FileNVRam.dylib.
What's happening here, is that Chameleon CAN read/write NVRam correctly, BUT fails at populating SMBios (real SMBios Used by MacOS, not SMBios.plist which is read by Chameleon to populate real SMBios fields), which causes the updates via App Store AND iMessge connection error to arise.
When I say "fail", it doesn't fail, it just does not write ALL necessary fields to SMBios to be seamlessly used by AppStore updates and iMessage.

That's what I understood from the Chameleon Topic, and what they're saying about 2267 Beta.
And what also points to that direction, is that Clover does NOT have all the trouble to get your updates properly done and your iMessage to work...
But I just don't like Clover, and would much rather stay on Chameleon ^^
So I'll wait ^^

What I don't understand, is WHY THE HECK can others login into iMessage with my build, and I don't...
There MUST also be some kind of server side validation, which could have been reinforced for some users reaching some iMessage connection attempts number... Don't really know, but how could that be only client sided?
What I mean by "reinforced validation", is that Apple would consider reading others(more) SMBios fields for specific users, and when they don't match a real Mac, the connection is refused.
Just a theory though, nothing rock solid here...

Anyway, let's just wait for the new Chameleon rev! ^^

#47
Bungo

Bungo

    InsanelyMac Sage

  • Coders
  • 296 posts
  • Gender:Male

I had NVRAM value retrieve problems with 2266 & FileNVRAM module too. Try the 2267 test2 chameleon, with that, it's retrieving datas from NVRAM after reboot nicely.

Thank's now it works (2267 test2). Retrives last brightness level.



#48
Bungo

Bungo

    InsanelyMac Sage

  • Coders
  • 296 posts
  • Gender:Male

@cosmo1t

One thing, I boot from a stick where is chameleon, Extra etc. but nvram,,,.plist wants to be saved into Extra on working partition.

Wouldn't be better to save it into boot partition's Extra?



#49
Smith@@™

Smith@@™

    InsanelyMac LOL

  • Retired
  • 2,928 posts
  • Gender:Male
  • Location:Somewhere over the rainbow...ITALIA!
  • Interests:Dark matter and dark energy. E basta. HD3000. E basta.

@cosmo1t

One thing, I boot from a stick where is chameleon, Extra etc. but nvram,,,.plist wants to be saved into Extra on working partition.

Wouldn't be better to save it into boot partition's Extra?

Cosmo and all ancient chameleon dev seems to be disappear from the chameleon scene..



#50
Bungo

Bungo

    InsanelyMac Sage

  • Coders
  • 296 posts
  • Gender:Male

Also I use SL 10.6.8 on my lap. FileNVRAM seems to be working properly but brightness level isn't saved and retrived on next boot.



#51
Gringo Vermelho

Gringo Vermelho

    The Jan Bird fix

  • Supervisors
  • 6,045 posts
  • Gender:Male
  • Location:Brazil

One thing, I boot from a stick where is chameleon, Extra etc. but nvram,,,.plist wants to be saved into Extra on working partition.

Wouldn't be better to save it into boot partition's Extra?

No. Doing that could cause issues on a PC with multiple versions of OS X installed. It's better to use /Extra on the partition you're actually booting.



#52
Bungo

Bungo

    InsanelyMac Sage

  • Coders
  • 296 posts
  • Gender:Male

No. Doing that could cause issues on a PC with multiple versions of OS X installed. It's better to use /Extra on the partition you're actually booting.

I meant different plists for different installations located all in Extra on boot partition (a stick in my case).



#53
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 136 posts
  • Gender:Male

Bungo,

 

FileNVRAM will probe all devices that chameleon has read access to for the latest nvram plist file, so it shouldn't matter where it gets saved. The plist is saved on the active system partition due to technical limitations of the module that make this the easiest solution to implement.

 

If you feel that there are drawbacks to this solution, let me know and it can be revisited.



#54
Bungo

Bungo

    InsanelyMac Sage

  • Coders
  • 296 posts
  • Gender:Male

Bungo,

 

FileNVRAM will probe all devices that chameleon has read access to for the latest nvram plist file, so it shouldn't matter where it gets saved. The plist is saved on the active system partition due to technical limitations of the module that make this the easiest solution to implement.

 

If you feel that there are drawbacks to this solution, let me know and it can be revisited.

Ok. I thought about it and agree with you. If I would make a plist hidden in root  (I mean outside Extra) I 'd be glad.

 

BTW, In SL 10.6.8 there isn't backlight-level key, do you know how does it save that value?



#55
meklort

meklort

    InsanelyMac Geek

  • Developers
  • 136 posts
  • Gender:Male

Internally there is a way to change the nvram plist path, however it's not expose as a boot argument / configurable (there are certain cases where it'll change however).

 

If you file a bug report, I can add it to the next version (but.... that might take a while to release)



#56
Bungo

Bungo

    InsanelyMac Sage

  • Coders
  • 296 posts
  • Gender:Male

Internally there is a way to change the nvram plist path, however it's not expose as a boot argument / configurable (there are certain cases where it'll change however).

 

If you file a bug report, I can add it to the next version (but.... that might take a while to release)

Filed (in Pre-boot section). Thanks



#57
Bungo

Bungo

    InsanelyMac Sage

  • Coders
  • 296 posts
  • Gender:Male

No. Doing that could cause issues on a PC with multiple versions of OS X installed. It's better to use /Extra on the partition you're actually booting.

I got KP on MV 10.9 and SL 10.6.8 hangs on boot when I placed Extra on both partitions.

 

 

Please report any bugs at https://public.xzenue.com/bugzilla/

Does somebody reads bug reports?



#58
jaymonkey

jaymonkey

    InsanelyMac Protégé

  • Members
  • Pip
  • 11 posts
  • Gender:Male
  • Location:England - UK

Bungo,

 

FileNVRAM will probe all devices that chameleon has read access to for the latest nvram plist file, so it shouldn't matter where it gets saved. The plist is saved on the active system partition due to technical limitations of the module that make this the easiest solution to implement.

 

If you feel that there are drawbacks to this solution, let me know and it can be revisited.

 

Hi,

 

Many thanks to the Developers of FileNVRAM,

 

Its a great solution, works well and It's allowed me to get iMessage (and other features) running on all my OSX systems, however there is one situation that constantly causes FileNVRAM to fail to initialise and load properly and that is when booting OSX from a software Raid (either 0 or 1)

 

In my case I have two 128GB SSD configured as a Raid 0 (stripe). Each Raid member drive has its own Raid Helper Partition (in my case Disk0s3 & Disk1s3) . Because the boot loader has to be accessible outside of OSX (software raid can only work once kernel is up and running) the /Extra folder must reside on the Raid Helper Partition, unfortunately the raid helper partition(s) are unmounted once OSX starts up, thus FileNVRAM is unable to access the /Extra folder as such it fails to load correctly. 

 

The only way around this as far as I know is to clone the raid onto a single HDD, modify the chameleon plist and install the boot loader so that the drive can boot on its own. Then it is possible to install FileNVRAM in the /Extra folder. Once the standalone drive is booted FileNVRAM works and creates its plist in /Extra. Once working you then have to re-clone the standalone drive back to the raid and copy the FileNVRAM plist to each of the /Extra folders on the helper partitions, simply copying the files will not work, you have to clone the whole drive so i'm guessing there are some configuration plists within OSX or the user folder that somehow are linked to the contents of FileNVRAM. Once the cloned SSD is working FileNVRAM works in that it can read the plist from the helper partition, but once loaded it is unable to refresh the contents as the raid helper partitions are no longer accessible so  If you ever get logged out of iMessage you have to do the whole process again.

 

As you can imagine, this is a bit of a pain and I know I am not alone in seeing this problem as users on this and other forums have reported similar issues when using a Raid as the OSX boot drive.

 

I'm guessing that the issue is that FileNVRAM needs to create/access its plist at initialisation, which cant be on the raid as its not active yet and for some reason it cant create it on the OSX Raid Helper partition (file/disk access permissions ?) but even if it could, the Helper Partition is unmounted once the raid is live so its not available to FileNVRAM once OSX is up and running ?

 

Maybe it would be possible to add a config switch to the chameleon plist (or FileNVRAM's own config file) that holds a full drive/path to the FileNVRAM plist, that way the module could stay with the current default behaviour, but if the path it set via plist string then it overrides the default behaviour and forces it the specified drive/path (in my case this could be one of my non raid, OSX data drives which is accessible at all times.

 

Seems this would be the easiest solution to the problem ?

 

Will be happy to provide debug info and beta test if required.

 

Cheers

Jay



#59
theconnactic

theconnactic

    Stubborn AMD user

  • Local Moderators
  • 2,815 posts
  • Gender:Male

cosmo1t, on 21 Feb 2013 - 11:59 PM, said:snapback.png

Please report any bugs at https://public.xzenue.com/bugzilla/



#60
jaymonkey

jaymonkey

    InsanelyMac Protégé

  • Members
  • Pip
  • 11 posts
  • Gender:Male
  • Location:England - UK

 

cosmo1t, on 21 Feb 2013 - 11:59 PM, said:snapback.png

 

 

No Problem,

 

Have posted issue and enhancement request: -

 

https://public.xzenu...w_bug.cgi?id=18

 

Cheers

Jay 








2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy