Sherlocks Posted January 4, 2017 Share Posted January 4, 2017 Since you post this issue, I want to improve my script to solve your problem as well. I am happy you give so many useful information, give me some time... I will contact you to test new script. Anyway, the major issue is gone. BTW, it's very late in you Korea right? Better to have a rest then talk this later. Thanks, syscl thank you. today i tested about generate nvram file. first, i'm sure that nvram file generated in r3974 rc script. always success 100% for my case. after install pkg, 1 time, remove nvram, 2 times, remove nvram, 3times, no problem. and i tested your script. my EFI folders is remove. also if enter terminal command, stop terminal. and very unstable. reboot. sometime rc script automately remove EFI folder after reboot, i can't get clover GUI. i don't touch anything. just replace and give permission like previous i use something happen to busy and cause to make unstable system. my ESP partition format is msdos. since long time a go, i don't have this problem. old and r3974 rc script. since use your script, this issue happen. i see you change mount method to work ESP mount in your script. but this is not work for me. i tested many times. if you don't believe me, i can give you video file. can you back mount method like r3974 rc script for test? Link to comment Share on other sites More sharing options...
syscl Posted January 4, 2017 Share Posted January 4, 2017 Okay. Once i return old script. old script is stable for me. Thank you. If you improve something, i will help you 나의 LG-F410S 의 Tapatalk에서 보냄 Please try version 1.2 80.save_nvram_plist.local.zip syscl Link to comment Share on other sites More sharing options...
Sherlocks Posted January 4, 2017 Share Posted January 4, 2017 Please try version 1.2 80.save_nvram_plist.local.zip syscl i can get nvram in ESP now. but need more test. Link to comment Share on other sites More sharing options...
syscl Posted January 4, 2017 Share Posted January 4, 2017 i can get nvram in ESP now. but need more test. Please try 1.3 @Sherlock @Slice @gujiangjiang @tluck @cjfly 80.save_nvram_plist.local.zip syscl Link to comment Share on other sites More sharing options...
Sherlocks Posted January 4, 2017 Share Posted January 4, 2017 Please try 1.3 @Sherlock @Slice @gujiangjiang @tluck @cjfly 80.save_nvram_plist.local.zip syscl finally it's good working now. brightness load and nvram value load too. Last login: Wed Jan 4 16:06:13 on console Supreme-MBP:~ supreme$ sudo cat /Library/Logs/CloverEFI/rc.shutdown.log Password: v1.3 © 2017 syscl/lighting/Yating Zhou 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 recommend that remove nvram file in all drive before use syscl's script. 1 Link to comment Share on other sites More sharing options...
barijaona Posted January 4, 2017 Share Posted January 4, 2017 i recommend that remove nvram file in all drive before use syscl's script. As there might be multiple instances of nvram.plist created in different disks / partitions / paths, this is another good reason for scripts not hiding these files. Link to comment Share on other sites More sharing options...
Sherlocks Posted January 4, 2017 Share Posted January 4, 2017 As there might be multiple instances of nvram.plist created in different disks / partitions / paths, this is another good reason for scripts not hiding these files.Yes. Desktop users has many drive. And if unhidden nvram file, we can see nvram easily. My case is laptop. Laptop has one drive. I just suggest it. Maybe Slice decide this hidden or not, now in rc script, unhidden nvram file. Thank you 나의 LG-F410S 의 Tapatalk에서 보냄 Link to comment Share on other sites More sharing options...
cnrd Posted January 4, 2017 Share Posted January 4, 2017 Please try 1.3 @Sherlock @Slice @gujiangjiang @tluck @cjfly 80.save_nvram_plist.local.zip syscl I can confirm that this script also works for my system (Which has had problems with all other scripts), and propose that it is added to Clover. Just one question Syscl: What is the reason you are saving the nvram.plist in both "/" and EFI partition? EDIT: nvram.plist is only saved to EFI partition if I run: sudo kextload /System/Library/Extensions/msdosfs.kext before shutting down. We probably need to load that kext on boot? Link to comment Share on other sites More sharing options...
gujiangjiang Posted January 4, 2017 Share Posted January 4, 2017 Please try 1.3 @Sherlock @Slice @gujiangjiang @tluck @cjfly 80.save_nvram_plist.local.zip syscl I prefer saved to efi only not both. 从我的 iPhone 发送，使用 Tapatalk Link to comment Share on other sites More sharing options...
smolderas Posted January 4, 2017 Share Posted January 4, 2017 I prefer saved to efi only not both. 从我的 iPhone 发送，使用 Tapatalk For those who want to use FileVault 2, it _is_ necessary to use EFI, hence the root partition will be encrypted at that stage. 1 Link to comment Share on other sites More sharing options...
syscl Posted January 4, 2017 Share Posted January 4, 2017 I can confirm that this script also works for my system (Which has had problems with all other scripts), and propose that it is added to Clover. Just one question Syscl: What is the reason you are saving the nvram.plist in both "/" and EFI partition? EDIT: nvram.plist is only saved to EFI partition if I run: sudo kextload /System/Library/Extensions/msdosfs.kext before shutting down. We probably need to load that kext on boot? You also need to use my version of 20.mount.ESP.local and place it to /etc/rc.boot.d syscl Link to comment Share on other sites More sharing options...
cnrd Posted January 4, 2017 Share Posted January 4, 2017 You also need to use my version of 20.mount.ESP.local and place it to /etc/rc.boot.d syscl Yeah I just created my own simple version: $cat 40.load_msdos_kext.local #!/bin/bash kextload /System/Library/Extensions/msdosfs.kext Link to comment Share on other sites More sharing options...
RehabMan Posted January 4, 2017 Share Posted January 4, 2017 Yeah I just created my own simple version: $cat 40.load_msdos_kext.local #!/bin/bash kextload /System/Library/Extensions/msdosfs.kext Will not be reliable. The macOS/OS X kernel employs "lazy unload" of kexts... After some period, given that the kext does not *need* to be in memory (no file systems mounted that need it), it will be unloaded. Link to comment Share on other sites More sharing options...
syscl Posted January 4, 2017 Share Posted January 4, 2017 Yeah I just created my own simple version: $cat 40.load_msdos_kext.local #!/bin/bash kextload /System/Library/Extensions/msdosfs.kext Now the problem is msdosfs.kext will sometimes unload by macOS, for example sleep or simply put your display into sleep but play music... syscl Will not be reliable. The macOS/OS X kernel employs "lazy unload" of kexts... After some period, given that the kext does not *need* to be in memory (no file systems mounted that need it), it will be unloaded. @RehabMan, is there a way to keep msdosfs persist in memory? Or do we need to create a virtual Fat32/exfat device(invisible) to ensure msdosfs is in memory? syscl Link to comment Share on other sites More sharing options...
RehabMan Posted January 4, 2017 Share Posted January 4, 2017 Now the problem is msdosfs.kext will sometimes unload by macOS, for example sleep or simply put your display into sleep but play music... syscl RehabMan, is there a way to keep msdosfs persist in memory? Or do we need to create a virtual Fat32/exfat device(invisible) to ensure msdosfs is in memory? syscl Keeping EFI mounted would probably do the trick... Or mount EFI earlier during the shutdown process (logout hook?) Or maybe a kext with IOResources match that has a dependency on msdosfs. Link to comment Share on other sites More sharing options...
syscl Posted January 4, 2017 Share Posted January 4, 2017 Keeping EFI mounted would probably do the trick... @RehabMan, ah ha, nice(better and reliable than what I used to)... Thank you, syscl 1 Link to comment Share on other sites More sharing options...
RehabMan Posted January 4, 2017 Share Posted January 4, 2017 @RehabMan, ah ha, nice(better and reliable than what I used to)... Thank you, syscl A few other ideas in #1595 edits... 2 Link to comment Share on other sites More sharing options...
syscl Posted January 4, 2017 Share Posted January 4, 2017 Keeping EFI mounted would probably do the trick... Or mount EFI earlier during the shutdown process (logout hook?) Or maybe a kext with IOResources match that has a dependency on msdosfs. Great, especially the logout hook or kext to match msdosfs... About logout hook: if we shutdown, should logout hook be called earlier than shutdown process? Because, during shutdown process, we can do very limited operations, many services are closed at this stage. Thank you again, syscl Link to comment Share on other sites More sharing options...
RehabMan Posted January 4, 2017 Share Posted January 4, 2017 Great, especially the logout hook or kext to match msdosfs... About logout hook: if we shutdown, should logout hook be called earlier than shutdown process? Because, during shutdown process, we can do very limited operations, many services are closed at this stage. Thank you again, syscl I would think logout hook would be earlier. As to whether it is "early enough", you'll find out when you try it... Link to comment Share on other sites More sharing options...
cnrd Posted January 4, 2017 Share Posted January 4, 2017 Looks like it is (very quick test): sudo defaults write com.apple.loginwindow LogoutHook /etc/rc.boot.d/40.load_msdos_kext.local Reboot sudo kextunload com.apple.filesystems.msdosfs To make sure the msdos kext is not loaded. Reboot and nvram.plist in EFI partition was updated. So LogoutHook should be early enough to allow us to load stuff. I used this page for the logoutHook command. 2 Link to comment Share on other sites More sharing options...
syscl Posted January 4, 2017 Share Posted January 4, 2017 Looks like it is (very quick test): sudo defaults write com.apple.loginwindow LogoutHook /etc/rc.boot.d/40.load_msdos_kext.local Reboot sudo kextunload com.apple.filesystems.msdosfs To make sure the msdos kext is not loaded. Reboot and nvram.plist in EFI partition was updated. So LogoutHook should be early enough to allow us to load stuff. I used this page for the logoutHook command. @cnrd, Do you remove any other script that will load the msdosfs.kext? To make sure nvram.plist being refreshed, could you please test the following as well? sudo kextunload msdosfs Then reboot? If this work, our script will be pretty nice to ensure nvram.plist will be dumped to EFI always What I tried with logoutHook: - call diskutil, call ls none of them work - Then, I kextunload msdosfs.kext and logoutHook 80.save_nvram_plist.local, after reboot there's no even a single file being created... Last login: Wed Jan 4 12:38:26 on console syscls-MacBook:~ syscl$ sudo cat /Library/Logs/CloverEFI/rc.shutdown.log Password: ------------------------------- DATE: 2017-01-04 TIME: 12:37:16 ------------------------------- syscls-MacBook:~ syscl$ There must be some restriction during the logoutHook stage to mute all information to log to file. But the funny thing is my script seem to work by using the LogoutHook as well... Here's what I do: - Removed /etc/rc.boot.d/20.mount.ESP.local - Rename /etc/rc.shutdown.d/80.save_nvram_plist.local to /etc/rc.shutdown.d/80.save_nvram_plist.local.syscl - Remove rc.shutdown.log - Reboot - msdosfs.kext is not loaded by kextstat |grep msdos - logoutHook /etc/rc.shutdown.d/80.save_nvram_plist.local.syscl - check msdosfs is not loaded again - change brightness to minimal - reboot - Minimal brightness, nvram.plist created successfully in EFI/, no nvram.plist in / - change brightness to maximum - Remove rc.shudown.log - Reboot - Maximum brightness, nvram in EFI/ being refreshed, no nvram.plist in / A short conclusion by using logoutHook: - we no more need to use touched 20.mount.ESP.local to force load msdosfs.kext - if this method is proved to be stable, then we won't see nvram.plist in root anymore - drawback of this way, we can't see any log, it's hard to solve problem if there has - logoutHook method credit @cnrd and @RehabMan - For detail information credit @Sherlock, very thanks for the test log - Prevent write to EFI without Clover credit @tluck Thank you, syscl 1 Link to comment Share on other sites More sharing options...
Sherlocks Posted January 4, 2017 Share Posted January 4, 2017 @cnrd, Do you remove any other script that will load the msdosfs.kext? To make sure nvram.plist being refreshed, could you please test the following as well? sudo kextunload msdosfs Then reboot? If this work, our script will be pretty nice to ensure nvram.plist will be dumped to EFI always What I tried with logoutHook: - call diskutil, call ls none of them work - Then, I kextunload msdosfs.kext and logoutHook 80.save_nvram_plist.local, after reboot there's no even a single file being created... Last login: Wed Jan 4 12:38:26 on console syscls-MacBook:~ syscl$ sudo cat /Library/Logs/CloverEFI/rc.shutdown.log Password: ------------------------------- DATE: 2017-01-04 TIME: 12:37:16 ------------------------------- syscls-MacBook:~ syscl$ There must be some restriction during the logoutHook stage to mute all information to log to file. But the funny thing is my script seem to work by using the LogoutHook as well... Here's what I do: - Removed /etc/rc.boot.d/20.mount.ESP.local - Rename /etc/rc.shutdown.d/80.save_nvram_plist.local to /etc/rc.shutdown.d/80.save_nvram_plist.local.syscl - Remove rc.shutdown.log - Reboot - msdosfs.kext is not loaded by kextstat |grep msdos - logoutHook /etc/rc.shutdown.d/80.save_nvram_plist.local.syscl - check msdosfs is not loaded again - change brightness to minimal - reboot - Minimal brightness, nvram.plist created successfully in EFI/, no nvram.plist in / - change brightness to maximum - Remove rc.shudown.log - Reboot - Maximum brightness, nvram in EFI/ being refreshed, no nvram.plist in / A short conclusion by using logoutHook: - we no more need to use touched 20.mount.ESP.local to force load msdosfs.kext - if this method is proved to be stable, then we won't see nvram.plist in root anymore - drawback of this way, we can't see any log, it's hard to solve problem if there has - logoutHook method credit @cnrd and @RehabMan - For detail information credit @Sherlock, very thanks for the test log - Prevent write to EFI without Clover credit @tluck Thank you, syscl Good.I'm waiting your script for testing. Thank you 나의 LG-F410S 의 Tapatalk에서 보냄 Link to comment Share on other sites More sharing options...
syscl Posted January 4, 2017 Share Posted January 4, 2017 I would think logout hook would be earlier. As to whether it is "early enough", you'll find out when you try it... Confirmed, logoutHook method work. But there's no log output in rc.shutdown.log now. syscl Good. I'm waiting your script for testing. Thank you 나의 LG-F410S 의 Tapatalk에서 보냄 Ok, I will write 1.4 for testing, give me 10 minutes syscl Link to comment Share on other sites More sharing options...
cnrd Posted January 4, 2017 Share Posted January 4, 2017 @cnrd, Do you remove any other script that will load the msdosfs.kext? To make sure nvram.plist being refreshed, could you please test the following as well? sudo kextunload msdosfs Then reboot? If this work, our script will be pretty nice to ensure nvram.plist will be dumped to EFI always What I tried with logoutHook: - call diskutil, call ls none of them work - Then, I kextunload msdosfs.kext and logoutHook 80.save_nvram_plist.local, after reboot there's no even a single file being created... Last login: Wed Jan 4 12:38:26 on console syscls-MacBook:~ syscl$ sudo cat /Library/Logs/CloverEFI/rc.shutdown.log Password: ------------------------------- DATE: 2017-01-04 TIME: 12:37:16 ------------------------------- syscls-MacBook:~ syscl$ There must be some restriction during the logoutHook stage to mute all information to log to file. But the funny thing is my script seem to work by using the LogoutHook as well... Here's what I do: - Removed /etc/rc.boot.d/20.mount.ESP.local - Rename /etc/rc.shutdown.d/80.save_nvram_plist.local to /etc/rc.shutdown.d/80.save_nvram_plist.local.syscl - Remove rc.shutdown.log - Reboot - msdosfs.kext is not loaded by kextstat |grep msdos - logoutHook /etc/rc.shutdown.d/80.save_nvram_plist.local.syscl - check msdosfs is not loaded again - change brightness to minimal - reboot - Minimal brightness, nvram.plist created successfully in EFI/, no nvram.plist in / - change brightness to maximum - Remove rc.shudown.log - Reboot - Maximum brightness, nvram in EFI/ being refreshed, no nvram.plist in / A short conclusion by using logoutHook: - we no more need to use touched 20.mount.ESP.local to force load msdosfs.kext - if this method is proved to be stable, then we won't see nvram.plist in root anymore - drawback of this way, we can't see any log, it's hard to solve problem if there has - logoutHook method credit @cnrd and @RehabMan - For detail information credit @Sherlock, very thanks for the test log - Prevent write to EFI without Clover credit @tluck Thank you, syscl I'm not sure that we should keep the 80.save_nvram_plist.local file in rc.shutdown.d folder, as I think that folder should be reserved for scripts that are run at that time, not for a logoutHook, but I'm not really sure where we should place it then? (I'm sorry, not a reply for you directly, but more for the Clover maintainers). Not sure if there is actually a folder we could use, but I'm thinking: "/etc/logoutHook"? Link to comment Share on other sites More sharing options...
tluck Posted January 4, 2017 Share Posted January 4, 2017 frankly, this logoutHook approach is not all that new. I (and others IIRC) used it about 1.5 years when El Cap came out - the CloverDaemon and /etc/rc.shutdown scripts where failing. a modified CloverDaemon script was run as a logoutHook. the /etc/rc.shutdown scripts can stay where they are. anyway it was stored in /Library/Application Support/Clover - called CloverDaemon.hook Link to comment Share on other sites More sharing options...
Recommended Posts