Jump to content

greatcornholio

Members
  • Content Count

    2
  • Joined

  • Last visited

About greatcornholio

  • Rank
    InsanelyMac Protégé

Profile Information

  • Gender
    Male
  • Location
    Canada
  1. greatcornholio

    Clover General discussion

    Thanks for your answer. I know, this is why I was mentioning it. I know if I start the installer from my actual OS partition (which is setup to save nvram plist) some values are set to assist the reboot which completes the install. I assume the installer removes those. When emerging from the update in the real OS disk, these new key-values are still present. These are "install-product-url" and "rc_imgsrc_info". I had to manually remove them. Weather these are crucial or not I don't know. Again, with the goal to keep the OS disk perfectly vanilla (rescue, install or real disk), since clover does kext injection, it would assume a kext could be written. This kext would grab all variables when asked to unload at shutdown and dump them in binary form to a storage device (maybe straight to device in a reserved area). In fact, why is that not in FakeSMC.kext? Isn't the SMC responsible for saving nvram on real macs? I'll keep digging.
  2. greatcornholio

    Clover General discussion

    Hi Guys! 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! 80.save_nvram_plist.local.zip
×