syscl Posted January 1, 2017 Share Posted January 1, 2017 My edit rc script makes only nvram.plist in mac drive root. First delete two nvram files in ESP, Mac root. Then, try my rc script file above link. Tell me brightness work or not. I don't know why not support native nvram in skylake platform. 나의 LG-F410S 의 Tapatalk에서 보냄 In r3974, brightness can be saved correctly. Note: I have to use IntelBacklight.kext, otherwise brightness level cannot be loaded/registered at startup. Can you just use your script without IntelBacklight.kext? There's duplicated nvram.plist(EFI/ and /), I manually removed /nvram.plist, set brightness level to almost minimal, still work like a charm. And, there's no more /nvram.plist generated in next boot. So, duplicated nvram.plist is just in case? Skylake NVRAM issue maybe related to macOS, at the end of ExitBS, nvram is OK, but during macOS, nvram is not OK. syscl Link to comment Share on other sites More sharing options...
Sherlocks Posted January 1, 2017 Share Posted January 1, 2017 In r3974, brightness can be saved correctly. Note: I have to use IntelBacklight.kext, otherwise brightness level cannot be loaded/registered at startup. Can you just use your script without IntelBacklight.kext? There's duplicated nvram.plist(EFI/ and /), I manually removed /nvram.plist, set brightness level to almost minimal, still work like a charm. And, there's no more /nvram.plist generated in next boot. So, duplicated nvram.plist is just in case? Skylake NVRAM issue maybe related to macOS, at the end of ExitBS, nvram is OK, but during macOS, nvram is not OK. syscl i just mentioned brightness load. i'm not mentioned brightness value save in nvram.plist. yes, in nvram.plist, nvram values are no problem. system can't load brightness after reboot. always hold brigtness i already test brightness load after reboot without IntelBacklight.kext. in r3974, brightness load is not work after reboot. ofc i always use IntelBacklight.kext since i use skylake laptop osx. it's not related IntelBacklight.kext about brightness load. did you test my mentioned rc script? like me, i saw other users has this issue in other forum after r3961 build. what is your bios manufacture? my laptop bios is phoenix bios and should use EmulVariableUEFI.efi. if dont have EmulVariableUEFI.efi, i can't get osx windows and any result to boot osx. Link to comment Share on other sites More sharing options...
syscl Posted January 1, 2017 Share Posted January 1, 2017 i just mentioned brightness load. i'm not mentioned brightness value save in nvram.plist. yes, in nvram.plist, nvram values are no problem. system can't load brightness after reboot. always hold brigtness i already test brightness load after reboot without IntelBacklight.kext. in r3974, brightness load is not work after reboot. ofc i always use IntelBacklight.kext since i use skylake laptop osx. it's not related IntelBacklight.kext about brightness load. did you test my mentioned rc script? like me, i saw other users has this issue in other forum after r3961 build. what is your bios manufacture? my laptop bios is phoenix bios and should use EmulVariableUEFI.efi. if dont have EmulVariableUEFI.efi, i can't get osx windows and any result to boot osx. Where's the rc script you write? Happy to test it... What's the meaning after reboot brightness hold? Does that mean you lose the brightness setting after reboot, as brightness sets to default? My laptop: Dell XPS 13 9350. I am not sure what BIOS I have because this bios has new user interface, but I double it's very possible AMI's variant. You mean you have to use EmuVariableUEFI to boot macOS, Windows? syscl Link to comment Share on other sites More sharing options...
Sherlocks Posted January 1, 2017 Share Posted January 1, 2017 Where's the rc script you write? Happy to test it... What's the meaning after reboot brightness hold? Does that mean you lose the brightness setting after reboot, as brightness sets to default? My laptop: Dell XPS 13 9350. I am not sure what BIOS I have because this bios has new user interface, but I double it's very possible AMI's variant. You mean you have to use EmuVariableUEFI to boot macOS, Windows? syscl Brightness hold after reboot. If you set very lower brightness ex. 2/10 before reboot, after reboot system usually remember 2/10 brightness value. But latest rc script is not working this function. http://www.insanelymac.com/forum/index.php?/topic/317290-FileVault-2&do=findComment&comment=2341352 This is brightness load solution after reboot. Tell me work or not compared r3974 나의 LG-F410S 의 Tapatalk에서 보냄 Link to comment Share on other sites More sharing options...
syscl Posted January 1, 2017 Share Posted January 1, 2017 Brightness hold after reboot. If you set very lower brightness ex. 2/10 before reboot, after reboot system usually remember 2/10 brightness value. But latest rc script is not working this function. http://www.insanelymac.com/forum/index.php?/topic/317290-FileVault-2&do=findComment&comment=2341352 This is brightness load solution after reboot. Tell me work or not compared r3974 나의 LG-F410S 의 Tapatalk에서 보냄 No issue on both of your script and the latest 80.save_nvram_plist.local. All work well. The only difference between your script and r3974's are NVRAMDevice=$(findFirstESP) --> NVRAMDevice=${rootDevice} local AppleBootDevice=${rootDevice} --> local AppleBootDevice=$(findFirstESP) syscl Link to comment Share on other sites More sharing options...
Sherlocks Posted January 1, 2017 Share Posted January 1, 2017 No issue on both of your script and the latest 80.save_nvram_plist.local. All can work well. The only difference between your script and r3974's are NVRAMDevice=$(findFirstESP) --> NVRAMDevice=${rootDevice} local AppleBootDevice=${rootDevice} --> local AppleBootDevice=$(findFirstESP) syscl Your laptop brightness load work in latest rc script? Not hold after reboot? Latest rc script remember brightness value after reboot? I miss this behavior. I always use high brightness. So i didnt know this issue first.Big difference Latest rc script make nvram file both efi and mac drive My edit file make only nvram file in mac drive. Clear nvram files and test please again. I want to test very lower brightness before reboot, and boot. 나의 LG-F410S 의 Tapatalk에서 보냄 Link to comment Share on other sites More sharing options...
syscl Posted January 1, 2017 Share Posted January 1, 2017 Your laptop brightness load work in latest rc script? Not hold after reboot? Latest rc script remember brightness value after reboot? I miss this behavior. I always use high brightness. So i didnt know this issue first. Big difference Latest rc script make nvram file both efi and mac drive My edit file make only nvram file in mac drive. Clear nvram files and test please again. I want to test very lower brightness before reboot, and boot. 나의 LG-F410S 의 Tapatalk에서 보냄 Give me 1 sec... syscl Your laptop brightness load work in latest rc script? Not hold after reboot? Latest rc script remember brightness value after reboot? I miss this behavior. I always use high brightness. So i didnt know this issue first. Big difference Latest rc script make nvram file both efi and mac drive My edit file make only nvram file in mac drive. Clear nvram files and test please again. I want to test very lower brightness before reboot, and boot. 나의 LG-F410S 의 Tapatalk에서 보냄 I double check your script and the latest one with the following step: - Remove nvram.plist on / and EFI/ - Remove /etc/rc.shutdown.d/* - Reboot - Copy your 80.save_nvram_plist.local under /etc/rc.shutdown.d/ - Ensure there's no nvram.plist in / and EFI/ in my case, there's no new nvram.plist being genreated - Reboot - Set brightness to minimal(almost invisible) - Reboot - Lowest brightness are loaded during boot - Reboot again to ensure - Lowest brightness is loaded again - There's only /nvram.plist being generated - Set brightness to maximum then reboot - Highest brightness is loaded during boot - Reboot again to ensue - Highest brightness is loaded again Then, I remove your script, remove /nvram.plist - Reboot(brightness set to default automatically by IntelBacklight) - Install official r3974's 80.save_nvram_plist.local - Reboot - Set brightness to lowest - Reboot - Lowest brightness is loaded correctly - Reboot again to ensure - Lowest brightness - Set brightness to maximum - Reboot - Max brightness is loaded and /nvram.plist occurs but there's no nvram.plist in EFI/ - Reboot - Max brightness still no nvram.plist in EFI/ this time A brief conclusion, both work as expect. But, the r3974's script behaves somewhat weird: - First time I installed it, nvram.plist will be in both / and EFI/ - Second time when I removed Sherlock's script then install r3974's script, there's no nvram.plist being generated in EFI/ I have to see what's wrong with the latest script. syscl 2 Link to comment Share on other sites More sharing options...
Sherlocks Posted January 1, 2017 Share Posted January 1, 2017 Give me 1 sec... syscl I double check your script and the latest one with the following step: - Remove nvram.plist on / and EFI/ - Remove /etc/rc.shutdown./* - Reboot - Copy your 80.save_nvram_plist.local under /etc/rc.shutdown.d/ - Ensure there's no nvram.plist in / and EFI/ in my case, there's no new nvram.plist being genreated - Reboot - Set brightness to minimal(almost invisible) - Reboot - Lowest brightness are loaded during boot - Reboot again to ensure - Lowest brightness is loaded again - There's only /nvram.plist being generated - Set brightness to maximum then reboot - Highest brightness is loaded during boot - Reboot again to ensue - Highest brightness is loaded again Then, I remove your script, remove /nvram.plist - Reboot(brightness set to default automatically by IntelBacklight) - Install official r3974's 80.save_nvram_plist.local - Reboot - Set brightness to lowest - Reboot - Lowest brightness is loaded correctly - Reboot again to ensure - Lowest brightness - Set brightness to maximum - Reboot - Max brightness is loaded and /nvram.plist occurs but there's no nvram.plist in EFI/ - Reboot - Max brightness still no nvram.plist in EFI/ this time A brief conclusion, both work as expect. But, the r3974's script behave somewhat weird: - First time I installed it, nvram.plist will in both / and EFI/ - Second time when I removed Sherlock's script then install r3974's script, there's no nvram.plist being generated in EFI/ I have to see what's wrong with the latest script. syscl Thank you for hard report. My rc script brightness load is no problem. For latest rc script test Remove all nvram file in root and esp And install clover pkg. I exprienced it like you said. After My rc script test, move latest rc script test, i first see its work, there is no nvram file in ESP but clear nvram file and other. Then test again. Not work for me with exist nvram file in ESP Because of this pattern, i cant think whether work or not Thank you 나의 LG-F410S 의 Tapatalk에서 보냄 1 Link to comment Share on other sites More sharing options...
tluck Posted January 1, 2017 Share Posted January 1, 2017 nvram.plist with 3974 - for some reason about 1/2 of the time, the script cannot save nvram.plist to /Volumes/ESP ( and why in the root of ESP vs say in the OEM or CLOVER folder?) and so it puts in /nvram.plist $ cat /Library/Logs/CloverEFI/rc.shutdown.log-------------------------------DATE: 2017-01-01 TIME: 18:08:04------------------------------->> Begin Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.localNVRAM couldn't be saved to nvram.plist on root of disk0s1 !NVRAM saved to '/nvram.plist' [disk0s2]>> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local 2 Link to comment Share on other sites More sharing options...
Sherlocks Posted January 2, 2017 Share Posted January 2, 2017 nvram.plist with 3974 - for some reason about 1/2 of the time, the script cannot save nvram.plist to /Volumes/ESP ( and why in the root of ESP vs say in the OEM or CLOVER folder?) and so it puts in /nvram.plist $ cat /Library/Logs/CloverEFI/rc.shutdown.log ------------------------------- DATE: 2017-01-01 TIME: 18:08:04 ------------------------------- >> Begin Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local NVRAM couldn't be saved to nvram.plist on root of disk0s1 ! NVRAM saved to '/nvram.plist' [disk0s2] >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local me too. Supreme-MBP:~ supreme$ sudo cat /Library/Logs/CloverEFI/rc.shutdown.log Password: ------------------------------- DATE: 2017-01-03 TIME: 02:34:27 ------------------------------- >> Begin Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local NVRAM couldn't be saved to nvram.plist on root of disk0s1 ! NVRAM saved to '/nvram.plist' [disk0s4] >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local Here's why we have two nvram.plist files. Sometimes it is regenerated in the mac install area because it fails to create nvram.plist on the ESP partition. The old code did not create an nvram.plist file on the ESP partition. The nvram file was always created in the Mac install area so that the nvram file never failed to be created. This problem does not occur because I create the nvram file only in the Mac installation area again in the above mentioned section. For this reason, for example, the brightness value is always fixed after rebooting. to avoid this case, i'm using r3974 and old rc script. we need to find solution. but i don't have idea. thank you. 1 Link to comment Share on other sites More sharing options...
syscl Posted January 2, 2017 Share Posted January 2, 2017 Hi all, finally settled down and figured out why we cannot save/dump the nvram.plist to ESP. Let me explain then show my fix. First I noticed the following piece of message from the rc.shutdown.log(my version of 80.save_nvram_plist.local) Found EFI disk0s1 Mount filesystem msdos kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/msdosfs.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/msdosfs.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/msdosfs.kext - (libkern/kext) function disabled. /System/Library/Extensions/msdosfs.kext failed to load - (libkern/kext) function disabled. mount_msdos: msdos filesystem is not available mount_hfs: Invalid argument kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/exfat.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/exfat.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/exfat.kext - (libkern/kext) function disabled. /System/Library/Extensions/exfat.kext failed to load - (libkern/kext) function disabled. mount_exfat: exfat filesystem is not available >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local r-- 1 root wheel 2190 Jan 2 13:52 /Volumes/EFI01/nvram.plist The problem is: at the shutdown stage, copious amount of system services will be closed, we are again in a very limited situation: we cannot use diskutil or mount at this stage to mount even a single ESP. And now we can explain why r3974's 80.save_nvram_plist.local partly work: msdosfs.kext and exfat.kext aren't loaded every time we boot macOS If we by chance mount the ESP(Fat32 or exFat), then system will load msdosfs.kext and exFat.kext, that's why we will see the script partly works Another problem is that Jrs and Taylan's 80.save_nvram_plist.local has copious amount of redundant code, unclear logic, thus I rewrite all of the 80.save_nvram_plist.local myself. Pairing with the touched version of 20.mount_ESP.local(force load msdosfs.kext and exfat.kext during startup), now nvram can be saved in EFI/ as expected. Compared to Jrs and Taylan's script, my version of 80.save_nvram_plist.local has the following advantages clean steps and logic remove redundant operations(we should operate fast at the shutdown stage) dump nvram.plist to all the EFI partitions if possible, and yes, ensure uniqueness of each mounted EFI use EmuVariablePresent to judge if we need to dump NVRAM if mount ESP failed(very possible disk0s1 damage) then dump NVRAM to / (just in case) @Sherlock's version only dump the NVRAM to /, but doesn't really solve the problem. My version of the script not only fix the nvram dump issue but also consider EFI cannot mount case ... How to use my 80.save_nvram_plist.local? place 20.mount_ESP.local to /etc/rc.boot.d place 80.save_nvram_plist.local to /etc/rc.shutdown.d Reboot to see change. Here's the result after using my version 80.save_nvram_plist.local Found EFI disk0s1 Target path: /Volumes/EFI01 EmuVariable is present dump nvram >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local Try the following attachment @gujiangjiang @tluck @Sherlock @Slice syscl_save_nvram.zip I have successfully tested on XPS 13 9350 Skylake. Best wishes, syscl 5 Link to comment Share on other sites More sharing options...
hackedWifi Posted January 2, 2017 Share Posted January 2, 2017 Hi all, finally settled down and figured out why we cannot save/dump the nvram.plist to ESP. Let me explain then show my fix. First I noticed the following piece of message from the rc.shutdown.log(my version of 80.save_nvram_plist.local) Found EFI disk0s1 Mount filesystem msdos kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/msdosfs.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/msdosfs.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/msdosfs.kext - (libkern/kext) function disabled. /System/Library/Extensions/msdosfs.kext failed to load - (libkern/kext) function disabled. mount_msdos: msdos filesystem is not available mount_hfs: Invalid argument kext-dev-mode allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext '/System/Library/Extensions/exfat.kext' kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Libkern.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Unsupported.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/Mach.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/System.kext/PlugIns/BSDKernel.kext" kext signature failure override allowing invalid signature -2147409622 0xFFFFFFFF8001212A for kext "/System/Library/Extensions/exfat.kext" (kernel) Kext loading is disabled. Failed to load /System/Library/Extensions/exfat.kext - (libkern/kext) function disabled. /System/Library/Extensions/exfat.kext failed to load - (libkern/kext) function disabled. mount_exfat: exfat filesystem is not available >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local r-- 1 root wheel 2190 Jan 2 13:52 /Volumes/EFI01/nvram.plist The problem is: at the shutdown stage, copious amount of system services will be closed, we are again in a very limited situation: we cannot use diskutil or mount at this stage to mount even a single ESP. And now we can explain why r3974's 80.save_nvram_plist.local partly work: msdosfs.kext and exfat.kext aren't loaded every time we boot macOS If we by chance mount the ESP(Fat32 or exFat), then system will load msdosfs.kext and exFat.kext, that's why we will see the script partly works Another problem is that Jrs and Taylan's 80.save_nvram_plist.local has copious amount of redundant code, unclear logic, thus I rewrite all of the 80.save_nvram_plist.local myself. Pairing with the touched version of 20.mount_ESP.local(force load msdosfs.kext and exfat.kext during startup), now nvram can be saved in EFI/ as expected. Compared to Jrs and Taylan's script, my version of 80.save_nvram_plist.local has the following advantages clean steps and logic remove redundant operations(we should operate fast at the shutdown stage) dump nvram.plist to all the EFI partitions if possible, and yes, ensure uniqueness of each mounted EFI use EmuVariablePresent to judge if we need to dump NVRAM if mount ESP failed(very possible disk0s1 damage) then dump NVRAM to / (just in case) @Sherlock's version only dump the NVRAM to /, but doesn't really solve the problem. My version of the script not only fix the nvram dump issue but also consider EFI cannot mount case ... How to use my 80.save_nvram_plist.local? place 20.mount_ESP.local to /etc/rc.boot.d place 80.save_nvram_plist.local to /etc/rc.shutdown.d Reboot to see change. Here's the result after using my version 80.save_nvram_plist.local Found EFI disk0s1 Target path: /Volumes/EFI01 EmuVariable is present dump nvram >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local Try the following attachment @gujiangjiang @tluck @Sherlock @Slice syscl_save_nvram.zip I have successfully tested on XPS 13 9350 Skylake. Best wishes, syscl I just used your scripts on my Dell XPS 15 9550 but it seems like nvram.plist is getting save on / but not on /EFI I deleted the duplicates nvram.plist before adding your script. Found EFI disk0s1 Target path: / EmuVariable is present dump nvram >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local Link to comment Share on other sites More sharing options...
syscl Posted January 2, 2017 Share Posted January 2, 2017 I just used your scripts on my Dell XPS 15 9550 but it seems like nvram.plist is getting save on / but not on /EFI I deleted the duplicates nvram.plist before adding your script. Found EFI disk0s1 Target path: / EmuVariable is present dump nvram >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local You need to use the touched version of 20.mount_ESP.local as well. syscl Link to comment Share on other sites More sharing options...
tluck Posted January 2, 2017 Share Posted January 2, 2017 @syscl - the new scripts are working to write to nvram.plist root of ESP! well in fact it writes nvram to all 3 of my disks in the root dir of ESP. and one of my disks which does not even have EFI/CLOVER its an .apdisk perhaps should check to see if .apdisk is present (i.e. no OS or EFI/CLOVER etc) looks good though 2 Link to comment Share on other sites More sharing options...
syscl Posted January 3, 2017 Share Posted January 3, 2017 @syscl - the new scripts are working to write to nvram.plist root of ESP! well in fact it writes nvram to all 3 of my disks in the root dir of ESP. and one of my disks which does not even have EFI/CLOVER its an .apdisk perhaps should check to see if .apdisk is present (i.e. no OS or EFI/CLOVER etc) looks good though Yes, this script will find all the ESP then dump to all of them. Actually I care about this behaviour too, that's why I include gRootInfo as well. A common scenario is a laptop with two or three hard drive and each has the Clover boot loader. Another scenario is that some people just use external EFI with Clover to boot.... In all, I am not sure this behaviour is good or not. We need to discuss or make an agreement on weather dump to all ESP or just dump to the current ESP.. @Slice @Sherlock @gujiangjiang @tluck any suggestion? If we reach the agreement, I can soon refine it Thanks in advance, syscl 2 Link to comment Share on other sites More sharing options...
Sherlocks Posted January 3, 2017 Share Posted January 3, 2017 Yes, this script will find all the ESP then dump to all of them. Actually I care about this behaviour too, that's why I include gRootInfo as well. A common scenario is a laptop with two or three hard drive and each has the Clover boot loader. Another scenario is that some people just use external EFI with Clover to boot.... In all, I am not sure this behaviour is good or not. We need to discuss or make an agreement on weather dump to all ESP or just dump to the current ESP.. @Slice @Sherlock @gujiangjiang @tluck any suggestion? If we reach the agreement, I can soon refine it Thanks in advance, syscl nvram.plist generate ESP and mac root? i have nvram.plist file both ESP and Mac root. brightness load are working. Supreme-MBP:~ supreme$ diskutil list /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *256.1 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Microsoft Basic Data Windows 7 110.0 GB disk0s2 3: Microsoft Basic Data Win Data 60.1 GB disk0s3 4: Apple_HFS Macintosh SSD 69.1 GB disk0s4 5: Apple_Boot Recovery HD 650.0 MB disk0s5 6: Apple_HFS Mac Data 16.0 GB disk0s6 Supreme-MBP:~ supreme$ Last login: Tue Jan 3 09:45:40 on console Supreme-MBP:~ supreme$ sudo cat /Library/Logs/CloverEFI/rc.shutdown.log Password: Found EFI disk0s1 Target path: /Volumes/EFI01 EmuVariable is present dump nvram >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local Supreme-MBP:~ supreme$ i wonder do you plant to add "chflags hidden "${mntpt}/${NVRAMFilename}""? about hidden nvram.plist if we can solve nvram problem. thank you for hard work. 1 Link to comment Share on other sites More sharing options...
syscl Posted January 3, 2017 Share Posted January 3, 2017 nvram.plist generate ESP and mac root? i have nvram.plist file both ESP and Mac root. brightness load are working. i wonder do you plant to add "chflags hidden "${mntpt}/${NVRAMFilename}""? about hidden nvram.plist if we can solve nvram problem. thank you for hard work. No, I mean if we have EFI on disk0s1, disk1s1, and ..., should we need to dump nvram.plist to disk0s1, disk1s1 and ...? Thanks for your tip, I will add chflags hidden for nvram.plist Nice to hear it work! syscl 1 Link to comment Share on other sites More sharing options...
Sherlocks Posted January 3, 2017 Share Posted January 3, 2017 No, I mean if we have EFI on disk0s1, disk1s1, and ..., should we need to dump nvram.plist to disk0s1, disk1s1 and ...? Thanks for your tip, I will add chflags hidden for nvram.plist Nice to hear it work! syscl i don't know. i don't have other drive with EFI. i have limit for test. i have only one drive. anyway brightness load and nvram value load are good. if confirm all nvram issue solved, hope to have nvram.plist file hidden feature in future. thank you so much. Link to comment Share on other sites More sharing options...
barijaona Posted January 3, 2017 Share Posted January 3, 2017 I'd prefer the nvram.plist not be hidden. It could become very tricky for the average user in situations where physical NVRAM works. Envoyé de mon iPhone en utilisant Tapatalk 1 Link to comment Share on other sites More sharing options...
tluck Posted January 3, 2017 Share Posted January 3, 2017 syscl how about 1) /EFI/CLOVER/OEM/<board>/nvram.plist and for no OEM 2) /EFI/CLOVER/nvram.plist and 3) if there is not /EFI/CLOVER - dont write it. 2 Link to comment Share on other sites More sharing options...
gujiangjiang Posted January 3, 2017 Share Posted January 3, 2017 I'd prefer the nvram.plist not be hidden. It could become very tricky for the average user in situations where physical NVRAM works. Envoyé de mon iPhone en utilisant Tapatalk If nvram is visable,it have change be delete so i prefer it be hidden. If you want to judge if nvram is work you can use terminal such as "ls" to found if have nvram.plist found. syscl how about 1) /EFI/CLOVER/OEM/<board>/nvram.plist and for no OEM 2) /EFI/CLOVER/nvram.plist and 3) if there is not /EFI/CLOVER - dont write it. Yes i agree with you but the nvram can't detect the original board id you have such as "XPS 15 9550" because the DMI has been changed after macOS boot.If this can be solved it maybe very fine. Thanks for your suggestion. Link to comment Share on other sites More sharing options...
syscl Posted January 3, 2017 Share Posted January 3, 2017 @gujiangjiang @tluck @Sherlock @Slice Try the latest 80.save_nvram_plist.local, improvements use mount_hfs instead of mount -t hfs to mount hfs EFI use @tluck's suggestion if there's no Clover under EFI, return if root volume and EFI are on the same disk, nvram.plist should be either in / or EFI/ Note: This script will write nvram.plist to all the EFI which contains Clover syscl_save_nvram.zip Good luck, syscl 2 Link to comment Share on other sites More sharing options...
Sherlocks Posted January 3, 2017 Share Posted January 3, 2017 @gujiangjiang @tluck @Sherlock @Slice Try the latest 80.save_nvram_plist.local, improvements use mount_hfs instead of mount -t hfs to mount hfs EFI use @tluck's suggestion if there's no Clover under EFI, return if root volume and EFI are on the same disk, nvram.plist should be either in / or EFI/ Note: This script will write nvram.plist to all the EFI which contains Clover syscl_save_nvram.zip Good luck, syscl brigntness load is no problem. i saw difference that generate nvram.plist in ESP, root like you mentioned, if root volume and EFI are on the same disk, nvram.plist should be either in / or EFI/ in previous version, generate nvram.plist both ESP and root. but now, only make nvram.plist in root. Supreme-MBP:~ supreme$ sudo cat /Library/Logs/CloverEFI/rc.shutdown.log Password: v1.1 © 2017 syscl/lighting/Yating Zhou Found EFI disk0s1 Target path: / EmuVariable is present dump nvram >> End Script: /private/etc/rc.shutdown.d/80.save_nvram_plist.local Supreme-MBP:~ supreme$ basically feature is good like old rc script. i'm not sure nvram.plist about FileVault2. latest rc script in r3974, to use FileVault2, make nvram in ESP. i don't know exactly right or not. because i don't use FileVault2. your script maybe need to test FileVault2 feature. thank you. 1 Link to comment Share on other sites More sharing options...
syscl Posted January 3, 2017 Share Posted January 3, 2017 brigntness load is no problem. i saw difference that generate nvram.plist in ESP, root like you mentioned, if root volume and EFI are on the same disk, nvram.plist should be either in / or EFI/ in previous version, generate nvram.plist both ESP and root. but now, only make nvram.plist in root. basically feature is good like old rc script. i'm not sure nvram.plist about FileVault2. latest rc script in r3974, to use FileVault2, make nvram in ESP. i don't know exactly right or not. because i don't use FileVault2. your script maybe need to test FileVault2 feature. thank you. Thanks for your feedback. The script is pretty much the same as previous one. Before, we dump nvram to not only EFI/ and / just in case, but now, nvram will only present in either EFI/ or /. That's the major difference. I notice another trivial/small bug that will cause nvram dump to / instead of EFI/. That is msdosfs.kext will automatically unload by system if you put system into sleep... A simply solution is to install sleepwatcher then kextload msdosfs.kext... I want to find a better solution if there has. But since this script performs well if mount EFI fail, we now need testers to test this script on FileVault2. Again, thanks for your feedback, syscl Link to comment Share on other sites More sharing options...
Sherlocks Posted January 3, 2017 Share Posted January 3, 2017 Thanks for your feedback. The script is pretty much the same as previous one. Before, we dump nvram to not only EFI/ and / just in case, but now, nvram will only present in either EFI/ or /. That's the major difference. I notice another trivial/small bug that will cause nvram dump to / instead of EFI/. That is msdosfs.kext will automatically unload by system if you put system into sleep... A simply solution is to install sleepwatcher then kextload msdosfs.kext... I want to find a better solution if there has. But since this script performs well if mount EFI fail, we now need testers to test this script on FileVault2. Again, thanks for your feedback, syscl Here's why rc scripts are starting to change since r3961 http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2332320 Link to comment Share on other sites More sharing options...
Recommended Posts