Clover General discussion

[joe75]

Clover kext patching is being applied to kernel/kext cache and should be shown in bdmesg. 

 

As far as I know there is nothing to log between clovers end and the start of boot.efi 

[mhaeuser]

@joevt, idk if Clover supports that OOTB, but EDK2 supports serial output (DebugLib). Just change The DBG macros in the code if there isnt a serial one already.

I also have no clue why patching doesnt happen before, while the BS are still up.

 

@joe75 Clover does stuff during boot.efi execution

[tluck]

@Slice

 

http://www.insanelymac.com/forum/index.php?/topic/284656-Clover-General-discussion&do=findComment&comment=2379057

 

This rc script is no problem about known failure case and other issue(entire code is same before, tluck have optimized in latest code).

 

I tested to find failure case and not work properly many times since find failure case.

 

No more see failure case now.

 

Hope update rc script in clover.

 

Thanks @tluck @syscl @testers

 

Thanks in advance.

 

 

나의 LG-F410S 의 Tapatalk에서 보냄

 

Note:

the "LogoutHook method" needs more than just the rc.shutdown/80.save_nvram_plist.local updated in the Clover repo. 

CloverDaemon was split into 2 scripts and then the "Shutdown" part is the LogoutHook script.

I suspect this could be easily implemented in the Clover installer with Emuvariable or  new Rc script option

[bronxteck]

on this forum clover files are located @ https://sourceforge.net/projects/cloverefiboot/files/ Try It.

[greatcornholio]

Hi Guys!

 

First, the usual, thanks for all the great work. This project is pure goodness.

 

On to it: Wondering why we still proceed with a shutdown hook to capture and save nvram key-values to a file... especially since when we run an installer image, those hooks aren't present and thus the nvram modifications are lost.

 

My goal was to create a boot usb key which would not contain any OSes but simply contain clover and all that is needed to run a vanilla mac os install on a legacy BIOS board. Saving the nvram variables is pretty much what's left standing in the way of having this key complete.

 

I have changed the save_nvram_plist script to find the actual ESP where clover booted from (through ioreg analysis). It is attached to this post. It is a fork of the script from v2.3k_r3974. See attached.

 

Now it works well in that it doesn't care about the current OS disk running, but rather assumes that the clover EFI partition is the best spot. It allows me to have one single clover boot partition, from which I can boot any of my installs, test installs, clone backups, etc.

 

BUT, it nvram changes made into installer boots are still lost.

 

SO, is it not possible to have a fake UEFI handler/driver (I'm new at this) which would actually catch the expected firmware or SMC "functions" and save the nvram data to a file, or a fixed sector of a block device (USB or whatever). I know the legacy BIOS RTC memory won't fit the nvram data, but we should be able to spare a few sectors and do very raw, BIOS like, write operations no?

 

I am a professional linux embedded developer but have never actually developed on my macs. I started casually browsing clover source code but would need pointers to get started, if it's at all possible.

 

Really looking forward to contributing!

80.save_nvram_plist.local.zip

[mathew2005in]

Hi Guys,

 

I am having little problem here. i have installed Sierra on XEON E2683 V3 14Core machine successfully and is working fine except two issues. sleep won't working and about mac shows" 2.0Ghz unknown " I haven't added any fake id or enabled kernel patching, actually it is not necessary I believe. I have tried several values in clover "CPU type"  but none of them are working..still shows Unknow Cpu. but my XEON E5 12core CPU shows correctly in about mac section. 

Is anybody knows what may be the issue??

 

Thank you,

[apianti]

Yes. There were 2 problems with edk2 commit dc4c77

• Get error "global macro arch is not permitted' in refit.inf.  This is result of change in MetaFileParser.py.  Can fix this by either using reversion checked in by Slice, or as Fritz suggested - edit refit.inf and change CLOVER$(ARCH) to just CLOVER.
• The change in WorkspaceDatabase.py caused unfixable breakdown - a regression in edk2 build process.  It was fixed by edk2 commit 1d8ceb.  So after 1d8ceb, it is possible to use WorkspaceDatabase.py from edk2 tree or the reversion checked in by Slice.

Hope this clarifies.

 

This is my fault, I was trying to get them to fix this problem with macro expansion and instead just emits an error now...

[tluck]

@greatcornholio

 

"nvram save" has been a topic of discussion debate and progress over the last month or so. btw, Clover 3974 is a bit old by the way!

there is a new proposed script and method recently posted above (v.1.16.1) . but this new model is not yet incorporated into the Clover tree (or package installer).

 

Note:

1) saves NVRAM to ESP vs /

2) uses LogoutHook vs shutdown

3) needs some tools/scripts in /etc (rc.clover.lib, rc.shutdown.d) etc)

 

So either way to your point, the old (your script) or new method does not handle the OS installer scenario very well. 

So yes, If there is extra stuff on the Installer - and if that somehow gets run, then the USB could provide the nvram.plist file on next boot presuming that is boot disk. 

perhaps you can expand on your idea to maintain variables from the install session ( are these really needed?)

[Sherlocks]

@greatcornholio

 

"nvram save" has been a topic of discussion debate and progress over the last month or so. btw, Clover 3974 is a bit old by the way!

there is a new proposed script and method recently posted above (v.1.16.1) . but this new model is not yet incorporated into the Clover tree (or package installer).

 

Note:

1) saves NVRAM to ESP vs /

2) uses LogoutHook vs shutdown

3) needs some tools/scripts in /etc (rc.clover.lib, rc.shutdown.d) etc)

 

So either way to your point, the old (your script) or new method does not handle the OS installer scenario very well. 

So yes, If there is extra stuff on the Installer - and if that somehow gets run, then the USB could provide the nvram.plist file on next boot presuming that is boot disk. 

perhaps you can expand on your idea to maintain variables from the install session ( are these really needed?)

 

we have to add "CloverDaemon-stopservice" file?

 

 

 

trap StopService SIGTERM # SIGTERM @ shutdown

while true; do

    sleep 86400 &  # Start the sleep process in background

    wait $!        # and wait to finish

done

 

above code, you did disabled to prevent failure case when shutdown in CloverDaemon. Is not that enough?

 

actually CloverDaemon-stopservice file work? "CloverDaemon" file run with com.projectosx.clover.daemon.plist.

 

but i can't see something to run CloverDaemon-stopservice.

 

why you add CloverDaemon-stopservice this file?

 

add. if there is no CloverDaemon-stopservice file, nvram can't gernerate when shutdown or restart. need CloverDaemon-stopservice file.

 

anyways 1.16.1 is working without problem for 1 weeks. i checked log and location everyday

[tluck]

@sherlocks 

 

if you installed nvram save script v1.16.1 by the installation script included the zip, then i believe you are launching the /etc/rc.shutdown.d/80*local script by LogoutHook - but not directly.

 

The LogoutHook script is /Library/A S/Clover/CloverDaemon-stopservice

- which runs then "shutdown scripts" in /etc/rc.shutdown.d

 

i will try to explain rationale again: 

 

I split the original CloverDaemon into 2 parts

- to avoid trying to running the "shutdown scripts" during shutdown which is not reliable.

- Changing the method to run these scripts by LogoutHook is reliable.

 

CloverDaemon

- runs all startup scripts /etc/rc.boot.d/

- run by launchd, set by /Library/LaunchDaemons/com.projectosx.clover.daemon.plist

 

CloverDaemon-stopservices 

- runs all shutdown scripts in /etc/rc.shutdown.d

- run by LogoutHook, set by installation script

[Sherlocks]

@sherlocks

 

if you installed nvram save script v1.16.1 by the installation script included the zip, then i believe you are launching the /etc/rc.shutdown.d/80*local script by LogoutHook - but not directly.

 

The LogoutHook script is /Library/A S/Clover/CloverDaemon-stopservice

- which runs then "shutdown scripts" in /etc/rc.shutdown.d

 

i will try to explain rationale again:

 

I split the original CloverDaemon into 2 parts

- to avoid trying to running the "shutdown scripts" during shutdown which is not reliable.

- Changing the method to run these scripts by LogoutHook is reliable.

 

CloverDaemon

- runs all startup scripts /etc/rc.boot.d/

- run by launchd, set by /Library/LaunchDaemons/com.projectosx.clover.daemon.plist

 

CloverDaemon-stopservices

- runs all shutdown scripts in /etc/rc.shutdown.d

- run by LogoutHook, set by installation script

Thank you. I understand it now.

 

 

나의 LG-F410S 의 Tapatalk에서 보냄

[tluck]

@Sherlocks

 

- on the Pkg for nvram save

- i think you need to add a post install command to define LogoutHook.

[Sherlocks]

@Sherlocks

 

- on the Pkg for nvram save

- i think you need to add a post install command to define LogoutHook.

 

can i use uncomment this line in 20.mount_ESP.local? only have to add in postinstall?

you did comment this line blow

 

 

#gLogoutHookLog="${CLOVER_LOG_LOCATION}/rc.syscl.addlogoutHook.log"

#gLogoutHookf="/etc/rc.shutdown.d/80.save_nvram_plist.local"

#if [ -f "${gLogoutHookf}" ]; then

#    #

#    # file exist, need to logoutHook

#    #

#    echo "v${gScriptVersion} © 2017 syscl/lighting/Yating Zhou" >${gLogoutHookLog}

#    echo "Found ${gLogoutHookf}, register logoutHook"            >>${gLogoutHookLog}

#    defaults write com.apple.loginwindow LogoutHook ${gLogoutHookf}

#fi

 

[tluck]

can i use uncomment this line in 20.mount_ESP.local? only have to add in postinstall?

you did comment this line blow

 

well one can either define the LogoutHook by the Clover pkg installer - or some other way

If you use this start up script it will need some better logic

1) this does not need happen everytime it is run. 

2) the LogoutHook script should be general - so i chose to use /Library/A S/Clover/CloverDaemon-stopservice - since it can run multiple scripts as needed.

[Sherlocks]

well one can either define the LogoutHook by the Clover pkg installer - or some other way

If you use this start up script it will need some better logic

1) this does not need happen everytime it is run. 

2) the LogoutHook script should be general - so i chose to use /Library/A S/Clover/CloverDaemon-stopservice - since it can run multiple scripts as needed.

 

1) this does not need happen everytime it is run. 

is it important? i want to know

 

2) how about this one?

 

gLogoutHookf="/Library/Application Support/Clover/CloverDaemon-stopservice"

if [ -f "${gLogoutHookf}" ]; then

    #

    # file exist, need to logoutHook

    #

    echo "v${gScriptVersion} © 2017 syscl/lighting/Yating Zhou" >${gLogoutHookLog}

    echo "Found ${gLogoutHookf}, register logoutHook"            >>${gLogoutHookLog}

    defaults write com.apple.loginwindow LogoutHook ${gLogoutHookf}

fi

 

 

add. it works

 

Supreme-MBP:~ supreme$ sudo cat /Library/Logs/CloverEFI/rc.shutdown.log

Password:

-------------------------------

DATE: 2017-03-11 TIME: 05:38:30

-------------------------------

>> Begin Script: /etc/rc.shutdown.d/80.save_nvram_plist.local

v1.16.1 © 2017 syscl/lighting/Yating Zhou/tluck/Sherlocks

2017-03-11-05:38:30  disk0: ESP -- Target  -- /Volumes/ESP-01/EFI/CLOVER

2017-03-11-05:38:30  NVRAM: No change since last update in /Volumes/ESP-01/nvram.plist

>> End Script: /etc/rc.shutdown.d/80.save_nvram_plist.local

 

Supreme-MBP:~ supreme$ 

 

and

 

v1.16.1 © 2017 syscl/lighting/Yating Zhou

Found /Library/Application Support/Clover/CloverDaemon-stopservice, register logoutHook

 

[tluck]

@sherlocks - 

 

try this version for 20.mount_ESP.local

 

added some logic to make sure should even add the LogoutHook etc.

 

 

20.mount_ESP.local.zip

[Sherlocks]

@sherlocks - 

 

try this version for 20.mount_ESP.local

 

added some logic to make sure should even add the LogoutHook etc.

 

okay. i see good code. 

 

normal process

boot, clover-daemon load, when restart or shutdown, disable clover-daemon(by CloverDaemon-stopservice). it's no problem.

 

i want to know one case whether problem or not

case is 

if logout and login again or wakeup. clover-daemon never work again? no need sudo defaults write com.apple.loginwindow LoginHook?

like "defaults write com.apple.loginwindow LoginHook /Library/Application Support/Clover/CloverDaemon"

 

add. New ESP script no problem

>> Begin Script: /private/etc/rc.boot.d/10.save_and_rotate_boot_log.local
Clover boot messages saved in /Library/Logs/CloverEFI/boot.log
>> End Script: /private/etc/rc.boot.d/10.save_and_rotate_boot_log.local

>> Begin Script: /private/etc/rc.boot.d/20.mount_ESP.local
Not auto mounting EFI partition
v1.16.1 (c) 2017 syscl/lighting/Yating Zhou/tluck
Registering LogoutHook as /Library/Application Support/Clover/CloverDaemon-stopservice
>> End Script: /private/etc/rc.boot.d/20.mount_ESP.local

@Slice

i made new v3 pkg file. completed all

1.16.1 update pkg v3.zip

[greatcornholio]

Thanks for your answer.

 

"nvram save" has been a topic of discussion debate and progress over the last month or so. btw, Clover 3974 is a bit old by the way!

I know, this is why I was mentioning it.

 

So either way to your point, the old (your script) or new method does not handle the OS installer scenario very well. 

So yes, If there is extra stuff on the Installer - and if that somehow gets run, then the USB could provide the nvram.plist file on next boot presuming that is boot disk. 

perhaps you can expand on your idea to maintain variables from the install session ( are these really needed?)

I know if I start the installer from my actual OS partition (which is setup to save nvram plist) some values are set to assist the reboot which completes the install. I assume the installer removes those. When emerging from the update in the real OS disk, these new key-values are still present. These are "install-product-url" and "rc_imgsrc_info". I had to manually remove them. Weather these are crucial or not I don't know.

 

Again, with the goal to keep the OS disk perfectly vanilla (rescue, install or real disk), since clover does kext injection, it would assume a kext could be written. This kext would grab all variables when asked to unload at shutdown and dump them in binary form to a storage device (maybe straight to device in a reserved area).

 

In fact, why is that not in FakeSMC.kext? Isn't the SMC responsible for saving nvram on real macs?

 

I'll keep digging.

[tluck]

@sherlocks

 

there is no need to rerun the startup script after a logout.

the LogoutHook definition persists until is deleted by a similar command

[cecekpawon]

Is CIA malware based on dmazar/modbin code or something?

[smolderas]

Is CIA malware based on dmazar/modbin code or something?

 

[PMheart]

Hi. I think there's a typo in kext_inject.c:

UINT8   KBESieDebugSearchEXT[]   = { 0xE8, 0x47, 0x00, 0x00, 0x00, 0xE9, 0x09, 0x00, 0x00, 0x00, 0x48, 0x8B, 0x7D, 0xE8, 0xE8, 0xD9 };
UINT8   KBESieDebugReplaceEXT[]  = { 0xE8, 0x47, 0x00, 0x00, 0x00, 0x90, 0x90, 0x00, 0x00, 0x00, 0x48, 0x8B, 0x7D, 0xE8, 0xE8, 0xD9 };

Note that now we don't NOP out the jmpq fully. (E9 09 00 00 00 -> 90 90 00 00 00 , should be 5x NOP actually.)

 

And fixed here... (Also with a minor variable renaming, don't care about that. )

 

new_kext_inject.c.zip

[smolderas]

You all are going to think I'm nuts, but it would be wonderful if when the system boots to the Clover main load screen (the one that lists your drives and systems with icons), it would be great if there was a way to have some kind of screen saver turn on after some minutes.

 

I don't suppose there's any way to do that, but it would be a nice to have feature!

Just out of curiosity, why in the world would one need such a "nice to have feature", if you don't mind me asking?

[smolderas]

Prevent monitor burnout, just in case you forget, and don't auto-load the OS, or prefer not to auto-load the OS.   If you load Windows and Mac and even a Linux distro (like we do at work) that screen is a nice stopping point, but if you forget, and leave the computer on that screen, you'll suffer screen burn-out.  A simple screen-off (or have the screen just go black) would be plenty.   Some systems we use we prefer to leave on to save time loading the system.

On what kind of system are you using Clover and forget such long time to burnout a monitor?

 

Edit: More elegant solution would be, as original macOS boot loader does (at least when FileVault 2 is active) shutdown the computer after x second timeout.

[droples]

Error of new compilation of clover4034 and above.

 

Clover 4033 is compiled successfully. And if after that I update the clover, 

then everything also ends successfully. But there is a problem when 

I perform a new compilation (not an update) of the clover 4034 and above.

 

iMac-Droplets-2:Clover droplets$ svn up -r 4034
Updating '.':
U    Clover.dsc
U    Patches_for_EDK2/Conf/tools_def.txt
U    buildExtras.sh
U    build_gcc6.sh
U    buildnasm.sh
U    ebuild.sh
Updated to revision 4034.

 

 

Generating BootSectors
[NASM] boot0af.s -> /Users/droplets/src/edk2/Clover/CloverPackage/CloverV2/BootSectors/boot0af
[NASM] boot0ss.s -> /Users/droplets/src/edk2/Clover/CloverPackage/CloverV2/BootSectors/boot0ss
[NASM] boot0md.s -> /Users/droplets/src/edk2/Clover/CloverPackage/CloverV2/BootSectors/boot0md
[NASM] boot1h.s -> /Users/droplets/src/edk2/Clover/CloverPackage/CloverV2/BootSectors/boot1h
[NASM] boot1h2.s -> /Users/droplets/src/edk2/Clover/CloverPackage/CloverV2/BootSectors/boot1h2
[NASM] boot1f32.s -> /Users/droplets/src/edk2/Clover/CloverPackage/CloverV2/BootSectors/boot1f32
[NASM] boot1f32alt.s -> /Users/droplets/src/edk2/Clover/CloverPackage/CloverV2/BootSectors/boot1f32alt
[NASM] boot1x.s -> /Users/droplets/src/edk2/Clover/CloverPackage/CloverV2/BootSectors/boot1x
boot1x.s:188: error: short jump is out of range
boot1x.s:193: error: short jump is out of range
boot1x.s:204: error: short jump is out of range
boot1x.s:233: error: short jump is out of range
make: *** [/Users/droplets/src/edk2/Clover/CloverPackage/CloverV2/BootSectors/boot1x] Error 1

 

 

But if I do not update ebuild.sh then the compilation is successful.