Jump to content

FileNVRAM 1.1.3 Released

cosmo1t

By cosmo1t,
in Chameleon

 Share
80 posts in this topic

Recommended Posts

Gringo Vermelho
Gringo Vermelho
Posted
Posted

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.

Link to comment
Share on other sites
Bungo
Bungo
Posted
Posted

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).

Link to comment
Share on other sites
  • 3 weeks later...
meklort
meklort
Posted
Posted

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.

  • Like 2
Link to comment
Share on other sites
Bungo
Bungo
Posted
Posted

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?

Link to comment
Share on other sites
meklort
meklort
Posted
Posted

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)

Link to comment
Share on other sites
Bungo
Bungo
Posted
Posted

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

Link to comment
Share on other sites
  • 2 weeks later...
  • 2 months later...
jaymonkey
jaymonkey
Posted
Posted

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

Link to comment
Share on other sites
  • 4 months later...
  • 2 weeks later...
  • 3 weeks later...
sebus
sebus
Posted
Posted

ML 10.8.5 with Chimera 3.0.1

 

My value of ROM changes randomly on every reboot.

 

Which stops me accessing iMessage & Facetime.

 

I apply:

 

sudo nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:ROM=xxxxxxxxxxxx

 

and on reboot this value changes to something else completely, and same on each reboot

 

Also the bug (reported) https://public.xzenue.com/bugzilla/show_bug.cgi?id=19

 

definitely exists. Facetime works with empty ROM, but iMessage does not

 

sebus

Link to comment
Share on other sites
  • 2 weeks later...
pkdesign
pkdesign
Posted
Posted

Not sure if this will help anyone but FWIW:

 

I boot using a USB thumbdrive. In trying to track down Messages and Facetime issues I realized that FileNVRAM was not writing the nvram.xx.plist to the /Extra folder on the USB thumbdrive. I had to manually create the /Extra folder on the root of my hard drive, reboot, copy the plist that was created in that folder to the /Extra folder on the USB thumbdrive. After rebootintg the MLB and ROM values stayed constant. That allowed me to call Apple and get the block removed. Now Messages and Facetime  work perfectly. I was able to delete the /Extra folder on the root of my hard drive and everything continues to work.

 

Thanks to all the hard work these developer do!

Link to comment
Share on other sites
  • 1 month later...
theconnactic
theconnactic
Posted
Posted

It won't work with Yosemite, that's old news: why people still insist? Unless meklort or cosmo1t say otherwise, FileNVRAM development is stalled. Chameleon based systems won't be supporting iMessage for now. Most important, uni-multi-tools based systems won't do it too: because I really think the growing demand for a Chameleon based solution these past couple of days is because now Voldemort support Yosemite, and since they don't really develop anything, their smarter users end up finding their way here and simply cannot accept their beast-configured machines won't be the Mac clones Voldemort's horcruxes let them think they would.

Link to comment
Share on other sites
tom5151
tom5151
Posted
Posted

It won't work with Yosemite, that's old news: why people still insist? Unless meklort or cosmo1t say otherwise, FileNVRAM development is stalled. Chameleon based systems won't be supporting iMessage for now. Most important, uni-multi-tools based systems won't do it too: because I really think the growing demand for a Chameleon based solution these past couple of days is because now Voldemort support Yosemite, and since they don't really develop anything, their smarter users end up finding their way here and simply cannot accept their beast-configured machines won't be the Mac clones Voldemort's horcruxes let them think they would.

 

Doesn't seem to be totally stalled...

https://public.xzenue.com/websvn/filedetails.php?repname=FileNVRAM&path=%2Ftrunk%2Fdocs%2FNEWS&rev=3&peg=3

  • Like 2
Link to comment
Share on other sites
fusion71au
fusion71au
Posted
Posted

I hope for chameleon users you're right.  However looking at the date of that news, it was from January 2014 and nothing publically announced since then.  Remember Yosemite DPs were released in June....

  • Like 2
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...