First, the usual, thanks for all the great work. This project is pure goodness.
On to it: Wondering why we still proceed with a shutdown hook to capture and save nvram key-values to a file... especially since when we run an installer image, those hooks aren't present and thus the nvram modifications are lost.
My goal was to create a boot usb key which would not contain any OSes but simply contain clover and all that is needed to run a vanilla mac os install on a legacy BIOS board. Saving the nvram variables is pretty much what's left standing in the way of having this key complete.
I have changed the save_nvram_plist script to find the actual ESP where clover booted from (through ioreg analysis). It is attached to this post. It is a fork of the script from v2.3k_r3974. See attached.
Now it works well in that it doesn't care about the current OS disk running, but rather assumes that the clover EFI partition is the best spot. It allows me to have one single clover boot partition, from which I can boot any of my installs, test installs, clone backups, etc.
BUT, it nvram changes made into installer boots are still lost.
SO, is it not possible to have a fake UEFI handler/driver (I'm new at this) which would actually catch the expected firmware or SMC "functions" and save the nvram data to a file, or a fixed sector of a block device (USB or whatever). I know the legacy BIOS RTC memory won't fit the nvram data, but we should be able to spare a few sectors and do very raw, BIOS like, write operations no?
I am a professional linux embedded developer but have never actually developed on my macs. I started casually browsing clover source code but would need pointers to get started, if it's at all possible.
Really looking forward to contributing!