Possible to clear NVRAM without re-enabling SIP?

[honeycombz]

Hey, wondering if it is possible to clear NVRAM using terminal without re-enabling SIP to avoid having to reboot into recovery mode to disable SIP again.

I haven’t tried this but since it appears you can clear NVRAM from terminal using:

sudo nvram boot-args=”-p -r”

and if I type in

nvram -xp

I can view the variables contained in NVRAM. I can see, csr-active-config which I would think relates to SIP, it seems like there should be a clear command that doesn't touch SIP?

 

[ASentientBot]

You are correct that a full reset of NVRAM will re-enable SIP.

The only solution I know of is to clear the other variables manually. Read the manpage (man nvram) for details, but sudo nvram -d variable_name should work. Repeat this for whatever you want to reset.

 

[honeycombz]

Right, repeating the one by one. Now, in looking at the XML output below, it really seems like it would only be necessary for my purposes to clear the efi-boot-device and efi-boot-device-data variables, thus leaving everything else and SIP disabled. The EFI-Boot-Device is a base64 encoded string that I decoded to see what it contains, and that makes sense but I'm not clear what EFI-Boot-Device-Data contains if I try to decode it I just get malformed input. Is it safe to manually clear those two and see what happens, with the understanding that the worst that could happen is that I just have to reset NVRAM with my keyboard on startup and try again or can I brick my machine messing around with this?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>LocationServicesEnabled</key>
    <data>
    AQ==
    </data>
    <key>SystemAudioVolume</key>
    <data>
    NQ==
    </data>
    <key>SystemAudioVolumeDB</key>
    <data>
    9Q==
    </data>
    <key>bluetoothActiveControllerInfo</key>
    <data>
    BoKsBQAAAAAgXQAf87EmrQ==
    </data>
    <key>bluetoothInternalControllerInfo</key>
    <data>
    BoKsBQAAIF0AH/OxJq0=
    </data>
    <key>csr-active-config</key>
    <data>
    dwAAAA==
    </data>
    <key>efi-boot-device</key>
    <data>
    PGFycmF5PjxkaWN0PjxrZXk+SU9NYXRjaDwva2V5PjxkaWN0PjxrZXk+SU9Qcm92aWRl
    ckNsYXNzPC9rZXk+PHN0cmluZz5JT01lZGlhPC9zdHJpbmc+PGtleT5JT1Byb3BlcnR5
    TWF0Y2g8L2tleT48ZGljdD48a2V5PlVVSUQ8L2tleT48c3RyaW5nPkIzQjlENjc3LUZG
    NDktNDUyMy05OEE5LTdGNUQxMEI4QkY0RTwvc3RyaW5nPjwvZGljdD48L2RpY3Q+PGtl
    eT5CTExhc3RCU0ROYW1lPC9rZXk+PHN0cmluZz5kaXNrNHMyPC9zdHJpbmc+PC9kaWN0
    PjwvYXJyYXk+AA==
    </data>
    <key>efi-boot-device-data</key>
    <data>
    AgEMANBBAwoAAAAAAQEGAAABAQEGAAAAAxIKAAAAAAAAAAQBKgACAAAAKEAGAAAAAADA
    wB46AAAAAHfWubNJ/yNFmKl/XRC4v04CAn//BAA=
    </data>
    <key>prev-lang:kbd</key>
    <data>
    ZW46MA==
    </data>
</dict>
</plist>

 

[ASentientBot]

Right, repeating the one by one. Now, in looking at the XML output below, it really seems like it would only be necessary for my purposes to clear the efi-boot-device and efi-boot-device-data variables, thus leaving everything else and SIP disabled. The EFI-Boot-Device is a base64 encoded string that I decoded to see what it contains, and that makes sense but I'm not clear what EFI-Boot-Device-Data contains if I try to decode it I just get malformed input. Is it safe to manually clear those two and see what happens, with the understanding that the worst that could happen is that I just have to reset NVRAM with my keyboard on startup and try again or can I brick my machine messing around with this?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>LocationServicesEnabled</key>
    <data>
    AQ==
    </data>
    <key>SystemAudioVolume</key>
    <data>
    NQ==
    </data>
    <key>SystemAudioVolumeDB</key>
    <data>
    9Q==
    </data>
    <key>bluetoothActiveControllerInfo</key>
    <data>
    BoKsBQAAAAAgXQAf87EmrQ==
    </data>
    <key>bluetoothInternalControllerInfo</key>
    <data>
    BoKsBQAAIF0AH/OxJq0=
    </data>
    <key>csr-active-config</key>
    <data>
    dwAAAA==
    </data>
    <key>efi-boot-device</key>
    <data>
    PGFycmF5PjxkaWN0PjxrZXk+SU9NYXRjaDwva2V5PjxkaWN0PjxrZXk+SU9Qcm92aWRl
    ckNsYXNzPC9rZXk+PHN0cmluZz5JT01lZGlhPC9zdHJpbmc+PGtleT5JT1Byb3BlcnR5
    TWF0Y2g8L2tleT48ZGljdD48a2V5PlVVSUQ8L2tleT48c3RyaW5nPkIzQjlENjc3LUZG
    NDktNDUyMy05OEE5LTdGNUQxMEI4QkY0RTwvc3RyaW5nPjwvZGljdD48L2RpY3Q+PGtl
    eT5CTExhc3RCU0ROYW1lPC9rZXk+PHN0cmluZz5kaXNrNHMyPC9zdHJpbmc+PC9kaWN0
    PjwvYXJyYXk+AA==
    </data>
    <key>efi-boot-device-data</key>
    <data>
    AgEMANBBAwoAAAAAAQEGAAABAQEGAAAAAxIKAAAAAAAAAAQBKgACAAAAKEAGAAAAAADA
    wB46AAAAAHfWubNJ/yNFmKl/XRC4v04CAn//BAA=
    </data>
    <key>prev-lang:kbd</key>
    <data>
    ZW46MA==
    </data>
</dict>
</plist>

I believe you're correct. In my knowledge, the most damage you can do by clearing EFI variables would be causing the system to not find your boot drive. A PRAM reset (Command+Option+P+R at boot) and then re-selecting the volume in Startup Manager and the Startup Disk preference pane should fix any issues.

If you don't mind me asking, what're you even trying to accomplish? If the computer is booting from the wrong drive, you can just re-select the right one in Startup Disk. If you're trying to remove extra "EFI Boot" options from Startup Manager, I believe the solution is actually to delete extra EFI files from a hidden partition (but look it up, don't just try it).

At this point, a PRAM reset and "csrutil disable" in recovery would've been a lot quicker than this discussion on a forum

 

[honeycombz]

It’s a long story that involves a PCIe card in a Mac Pro 3,1, an SSD Boot Drive connected to that card, and an unsupported OS. If you are interested PM me and I can tell you what’s up but think I've probably already bored the forums with my issues related to that enough already.

 

[ASentientBot]

Sounds a bit out of my depth haha. I have a bit of experience with unsupported macOS installations (helped find some of the patches to run Mojave on that machine, actually!), but not the hardware side at all. Did you make another thread with the problem? I'd be happy to take a look, though I doubt I can help much.