storessraka.blogg.se

1. #Clover configurator boot volume driver#
2. #Clover configurator boot volume Patch#
3. #Clover configurator boot volume code#

#Clover configurator boot volume driver#

Config changes (and driver updates) will benefit all the systems (starting from Yosemite if I remember correctly), not just 10.13.6 Revision 4515 incorporates them in Clover.Ģ) AptioMemoryFix must be R20 (b83c025) or newerģ) Boot → RtcHibernateAware must be set to YES

#Clover configurator boot volume code#

Starting with 10.13.6 a lot of legacy code got (finally) ditched on Apple side, and some changes are necessary to get hibernation to work on hacks. Revision 4450 introduced a new key (Boot → RtcHibernateAware) which improved the situation with hibernation compatibility and reduced the impact of some security issues in this process.

#Clover configurator boot volume Patch#

However, if RtcHibernateAware does not work for you, enabling AppleRTC patch and using HibernationFixup may be a safer workaround. You should DISABLE them if you have no issues with BIOS preferences afterwards or use HibernationFixup.

Note, that AppleRTC or FixRTC patches effectively break hibernation by reducing the available RTC memory and avoiding encryption key preservation. While it is extremely recommended to be turned on if you rely on hibernation, it may not work on your hardware (should be fine on Ivy Bridge and newer at least), and is thus optional and disabled by default. This option relies on a poorly documented (or rather undocumented) RTC memory access, and unspecified RTC memory layout, which is implementation-specific. To workaround this issue a new option enabling RTC memory erase upon waking from hibernation was added:īoot > RtcHibernateAware = YES (BOOLEAN, off by default) More details could be found in this message. To be used for Hibernation modes 25 & 3 with Lilu.kext and HibernationFixup.kext.Ī data leak issue was identified in the hibernation code, allowing hibernation encryption key to be passed to the system through RTC and preserved till the next hibernation without a subsequent erase. However, the graphics output protocol is not in anyway modified so if the OS draws after it is started then it is after the boot screen is drawn and will overwrite the custom logo, at least for now. The CustomLogo key can also be used under GUI/Custom/Entries in conjunction with BootBgColor for a different screen for every OS. If no option is specified then the boot screen will be drawn only for >= 10.10 Yosemite, so it remains compatible with previous behavior. - A base64 encoded PNG, BMP, or ICNS data.Path - A file path to load a custom image from.None - Use no logo only background color, gray if not specified by custom entry.Theme - Use the theme boot screen for entry type - NOT IMPLEMENTED.