Jump to content

Clover Problems and Solutions


ErmaC
3,206 posts in this topic

Recommended Posts

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

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

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

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

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

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

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

  • Like 2
Link to comment
Share on other sites

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에서 보냄

  • Like 1
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

  • Like 5
Link to comment
Share on other sites

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 

attachicon.gifsyscl_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

 

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

@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

  • Like 2
Link to comment
Share on other sites

@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

  • Like 2
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

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

@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

  • Like 2
Link to comment
Share on other sites

@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

attachicon.gifsyscl_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.

  • Like 1
Link to comment
Share on other sites

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

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

×
×
  • Create New...