Jump to content

Clover General discussion


ErmaC
29,866 posts in this topic

Recommended Posts

Hello Slice,

 

here is updated shutdown script. There were some issues in previous script, that it saved to root of boot Volume and exited. But it can't be read on file vault 2. With this version it only saves the content of NVRAM to the EFI partition of the boot volume.

 

Second thing is: I'm not sure, that those rc.shutdown scripts get called. I had to set a LogoutHook for it to get it run:

sudo defaults write com.apple.loginwindow LogoutHook /etc/rc.shutdown.d/80.save_nvram_plist.local

Cheers

Link to comment
Share on other sites

Hello Slice,

 

here is updated shutdown script. There were some issues in previous script, that it saved to root of boot Volume and exited. But it can't be read on file vault 2. With this version it only saves the content of NVRAM to the EFI partition of the boot volume.

 

Second thing is: I'm not sure, that those rc.shutdown scripts get called. I had to set a LogoutHook for it to get it run:

sudo defaults write com.apple.loginwindow LogoutHook /etc/rc.shutdown.d/80.save_nvram_plist.local

Cheers

Thanks,

committed to 3961.

  • Like 1
Link to comment
Share on other sites

Hi.

In kext_inject.c we may try removing some byte values between KBEYosSearchEXT & KBESieSearchEXT?

And this makes KBEYosSearchEXT & KBESieSearchEXT the same and thus we just keep one of them?

 

// Yosemite

UINT8   KBEYosSearchEXT[]        = { 0xE8, 0x25, 0x00, 0x00, 0x00, 0xEB, 0x05, 0xE8, 0xCE, 0x02, 0x00, 0x00 };  // Remove '0xE80xCE0x020x000x00'

 

UINT8   KBEYosReplaceEXT[]       = { 0xE8, 0x25, 0x00, 0x00, 0x00, 0x90, 0x90, 0xE8, 0xCE, 0x02, 0x00, 0x00 };

 

// Sierra

// Sherlocks: Sierra SIP, cecekpawon: Sierra DP2+

// need to use KBEYos*EXT patch for Sierra DP1

// need to use KBESie*EXT patch for Sierra DP2+

UINT8   KBESieSearchEXT[]        = { 0xE8, 0x25, 0x00, 0x00, 0x00, 0xEB, 0x05, 0xE8, 0x7E, 0x05, 0x00, 0x00 }; // Remove '0xE80x7E0x050x000x00'

UINT8   KBESieReplaceEXT[]       = { 0xE8, 0x25, 0x00, 0x00, 0x00, 0x90, 0x90, 0xE8, 0x7E, 0x05, 0x00, 0x00 };

 

 

Confirmed. Just patch them 1 time after deleting the redundant byte values. Not caused confusions. So I think we can just keep one of them for convenience?

But... Not tested for Yos and EC. Just tested on 10.12.1 (16B2657) and 10.12.2 (16C63a)...

 

 

Link to comment
Share on other sites

Hi.

In kext_inject.c we may try removing some byte values between KBEYosSearchEXT & KBESieSearchEXT?

And this makes KBEYosSearchEXT & KBESieSearchEXT the same and thus we just keep one of them?

 

// Yosemite

UINT8 KBEYosSearchEXT[] = { 0xE8, 0x25, 0x00, 0x00, 0x00, 0xEB, 0x05, 0xE8, 0xCE, 0x02, 0x00, 0x00 }; // Remove ', 0xE8, 0xCE, 0x02, 0x00, 0x00'

 

UINT8 KBEYosReplaceEXT[] = { 0xE8, 0x25, 0x00, 0x00, 0x00, 0x90, 0x90, 0xE8, 0xCE, 0x02, 0x00, 0x00 };

 

// Sierra

// Sherlocks: Sierra SIP, cecekpawon: Sierra DP2+

// need to use KBEYos*EXT patch for Sierra DP1

// need to use KBESie*EXT patch for Sierra DP2+

UINT8 KBESieSearchEXT[] = { 0xE8, 0x25, 0x00, 0x00, 0x00, 0xEB, 0x05, 0xE8, 0x7E, 0x05, 0x00, 0x00 }; // Remove ', 0xE8, 0x7E, 0x05, 0x00, 0x00'

UINT8 KBESieReplaceEXT[] = { 0xE8, 0x25, 0x00, 0x00, 0x00, 0x90, 0x90, 0xE8, 0x7E, 0x05, 0x00, 0x00 };

 

 

Confirmed. Just patch them 1 time after deleting the redundant byte values. Not caused confusions. So I think we can just keep one of them for convenience?

But... Not tested for Yos and EC. Just tested on 10.12.1 (16B2657) and 10.12.2 (16C63a)...

 

attachicon.gifnew_kext_inject.c.zip

Did you check all kernel binary value?

 

I checked all. If reduce binary value, Mavericks kernel patched two times. Its not correct. I think we remain enough binary value.

 

reduce binary value cause to patch other parts.

 

 

나의 LG-F410S 의 Tapatalk에서 보냄

Link to comment
Share on other sites

Yeah. Not affect. I dont know why you reduce binary patch length? What is difference?

 

My think is patch remains enough length to avoid patch other parts.

 

나의 LG-F410S 의 Tapatalk에서 보냄

After reducing byte values for KBEYos* and KBESie* will keep them the same. So will be universal for all Yos, EC and Sie.

Yes. But sometimes use too long length is not good as well.

Link to comment
Share on other sites

After reducing byte values for KBEYos* and KBESie* will keep them the same. So will be universal for all Yos, EC and Sie.

Yes. But sometimes use too long length is not good as well.

Not good as well? I dont agree that.

I think we find difference for update. Yeah universal patch is good. But some patches need more length to avoid 2 times or over patch.

 

Just my mind and your mind are difference.

 

Anyway its depend on Slice's mind.

 

Thank you

 

나의 LG-F410S 의 Tapatalk에서 보냄

  • Like 1
Link to comment
Share on other sites

I have a problem with SetIntelBacklight:

 

Brightness control slider, and Function Keys do NOT work. The brightness indicator shows up but brightness stays the same. Brightness values in nvram DO change and apply correctly on boot.

 

Not sure if this is actually fixable but thought I'd report it  :)

Link to comment
Share on other sites

Hello Slice,

 

here is updated shutdown script. There were some issues in previous script, that it saved to root of boot Volume and exited. But it can't be read on file vault 2. With this version it only saves the content of NVRAM to the EFI partition of the boot volume.

 

Second thing is: I'm not sure, that those rc.shutdown scripts get called. I had to set a LogoutHook for it to get it run:

sudo defaults write com.apple.loginwindow LogoutHook /etc/rc.shutdown.d/80.save_nvram_plist.local

Cheers

Users claim that the new script is not working.

  • Like 1
Link to comment
Share on other sites

It doesn't work on my hp which has BIOS+GPT+UEFI.

Could you please post the result of the following:

diskutil list

It seems that not all Clover users own EFI System Partition. And thus for those the new script for storing NVRAM may not work. They install their Clover and even everything on the same partition as the system partition... Not ESP.

 

 

An ESP has no relation to NVRAM. When NVRAM is not usable there is the option to use an nvram.plist

 

I don't see any issue for having an EFI partition. I even think if you ever try to repair your disk in macOS, it will ensure that an EFI partition exists.

 

Whatever the case maybe for not having an EFI partition, I'll post soon a newer version of the script with a fallback to the root partition, if there is no EFI partition. With that it should work for everybody (I think).

 

Sorry for any inconvenience.

 

Edit: Here is the script with the fallback to the root partition. For everyone else just copy it to its location and change its executable bit:

sudo cp ~/Downloads/80.save_nvram_plist.local.txt /etc/rc.shutdown.d/80.save_nvram_plist.local
sudo chmod 755 /etc/rc.shutdown.d/80.save_nvram_plist.local
  • Like 1
Link to comment
Share on other sites

 

Could you please test the new script manually* and post its result?

 

*

sudo cp ~/Downloads/80.save_nvram_plist.local.txt /etc/rc.shutdown.d/80.save_nvram_plist.local
sudo chmod 755 /etc/rc.shutdown.d/80.save_nvram_plist.local
sudo /etc/rc.shutdown.d/80.save_nvram_plist.local

 

 

new script here

Last login: Thu Dec 15 00:41:29 on ttys000

Supreme-MBP:~ supreme$ sudo cp ~/Downloads/80.save_nvram_plist.local /etc/rc.shutdown.d/80.save_nvram_plist.local

Password:

Supreme-MBP:~ supreme$ sudo chmod 755 /etc/rc.shutdown.d/80.save_nvram_plist.local

Supreme-MBP:~ supreme$ sudo /etc/rc.shutdown.d/80.save_nvram_plist.local

NVRAM saved to '/nvram.plist' [disk0s4]

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$ 

 

 

script not work for me in r3961

Link to comment
Share on other sites

new script here

Last login: Thu Dec 15 00:41:29 on ttys000

Supreme-MBP:~ supreme$ sudo cp ~/Downloads/80.save_nvram_plist.local /etc/rc.shutdown.d/80.save_nvram_plist.local

Password:

Supreme-MBP:~ supreme$ sudo chmod 755 /etc/rc.shutdown.d/80.save_nvram_plist.local

Supreme-MBP:~ supreme$ sudo /etc/rc.shutdown.d/80.save_nvram_plist.local

NVRAM saved to '/nvram.plist' [disk0s4]

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$ 

 

 

script not work for me in r3961

It seems the new one works for you. It saved to your root partition.

Link to comment
Share on other sites

It seems the new one works for you. It saved to your root partition.

 

but not save brightness value. if decrease brightness before reboot, next boot save decrease brightness in normal case. 

 

lastest script not work this behavior. is it relate?

It seems the new one works for you. It saved to your root partition.

 

 

okay. im sure that nvram is not save properly.

 

clover r3960 is good i said behavior. i tested it.

 

but your new script is not work.

Link to comment
Share on other sites

but not save brightness value. if decrease brightness before reboot, next boot save decrease brightness in normal case. 

 

lastest script not work this behavior. is it relate?

Look with `bdmesg |grep nvram` where clover loaded your nvram.plist from. And check if it is the newest one.

 

Here is a new test case:

 

Type following:

sudo nvram myvar="this is a new variable"

and reboot after that.

After reboot check your NVRAM content if this new variable exists:

nvram -p|grep myvar
Link to comment
Share on other sites

@Sherlocks

It also needs com.projectosx.clover.daemon.plist in /Library/Application Support/LaunchDaemons (which must be activated with launchctl), aswell as /etc/rc.clover.lib ! Although I didn't test the newest version...

And /Library/Application Support/Clover/CloverDaemon is needed.

Link to comment
Share on other sites

×
×
  • Create New...