Clover.app testing

vector sigma · November 19, 2019

Clover.app v1.07 Beta available at first post.

The CloverDaemonNew is not compatible with old rc scripts and for this reason, since v1.07, Clover.app remove them. For the same reason the package remove CloverDaemonNew if you install back the rc scripts (since commit d447228 of november 29 2019);

Big thanks to @Sherlocks for helping me to make it work.

Also I fixed, again (due to a missing "), and improved the installation of legacy Clover, tested on hfs, exfat and fat32. Working on all.

Edited November 19, 2019 by vector sigma

Rodion2010 · November 20, 2019

v1.07 beta

Legacy Boot installation works OK

Installation begin..
My Path = /private/var/folders/24/h4z_tgkx5_jgnd35s4yslm3m0000gn/T/AppTranslocation/D1F44A6D-EBA8-497B-9D1A-0D760A8F7970/d/Clover.app/Contents/MacOS/Cloverhelper
bootSectorsInstallSrc = /private/var/folders/24/h4z_tgkx5_jgnd35s4yslm3m0000gn/T/AppTranslocation/D1F44A6D-EBA8-497B-9D1A-0D760A8F7970/d/Clover.app/Contents/SharedSupport/bootsectors-install
Target volume: /Volumes/EFI
boot0: boot0af
boot1: boot1f32
boot2: boot6

Installing/Updating Clover:
+ ../BOOT/BOOTX64.efi
+ ../CLOVER/CLOVERX64.efi

Installing/Updating drivers:
+ ../BIOS/FSInject.efi
+ ../BIOS/SMCHelper.efi

Installing/Updating tools:
+ ../tools/bdmesg.efi
+ ../tools/Shell32.efi
+ ../tools/Shell64.efi
+ ../tools/Shell64U.efi

Installing/Updating doc:
+ ../doc/bcfg.txt
+ ../doc/boot1f32-install.sh
+ ../doc/HowToFixDsdt.txt
+ ../doc/HowToInstallOSX.txt
+ ../doc/UEFI boot with Clover.rtf

Installing stage 2..
+ ../EFI/boot

Installing boot sectors (version of Sun 17 2019, 12:14)

disk:       disk2s1
bootdev:    /dev/disk2s1
bootrdev:   /dev/rdisk2s1
bootdisk:   /dev/disk2
bootrdisk:  /dev/rdisk2
bootslice:  1
filesystem: fat32
partition_scheme: GUID_partition_scheme


/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *256.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            255.2 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *3.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS Macintosh HD2           2.5 TB     disk1s2
   3:                  Apple_HFS macOS                   250.0 GB   disk1s3
   4:                 Apple_Boot Recovery HD             650.0 MB   disk1s4
   5:                  Apple_HFS Untitled                50.6 GB    disk1s5
   6:       Microsoft Basic Data NTFS                    101.0 GB   disk1s6
   7:       Microsoft Basic Data BOOTCAMP                97.1 GB    disk1s7
   8:           Windows Recovery                         601.9 MB   disk1s8

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *16.4 GB    disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:                  Apple_HFS Test                    16.0 GB    disk2s2


Volume EFI on disk2s1 unmounted

Stage 0 - Writing /tmp/boot0af to /dev/rdisk2
Executing: dd if=/dev/rdisk2 count=1 bs=512 of=/tmp/CloverOrigMBR
1+0 records in
1+0 records out
512 bytes transferred in 0.003000 secs (170665 bytes/sec)
Executing: cp /tmp/CloverOrigMBR /tmp/CloverNewMBR
Executing: dd if=/tmp/boot0af of=/tmp/CloverNewMBR bs=440 count=1 conv=notrunc
1+0 records in
1+0 records out
440 bytes transferred in 0.007691 secs (57209 bytes/sec)
Executing: fdisk -f /tmp/CloverNewMBR -u -y /dev/rdisk2

Stage 1 - Writing /tmp/boot1f32 to /dev/rdisk2s1
Executing: boot1-install -y -f /tmp/boot1f32 /dev/rdisk2s1
Volume EFI on /dev/disk2s1 mounted

Installation succeded.

Do we still need NewMBR?

I think it is for very old Windows compatibility (?)

I use

sudo fdisk -f boot0af  -u /dev/rdisk2

and it works with no difference

Rodion2010 · November 20, 2019

simple replacement for logout script

works for me

latest=/nvram.plist
for file in /Volumes/*/nvram.plist; do
[[ $file -nt $latest ]] && latest=$file
done

nvram -xp > "$latest"
chflags hidden "$latest"

and

mount the partition Clover was started from

sudo diskutil mount $(ioreg -lw0 -p IODeviceTree | grep boot-log | sed -e 's/.*<//' -e 's/>//' | xxd -r -p | grep SelfDevicePath | awk -F'GPT,' '{print $2}' | cut -d, -f1)

maybe, someone will find it usefull

Sherlocks · November 20, 2019

15 hours ago, vector sigma said:

Clover.app v1.07 Beta available at first post.

The CloverDaemonNew is not compatible with old rc scripts and for this reason, since v1.07, Clover.app remove them. For the same reason the package remove CloverDaemonNew if you install back the rc scripts (since commit d447228 of november 29 2019);

Big thanks to @Sherlocks for helping me to make it work.

Also I fixed, again (due to a missing "), and improved the installation of legacy Clover, tested on hfs, exfat and fat32. Working on all.

report bug

1. although to check install cloverdaemon, clover app recognize that no installed cloverdaemon. this issue first happen in this version

previous version that there is no problem.

403543121_2019-11-2010_37_52.png.3b30d05ee5ab3dec27052af5dabc326e.png

2. after checked DisableSleepProxyClient in clover app, and clover app makes Clover.DisableSleepProxyClient true in nvram.

then reboot and i checked

it is fine, but,

i uncheck DisableSleepProxyClient in clover app, and nvram -p, i checked DisableSleepProxyClient key was removed.

and fixed clover app recognized unchecked DisableSleepProxyClient option. it correctly means that read nvram value by clover app.

then reboot,

and checked com.apple.mDNSResponder.plist file

but still there is -DisableSleepProxyClient in ProgramArguments. i have to remove -DisableSleepProxyClient manually

3. about remove nvram.plist

sherlocks test 1.0.7 version, logout script removed nvram.plist on hfs+ partition(this is case that i copied nvram.plist and pasted it in mac data of hfs+ partition for test) when logout.

but 1.0.7 beta version now can't remove nvram.plist.

sherlocks@SherloccBookPro ~ % diskutil list

/dev/disk0 (internal, physical):

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *500.1 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_APFS Container disk1 200.0 GB disk0s2

3: Microsoft Basic Data Windows 7 200.3 GB disk0s3

4: Apple_HFS Mac Data 39.5 GB disk0s4

5: Microsoft Basic Data Win Data 60.1 GB disk0s5

/dev/disk1 (synthesized):

#: TYPE NAME SIZE IDENTIFIER

0: APFS Container Scheme - +200.0 GB disk1

Physical Store disk0s2

1: APFS Volume Macintosh HD - 데이터 93.8 GB disk1s1

2: APFS Volume Preboot 82.6 MB disk1s2

3: APFS Volume Recovery 528.3 MB disk1s3

4: APFS Volume VM 1.1 GB disk1s4

5: APFS Volume Macintosh HD 10.9 GB disk1s5

sherlocks@SherloccBookPro ~ %

my laptop has only one SSD. and GPT format.

for legacy and emuvariablesuefi

if ESP

remove nvram.plist of other partition except ESP partition

else //MBR

check nvram.plist in root of macos(booted)

and remain it and remove nvram.plist of other partition.

thank you for update and hard work.

Edited November 20, 2019 by Sherlocks

vector sigma · November 20, 2019

14 hours ago, Rodion2010 said:
Do we still need NewMBR?

I think it is for very old Windows compatibility (?)

I use
sudo fdisk -f boot0af  -u /dev/rdisk2
and it works with no difference

Thanks for the report. Totally UEFI here, but so much users still boot with CSM enabled and Windows 7 is still in use by many peoples, so why I thought this is still needed. In short I don't want to cause boot failures (or malfunctions) to any one, and merge new 440 bytes + existing 72 cost nothing, also because last 72 bytes of boot0af or boot0ss are filled with zeroes and only the last two, the boot signature (0x55, 0xAA), is common for all bioses :

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000055AA

so doing this looks due.

13 hours ago, Rodion2010 said:

nvram -xp > "$latest"

I made my own API because I'm not sure the -x option exist in some old OSes. Plus I can easily add or remove keys if a need be in future.

13 hours ago, Rodion2010 said:
and

mount the partition Clover was started from
sudo diskutil mount $(ioreg -lw0 -p IODeviceTree | grep boot-log | sed -e 's/.*<//' -e 's/>//' | xxd -r -p | grep SelfDevicePath | awk -F'GPT,' '{print $2}' | cut -d, -f1) 
maybe, someone will find it usefull

Yes, I'm doing almost the same and it work also on non GPT partition sheme.

I'm happy it now works well, thanks again!

Edited November 20, 2019 by vector sigma
typos

vector sigma · November 20, 2019

On 11/20/2019 at 2:47 PM, Sherlocks said:

it is fine, but,

i uncheck DisableSleepProxyClient in clover app, and nvram -p, i checked DisableSleepProxyClient key was removed.

Because it was checking for "Clover.DisableSleepProxyClient" existence, and if true, services was disabled, while to re enable the service the same variable should have been existing but not "true". So the app was removing the key and the daemon was leaving all as is. Fixed.

On 11/20/2019 at 2:47 PM, Sherlocks said:

3. about remove nvram.plist

sherlocks test 1.0.7 version, logout script removed nvram.plist on hfs+ partition(this is case that i copied nvram.plist and pasted it in mac data of hfs+ partition for test) when logout.

but 1.0.7 beta version now can't remove nvram.plist.

Yes, is what I tried to say to you:

On 11/19/2019 at 2:54 PM, vector sigma said:

Please, we will check it later. We have to focus to nvram saving :-)

late, I removed all the code. Now we have to redone it??

but probably I did not understood if that was good or not :angel:

On 11/20/2019 at 2:47 PM, Sherlocks said:

for legacy and emuvariablesuefi

if ESP

remove nvram.plist of other partition except ESP partition

else //MBR

check nvram.plist in root of macos(booted)

and remain it and remove nvram.plist of other partition.

The problem is else where. You told me to not save again and again the nvram if no changes to the real nvram was made: well, that works! ...but now when you are going to sleep, your HibernationFixUp create a new /nvram.plist..... but the daemon knows the nvram file in the ESP is not changed :hysterical: .

I think I fixed it. To do that it now know if the nvram was saved to / or else were, and if the place is not /, it remove /nvram.plist, leaving the other one.

Try: removed

P.S. MBR or GPT makes no difference because:

Search for the boot partition and if it is an ESP the program use it to dump the nvram.
If the boot partition no longer exist (the case you boot from USB and then you remove the pen drive), it search again for another ESP.
If the running OS works under MBR scheme, the program search if an internal ESP exists and use it (you can have more than one disk GPT, MBR.. right?), otherwise use /.
If no ESP exists it use /.
If the boot partition, or the chosen ESP doesn't want to mount it use /.
It does not use external disks, always internal.

Edited November 22, 2019 by vector sigma
Attachment removed

Sherlocks · November 20, 2019

56 minutes ago, vector sigma said:

Because it was checking for "Clover.DisableSleepProxyClient" existence, and if true, services was disabled, while to re enable the service the same variable should have been existing but not "true". So the app was removing the key and the daemon was leaving all as is. Fixed.

Yes, is what I tried to say to you:

but probably I did not understood if that was good or not

The problem is else where. You told me to not save again and again the nvram if no changes to the real nvram was made: well, that works! ...but now when you are going to sleep, your HibernationFixUp create a new /nvram.plist..... but the daemon knows the nvram file in the ESP is not changed .

I think I fixed it. To do that it now know if the nvram was saved to / or else were, and if the place is not /, it remove /nvram.plist, leaving the other one.

Try:

Clover.app_v1.08_Beta_Sherlocks.zip

P.S. MBR or GPT makes no difference because:

Search for the boot partition and if it is an ESP the progran use it to dump the nvram.

If the boot partition no longer exist (the case you boot from USB and then you remove the pen drive), it search again for another ESP.

If the running OS works under MBR scheme, the program search if an internal ESP exists and use it (you can have more than one disk GPT, MBR.. right?), otherwise use /.

If no ESP exists it use /.

If the boot partition, or the chosen ESP doesn't want to mount it use /.

It does not use external disks, always internal.

thank you for hard work

1.08 is everything good for entire process.

--------------------------------------------
- CloverDaemonNew v1.0.6
- macOS Version 10.15.2 (Build 19C39d)
- System start at 2019-11-21 07:42:45
------
root mount point is '/Volumes/Macintosh HD'
Started with Clover r5098.
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
making '/' writable as Clover.RootRW=true.
Clover.DisableSleepProxyClient is not set.
Cannot go ahead as / is read-only
Logout hook is: /Library/Application Support/Clover/CloverLogOut

SIGTERM received at 2019-11-21 07:44:33
Clover.DisableSleepProxyClient is not set.
Sleep Proxy Client is already enabled as default.

- CloverLogOut v1.0.2: logout begin at 2019-11-21 07:46:08
Detected ESP disk0s1 as boot device.
mounting disk0s1..
nvram correctly saved to /Volumes/EFI with UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B.
- CloverLogOut: end at 2019-11-21 07:46:11

--------------------------------------------
- CloverDaemonNew v1.0.6
- macOS Version 10.15.2 (Build 19C39d)
- System start at 2019-11-21 07:45:16
------
root mount point is '/Volumes/Macintosh HD'
Started with Clover r5098.
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
making '/' writable as Clover.RootRW=true.
Clover.DisableSleepProxyClient is not set.
Cannot go ahead as / is read-only
old '/Volumes/Mac Data/nvram.plist' removed.
Logout hook is: /Library/Application Support/Clover/CloverLogOut

SIGTERM received at 2019-11-21 07:46:11
Clover.DisableSleepProxyClient is not set.
Sleep Proxy Client is already enabled as default.

- CloverLogOut v1.0.2: logout begin at 2019-11-21 07:51:18
Detected ESP disk0s1 as boot device.
mounting disk0s1..
nvram correctly saved to /Volumes/EFI with UUID: 0E239BC6-F960-3107-89CF-1C97F78BB46B.
- CloverLogOut: end at 2019-11-21 07:51:21

--------------------------------------------
- CloverDaemonNew v1.0.6
- macOS Version 10.15.2 (Build 19C39d)
- System start at 2019-11-21 07:46:54
------
root mount point is '/Volumes/Macintosh HD'
Started with Clover r5098.
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
Removing old rc scripts..
making '/' writable as Clover.RootRW=true.
Clover.DisableSleepProxyClient is not set.
Cannot go ahead as / is read-only
Logout hook is: /Library/Application Support/Clover/CloverLogOut

SIGTERM received at 2019-11-21 07:51:21
Clover.DisableSleepProxyClient=true
Trying to disable Sleep Proxy Client service.

Edited November 20, 2019 by Sherlocks

vector sigma · November 20, 2019

All changes commited at github and Clover.app v1.08 Beta is available at first post.

Rodion2010 · November 21, 2019

10 hours ago, vector sigma said:

because I'm not sure the -x option exist in some old OSes.

-x tested from Mavericks to Catalina, works ok

not sure about very old OSes (Lion, Leopard)

and Clover's script uses the same

gNVRAMf=nvram.plist
gNVRAMbuf=$(nvram -x -p)

Edited November 21, 2019 by Rodion2010

Sherlocks · November 21, 2019

2 hours ago, Rodion2010 said:
-x tested from Mavericks to Catalina, works ok

not sure about very old OSes (Lion, Leopard)

and Clover's script uses the same
gNVRAMf=nvram.plist
gNVRAMbuf=$(nvram -x -p)

not sure lion and snow leopard.

i can test it in this weekend

how can i test?

@vector sigma

thank you for commits and hard work

Edited November 21, 2019 by Sherlocks

Slice · November 21, 2019

@vector sigma

What do you think about ticket 616 on sourceforge?

Rodion2010 · November 21, 2019

1 hour ago, Sherlocks said:

i can test it in this weekend

how can i test?

nvram -xp > nvram.plist

must create readable file. I think it works with any OS

Sherlocks · November 21, 2019

22 minutes ago, Rodion2010 said:
nvram -xp > nvram.plist
must create readable file. I think it works with any OS

i will test it on snowleopard in this weekend

Slice · November 21, 2019

For those who interested

nvram utility is opensource and available up to 10.14.5

https://opensource.apple.com/source/system_cmds/system_cmds-805.250.2/nvram.tproj/

Slice · November 21, 2019

Option -x supported since 10.5 Leopard.

vector sigma · November 21, 2019

@Rodion2010, @Slice, @Sherlocks, about -x option. Probably you don't know my hackintosh experience starts in 10.13, and currently my oldest OS is 10.14.6, plus I'm booting UEFI and I have working nvram. Before starting writing Clover.app, I investigate possible solutions and techniques to save nvram before proceed starting writing code, and among other solutions in the net I found this:

LogoutHook

Installation

sudo defaults write com.apple.loginwindow LogoutHook /path/to/LogoutHook.command

Notes

LogoutHook.command highly depends on macOS nvram utility supporting -x option, which is unavailable on 10.12 and below. (Our nvram.mojave somehow fixes that issue by invoking it instead of system one)

available at https://github.com/acidanthera/OcSupportPkg/blob/master/Utilities/LogoutHook/README.md and I trusted the guys who write this. So simply is not important if the -x option work or not because in the doubt I've made my code to do everythings in reading the nvram and to write/modify a plist, I just hope we won't run into the same problems these guys have .

Edited November 21, 2019 by vector sigma

AudioGod · November 21, 2019

@vector sigma You have done an amazing bit of work creating this. I’ve been using it for a few days now with a z390 master board and it’s freaking awesome dude. 10 out of 10 brother and thank you for thinking up something so useful that does exactly what it’s meant too.

vector sigma · November 21, 2019

22 minutes ago, AudioGod said:

@vector sigma You have done an amazing bit of work creating this. I’ve been using it for a few days now with a z390 master board and it’s freaking awesome dude. 10 out of 10 brother and thank you for thinking up something so useful that does exactly what it’s meant too.

Thanks for testing. Ensure to run the latest release where a lot of problems and errors were resolved.

AudioGod · November 21, 2019

Just now, vector sigma said:

Thanks for testing. Ensure to run the latest release where a lot of problems and errors were resolved.

Will do bud, I’m watching this thread and will keep everything up too date.

vector sigma · November 21, 2019

Guys, do you need a plist editor? Last Xcode editor is really bad:

1515694245_Screenshot2019-11-21at19_28_15.png.a271bf6068edf869bb8ac2403efe85d7.png

for me is horrifying. What do you think??

vector sigma · November 21, 2019

11 hours ago, Slice said:

@vector sigma

What do you think about ticket 616 on sourceforge?

The user which opened the 616 also posted at closed ticket 519. A partial solution is already available for the package:

sudo touch /useespfinder

but nobody cares Lol. I said partial because user in 519 can mount the ESP but then is not the desired one in the fusion array. Clover can start from disk at index 0 (in bios), but start an OS in disk at index 2 and macOS surely doesn't know where it is started from. I can found the boot partition, but then this doesn't seem a good idea if you target an external disk, like a USB pen or another volume which can be another fusion or may be is a RAID array, where again the esp used, is the one espfinder choses, i.e. the first.
In short, it found an ESP, but can be the one you did not like, or not be the one where you expect Clover is already installed to being updated.
This is one of the reason why I wrote this app, as you can just directly target the ESP on the disk you like, or just the Clover boot partition:

@Slice I have a question:

Why we have boot6 and boot7, and not only the second? It doesn't work for all?

Edited November 21, 2019 by vector sigma

Slice · November 22, 2019

8 hours ago, vector sigma said:

@Slice I have a question:

Why we have boot6 and boot7, and not only the second? It doesn't work for all?

Exactly. In most cases boot6 works. But I encounter a hardware where only boot6 may function or only boot7.

Simple test is QEMU. Only boot6 is working here.

PS. Qemu is 4.1.0 now and its command line changed again. I don't know again how to use it.

joevt · November 22, 2019

16 hours ago, Slice said:

Option -x supported since 10.5 Leopard.

Do we need the -x option? Here's a script to create a plist (needs modification if you want to show string instead of just data):


plistname=nvram.plist
/usr/libexec/PlistBuddy -c "Clear dict" "${plistname}" > /dev/null
IFS=$'\n'
for nvramvar in $(nvram -p | perl -pe 's/([^\t]+)\t.*/$1/'); do
    plutil -insert "$nvramvar" -data "$(printf "$(nvram "$nvramvar" | sed -E '/^'"$nvramvar"'.(.*)/s//\1/g;/\\/s//\\\\/g;/%/s//\\x/g')" | base64)" "${plistname}"
done

9 hours ago, vector sigma said:

Guys, do you need a plist editor? Last Xcode editor is really bad:

for me is horrifying. What do you think??

You can use PlistBuddy to create plist and plutil to modify it. But need to make sure those exist in early macOS versions? They both appear to exist in Leopard.

vector sigma · November 22, 2019

10 hours ago, joevt said:

You can use PlistBuddy to create plist and plutil to modify it. But need to make sure those exist in early macOS versions? They both appear to exist in Leopard.

Oh no, I mean to create a property list editor, like Xcode.

Rodion2010 · November 22, 2019

On 11/21/2019 at 7:14 PM, vector sigma said:

@Rodion2010, @Slice, @Sherlocks, about -x option.


LogoutHook

Installation

sudo defaults write com.apple.loginwindow LogoutHook /path/to/LogoutHook.command

Notes

LogoutHook.command highly depends on macOS nvram utility supporting -x option, which is unavailable on 10.12 and below. (Our nvram.mojave somehow fixes that issue by invoking it instead of system one)

seems to be different -x options

latest nvram utility from Mojave can export any single key to XML with -x

"${nvram}" -x "${key}"

but export of the whole file ( -x -p) worked from Leopard and works now

that is enough for our tasks

Edited November 22, 2019 by Rodion2010

Clover.app testing

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites