Transferring data to a new Mac and Terminal settings

Although I never transfer settings from Mac to Mac, I strongly believe that what you ask for specifically never gets transferred, because those are firmware-related settings that are commonly stored in dedicated non-volatile memory, and some settings stored there can actually prevent the system for working correctly or booting. In the case of Intel-based Macs, bad firmware settings can even prevent the system from powering up, requiring pressing a specific key combination to reset those values to restore the system back to a working condition.

To print the variables along with their respective values in Terminal, type:

nvram -p

To print the current value of a specific variable in Terminal, type:

nvram variable

To change the value of a variable in Terminal regardless of whether it already exists, type:

nvram variable='value'

I strongly advise against changing variables that you don't understand, and copy-pasting the names of those you do to prevent accidentally cluttering that space with useless misspells. Also keep in mind that changing a variable overwrites whatever value was previously set, and in some binary value cases, like the power-on boot preferences that you mentioned, combining values is not trivial to people without some development experience since it involves bitwise operations. Finally beware that Intel-based and ARM-based Macs expect completely different and incompatible firmware settings, so sharing the same variables and values between the two architectures will most likely not produce the expected result.

Some variables might require administrator privileges to set or change their values, in which case you must prepend the sudo command before the nvram command and then authenticate for the operation to take effect, as follows:

sudo nvram variable=value

In some cases variables can only be changed from the recovery system, and there are even cases that only software that is ultimately digitally signed by Apple can make changes, so if you get "Operation not permitted" error messages for some variables even after authenticating as a system administrator or booting into recovery, those are the reasons.

Finally, if you wish to prevent an ARM-based MacBook from powering on by a lid open event, I recommend just following the official instructions and doing it manually instead of copying firmware settings from another Mac.

Since you can no longer remember all the changes you made to firmware settings, one strategy is to dump the current settings from both Macs, compare them to get the differences, extract anything that remind you of changes that you might have made, and selectively apply those to the new Mac. If you mess up, the worst that can happen with an ARM-based Mac is to prevent it from booting with a visual error message instructing you to browse a support page on the Apple website, in which case the problem can be fixed by turning the system off, pressing and holding the power or TouchID button for a while until the boot options menu appears (there's no audio feedback for this but 15 seconds should be long enough), pressing Command+F5 to enable the firmware VoiceOver, booting into recovery, entering the required credentials to decrypt the storage, wiping all the current settings, and finally restoring the original settings that you saved earlier.

To dump the current firmware settings to a file named nvram.txt that can be used to compare or restore them later, type the following in Terminal:

nvram -p | sort | tee nvram.txt

If you do the above on both Macs, and since they are both ARM-based, you can then compare both dumps to figure out what changed and selectively apply the relevant changes to the new Mac.

Assuming that you used the above example to dump the firmware settings to two files named nvram-old.txt and nvram-new.txt on the old and new Macs respectively, you can get just the old values that are different on the new Mac by typing the following in Terminal after copying the dump of the old Mac's firmware settings to the new Mac:

 diff -u0 nvram-new.txt nvram-old.txt | perl -ne 'print if s/^\+(?=[^+])//'

Then you can selectively apply any changes by typing the following in Terminal (make sure to include the single quotes around the values):

sudo nvram variable='value'

Since these changes only take effect after a clean shutdown or restart process, you can always undo any mistakes by wiping the current settings and restoring from the previously saved dump. This can be accomplished by typing the following sequence of two commands assuming that it is in a file named nvram-new.txt:

sudo nvram -c
sudo nvram -f nvram-new.txt

The above two-command sequence can also be used to restore the system from recovery if you mess up and have to follow the steps that I mentioned in my first paragraph.

Edited by request of the site administration to attempt posting the message that originally got blocked by Cloudflare, plus taking advantage of this to swap the old and new dump files so you actually get the values on the old Mac displayed instead of those on the new Mac, which is what was originally intended.

Hi,

Just curious, but are we not permitted to use the <code> tags via the Filtered HTML format on these forums?

I use Markdown instead of HTML for formatting, and since some of the code voice content in my comments goes through, I suppose that something else is triggering Cloudflare. The comment that I tried to post included a Perl regular expression so that's likely what caused the problem, however this security protection seems to be new, as this is not the first time I post regular expressions to this forum, and this one in particular wasn't even remotely close to worse offenders that went through in the past. I've also experienced it while trying to post a short sample of Objective-C code to retrieve the names of connected audio devices not long ago which I had to work around by posting the code as a GitHub Gist, as well as when I tried to post instructions on how to run a large language model on macOS locally from the command-line.

The front page of this website states the following as its mission:

AppleVis is the go-to resource for blind, DeafBlind, and low vision users of Apple technologies. A proud member of the Be My Eyes family, AppleVis' mission is to empower people who are blind, DeafBlind, or who have low vision to get the most from Apple products and services. With an active, engaged user base and a vast collective understanding of vision accessibility on Apple's platforms, members of our community support each other in accessing the maximum potential of Apple hardware, software, and services.

My stance is that the aforementioned overly conservative security protections are getting in the way of the previously quoted mission of the site, especially considering that there's even an app development forum on the site to which it's perfectly reasonable to expect an unhindered ability to post code. While in some generic cases it's OK to post samples as GitHub Gists and link them here since they are sufficiently general purpose, I don't think that the same applies to cases like this thread in particular where I'm trying to provide a solution to a specific problem.

Hi João,

Our position is that allowing the sharing of code on the site introduces an unacceptably high level of security risk, due to the potential of code injection from bad actors. I understand and appreciate your position and where you are coming from, and I will take another look at this issue with my team this week. However, if no solution can be found that sufficiently mitigates the risk, our current policy will need to remain in place.

@João Santos,
I personally do not know how long this particular rule has been in effect, but a few years ago, when I was more active with macOS, I remember I used to post several tips on here with regards to things like Apple scripts, some terminal tips and tricks, etc. I remember sometimes my posts would not go through either. Wondering if it was due to the same issue?
anyway, thank you for the explanation.