CleanNVRAM vs resetNVRAM in OpenCore 0.7.0 - a question

[kentval]

Does anyone know the difference between the tools "cleannvram" and "resetnvram"? I could not find it on GitHub...

TIA

 

[Middleman]

I would think they are named as so as they each have their distinct functions. The cleannvram would likely be used to remove any corruption of data in the NVRAM whilst the resetnvram is used to wipe and clear (empty) the NVRAM.

 

[kentval]

Thanks... that would be my guess too. But I was hoping to find someone who actually knows. ClearNvram would be a good thing, depending on what it does not clear

 

[etorix]

I think that both perform the same function, but CleanNvram is an EFI executable while ResetNvram is integrated into OpenCore. It is however not apparent why the older CleanNvram.efi has not been dropped after ResetNvram was added.

 

[miliuco]

Thanks... that would be my guess too. But I was hoping to find someone who actually knows. ClearNvram would be a good thing, depending on what it does not clear

ResetNVRAM: included into Opencore, available as a special tool when AllowNvramReset is set to true.

CleanNvram: ResetNVRAM alternative bundled as a standalone tool, available when included into Tools folder and config.plist.

 

[kentval]

Thanks to one and all. So judging by what I read here, "Clean" really means "reset" as they both do the same thing. Resetting the NVRAM can be problematic, having been there and done that. It may require, for example, booting from some other device and setting the boot device back to the built-in. I was kind of hoping for something that would (for example) leave the NVRAM with Apple's minimum requirements while clearing out the cruft that lots of third-party software sticks in there.

Thanks again.

 

[miliuco]

Thanks to one and all. So judging by what I read here, "Clean" really means "reset" as they both do the same thing. Resetting the NVRAM can be problematic, having been there and done that. It may require, for example, booting from some other device and setting the boot device back to the built-in. I was kind of hoping for something that would (for example) leave the NVRAM with Apple's minimum requirements while clearing out the cruft that lots of third-party software sticks in there...

But I think that variables stored in NVRAM are not in general from third-party software but rather equivalent to those that Apple uses on Macs. And there aren't many. At least this is the intention of the Opencore developers.
For example, in my hack these are the NVRAM variables:

% /Users/yo > nvram -p
bluetoothInternalControllerInfo    %8d%82%ac%05%000b%14%88c%df%8a'%c7
fmm-computer-name    BigSUR
preferred-networks    1
bluetoothActiveControllerInfo    %8d%82%ac%05%00%00%000b%14%88c%df%8a'%c7
preferred-count    1
SystemAudioVolume    %14
run-efi-updater    No%00
LocationServicesEnabled    %01
csr-active-config    %00%00%00%00
boot-args    darkwake=8
ForceDisplayRotationInEFI    %00%00%00%00

There are only 11 variables that can be found on a real Mac except those that are specific to OpenCore.

I can delete them with the -c switch of the nvram command (except those protected by macOS) and this is the same as doing CleanNVRAM or ResetNVRAM except for the fact that the protected ones can be deleted from the OpenCore menu

% /Users/yo > sudo nvram -c
Password:
nvram: Error clearing firmware variable fmm-computer-name: (iokit/common) not permitted
nvram: Error clearing firmware variable csr-active-config: (iokit/common) not permitted

% /Users/yo > nvram -p
csr-active-config    %00%00%00%00
fmm-computer-name    BigSUR

The system recreates those necessary on the first boot.

Don't look at the words, in the OpenCore's Configuration.pdf file you can read "CleanNvram: ResetNVRAM alternative bundled as a standalone tool" from which it follows that both tools do the same.

In my opinion, resetting the NVRAM isn't problematic, some registers are flushed from the motherboard's CMOS (I assume native NVRAM) that will be written again if the system needs it. I don't see any risk in it.

 

[kentval]

Thaks for your patience and courtesy.

I have the ones you have and a few more:

prev-lang:kbd
ota-updateType
ota-controllerVersion
multiupdater-state
multiupdater-retry-limits
efi-boot-device-data
efi-boot-device
efi-backup-boot-device-data
efi-backup-boot-device
SystemAudioVolumeDB
LocationServicesEnabled
_kdp_ipstr (appears to be IP addr)

... all of which look to be legit.

So, I expect your bottom line is correct: it should not hurt. That said, I don't know why it did at least once, and further, looking at these, I don't any particular issues, at least judging by name alone.

I think I'll just let it be.

Thanks again.

 

[miliuco]

Some of those variables are from the last macOS install or update. It’s ok. I can say as you "Thanks for your patience and courtesy".