Jump to content

FileNVRAM 1.1.3 Released


cosmo1t
 Share

80 posts in this topic

Recommended Posts

xZenue is proud to present

FileNVRAM.dylib

https://public.xzenue.com/downloads/

version 1.1.3

FileNVRAM Release Notes

 

========= Version 1.1.3 =======

* Fixed an potential issue where boot-args could get mangled.

* Fixed an issue where certain legacy variables were saved incorrectly.

* Fixed an issue where certain nvram variables not write to the file immediately.

 

========= Version 1.1.2 =======

* Fixed a regression in 1.1.1 causing sleep to break.

 

========= Version 1.1.1 =======

* Fixed an issue where non-root users could delete variables

* Fixed a potential issue with sleep

* Fixed a potential issue with 10.8.3

* Fixed an issue where boot-args remain after deleted on the command line.

* Update ROM generation to generate a random value.

 

===================

FileNVRAM.dylib

===================

 

FileNVRAM copyright xZeneu LLC.

FileNVRAM is licensed under the Attribution-NonCommercial 3.0 Unported license.

Please see the license file for details

 

 

===================

Bugs

===================

 

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

 

 

===================

Requirements

===================

 

- Chameleon r2181 or newer

 

===================

Usage

===================

 

- Install the FileNVRAM.dylib to /Extra/modules/

- Reboot

 

Use the nvram command to manipulate variables

  • Like 7
Link to comment
Share on other sites

Just adding to what Gringo Vermelho said: or just start typing something at the boot menu, then the stored boot flags will appear and you can just delete them with the backspace key, finally typing the ones you want to use (or none at all, but in this case you'll need to do it every boot). I just learned it's fixed. :)

Link to comment
Share on other sites

With this version, my autogenerated ROM value is became this: "i%1b(%e0%96%00"

This is nothing related to my MAC address, none of the characters are in my MAC address, and what the hell is that "(" in it? :worried_anim:

 

Bug in the auto ROM value generator?

Link to comment
Share on other sites

With this version, my autogenerated ROM value is became this: "i%1b(%e0%96%00"

This is nothing related to my MAC address, none of the characters are in my MAC address, and what the hell is that "(" in it? :worried_anim:

 

Bug in the auto ROM value generator?

 

The autogenerated rom has never been your mac address. IT's randomnly generated. If this is causing things to not work for you please file a bug @ the link in post #1

Link to comment
Share on other sites

It's a random number. If it happens to be equivalent to an ascii printable character, it'll print out as that char (such as the '('). If not it'll print out as hex (%NN)

 

The value is the the same either way, it's just how nvram is printing it for human readability.

Link to comment
Share on other sites

The value is the the same either way, it's just how nvram is printing it for human readability.

 

Hi, meklort!

 

If it's that way for the sake of aesthetics (because it's not readable either way in the end), i really think printing as a hex string is a better choice.

 

Best regards!

Link to comment
Share on other sites

Hi, meklort!

 

If it's that way for the sake of aesthetics (because it's not readable either way in the end), i really think printing as a hex string is a better choice.

 

Best regards!

 

Tell apple that, they are the ones who wrote the nvram program

  • Like 1
Link to comment
Share on other sites

Sorry, but i am a bit a "noob" for that nvram usage ;)

 

If i use nvram -p command - without that module installed - to show variables i get :

 

GA_EP35:~ andreasm$ nvram -p

SystemAudioVolume 0

fmm-computer-name GA_EP35

 

If i would use / install that nvram module (with chameleon 2181+) what new variables would exist / what would be changed / what things may work better?

Or, if no new nvram variables are automaticly created by the module, which variables maybe usefull to create + use?

Link to comment
Share on other sites

A little feedback:

 

Something is wrong. My Wifi no longer connects to a wifi network when it hits the desktop (it connects a few seconds after hitting the desktop). Not only this I have to wait between 45 seconds to a minute for my bluetooth dongle to work when I hit the desktop.

Link to comment
Share on other sites

A little feedback:

 

Something is wrong. My Wifi no longer connects to a wifi network when it hits the desktop (it connects a few seconds after hitting the desktop). Not only this I have to wait between 45 seconds to a minute for my bluetooth dongle to work when I hit the desktop.

if you have a bug to file please file it @ the link in post #1.

 

Try dleeting al the nvram variables that are related to wifi/bluetooth.

 

or boot -s, and dleete the nvram.{censored}.plist and reboot

Link to comment
Share on other sites

if you have a bug to file please file it @ the link in post #1.

 

Try dleeting al the nvram variables that are related to wifi/bluetooth.

 

or boot -s, and dleete the nvram.{censored}.plist and reboot

 

Disregard my bluetooth and wifi woes.

 

It was a hardware problem that has been taken care of

Link to comment
Share on other sites

Sorry, but i am a bit a "noob" for that nvram usage ;)

 

If i would use / install that nvram module (with chameleon 2181+) what new variables would exist / what would be changed / what things may work better?

Or, if no new nvram variables are automaticly created by the module, which variables maybe usefull to create + use?

 

Here's how I understand that (If I'm wrong please correct me):

OS X saves some settings in NVRAM (Non-Volatile RAM). PC doesn't have that. So every boot these settings are restored to default values. This module writes and restores them from a file created in /Extra directory. So for example, after reboot it will remember your volume settings, brightness value (on a laptop), etc. It can fix iMessage issues, probably also Find My Mac.

Link to comment
Share on other sites

The boot-args are in addition to whatever is in the plist. If you don't want one, just set it using nvram boot-args="-v other flags" or delete it with nvram -d boot-args. Alternatively you can update the boot args in chameleon by updating the command line.

Link to comment
Share on other sites

The boot-args are in addition to whatever is in the plist. If you don't want one, just set it using nvram boot-args="-v other flags" or delete it with nvram -d boot-args. Alternatively you can update the boot args in chameleon by updating the command line.

 

I get what you're saying but most people are used to updating boot args by editing org.chameleon.boot.plist. This module changes that process and it would be good if the module obeyed what has always been the way to set boot parameters instead of forcing users to learn a new way.

 

If its technically not possible based on the chameleon module architecture then that's one thing but if possible, it would be good to have the option. You could always open source the module and let other developers add that capability ;-)

 

Link to comment
Share on other sites

We do plan on eventualy releasing source for the module, however those plans are not for the immediate future.

 

In any case, enough information is distributed with the module to modify and extend it's behavior. We include the FileNVRAM.h header in the distribution to allow for any developer to create a module that extends this one. Three API function are defined, get, set, and delete NVRAM variable. Using these functions you can do things such as check if the machine has been locked by FMM, check the default partition that was set by the Startup Disk utility in os x, or anything else that you can think of.

 

In the case of boot-args, the FileNVRAM module registers for a notification to the BootOptions hook. If you wish boot-args to not be set (or to be set to a specific value), you can pose as the original caller of that hook and inject your own data.

Link to comment
Share on other sites

are the chameleon boot loader project dead ?

cosmo1t and I do not have much time to work on chameleon and took ourselves off of the project. There are still users with commit access who can develop it as needed, however commit activity is very low.

 

 

i got this plist in the extra folder nvram.ffffffff-ffff-ffff-ffff-001xxxxxxx.plist. what does these ffff meaning?

The UUID was read directly out of the machine's SMBIOS, it's whatever your computer's manufacturer set it to be.

Link to comment
Share on other sites

 Share

×
×
  • Create New...