Clover Problems and Solutions

[apianti]

OK, I just don't remember why I did this. May be because of other bug.

 

Yes, there appears to be some conflict between the new injection disabling and injection after fake smc (non) detection.

 

No, the problem is deeper.

The structure is packed and so all reading should be with ReadUnaligned method, it's painful.

So I keep all field as natural aligned. It is also affected clover-genconfig.

If rewrite Clover from initial there will be other way but I just keeping this way.

 

Easy to move that struct (and perhaps others) outside of the #pragma pack(1).

 

But that's not the same, if you have a different packing then each individual member would align to the packing (which is probably 4 or 8) which results in a huge size when each BOOLEAN would inflate from 1 byte to 4 or 8.

 

EDIT: Errr... well not all of them would inflate because of the rules of packing but rearranging them would probably have a better effect.

Well, that's your opinion.

Using this method for many years now without problems.

And no, it isn't windows so the comparison is wrong.

BTW, kext from EFI will load with SIP enabled.

 

Sent from my ONEPLUS A5000 using Tapatalk

 

What about what I said was an opinion? Advising someone to not properly install something is reckless. It's an operating system, the comparison is apt. Prove to me about the injecting with SIP kext restrictions enabled, I've seen many say that and not one can prove it. In fact they have proven that you cannot enable SIP and inject properly. Also, I helped write a lot of what's going on, or at least had a hand in researching. Injection uses at least twice the memory of each kext you inject, but most likely much more than that. The kext is loaded into memory, written to the datahub, and then moved into the kernel. If you somehow think that is less resources than being stripped, aligned, and incorporated into the kernel prelinked....... 

[Slice]

I reverted commit 4242. Let "Detect" be working. But I will not test. Sure someone will report about this.

 

Anyway I tested two similar FakeSMC injected. One from SLE and other from EFI.

The difference is Key Set so I can easy to see who is winner.

The kext from SLE is winner.

[RehabMan]

I reverted commit 4242. Let "Detect" be working. But I will not test. Sure someone will report about this.

 

Anyway I tested two similar FakeSMC injected. One from SLE and other from EFI.

The difference is Key Set so I can easy to see who is winner.

The kext from SLE is winner.

The winner also might depend on bundle version.

[WinstonAce]

What about what I said was an opinion? Advising someone to not properly install something is reckless. It's an operating system, the comparison is apt. Prove to me about the injecting with SIP kext restrictions enabled, I've seen many say that and not one can prove it. In fact they have proven that you cannot enable SIP and inject properly. Also, I helped write a lot of what's going on, or at least had a hand in researching. Injection uses at least twice the memory of each kext you inject, but most likely much more than that. The kext is loaded into memory, written to the datahub, and then moved into the kernel. If you somehow think that is less resources than being stripped, aligned, and incorporated into the kernel prelinked....... 

 

 

You keep playing the memory card, but how much it really affects a modern system?

what proof do you need about SIP enabled?

anyhow, this method always worked for me (only 4 kexts needed in my system)

and i'm betting that its the way most of Clover use it and all of Ozmosis users use it.

[RehabMan]

I reverted commit 4242.

There were changes to two files in r4242(kext_patcher.c and kext_inject.c). You only reverted the changes to one of them (kext_pacher.c).

[barijaona]

nvram save script seems broken in High Sierra

 

On my system, the nvram.plist file will never be saved to the ESP on system shutdown.

The culprit seems that `gpt -r show` applied on the boot device will fail : " Operation not permitted "

 

Details : save script v.1.65/High Sierra 10.13.0/APFS

[tluck]

nvram save script seems broken in High Sierra

 

On my system, the nvram.plist file will never be saved to the ESP on system shutdown.

The culprit seems that `gpt -r show` applied on the boot device will fail : " Operation not permitted "

 

Details : save script v.1.65/High Sierra 10.13.0/APFS

what is your SIP setting? you will get this warning if SIP is enabled... or specifically if you don't have unrestricted filesystem (2nd bit ) SIP 0x2 set

[barijaona]

what is your SIP setting? you will get this warning if SIP is enabled... or specifically if you don't have unrestricted filesystem (2nd bit ) SIP 0x2 set

 

Yes. I have SIP enabled. I suggest replacing the line :

gPartIndex=$(gpt -r show "/dev/${gDisk[i]}" 2> /dev/null |grep -i "${gEfiUID}" |awk '{print $3}')

with

gPartIndex=$(diskutil list "/dev/${gDisk[i]}" 2> /dev/null | awk '{print $1,$2}' | grep EFI | awk -F : '{print $1}')

(I am currently not on my machine, so I am not 100% sure of the syntax, but I hope you get the idea).

[apianti]

You keep playing the memory card, but how much it really affects a modern system?

what proof do you need about SIP enabled?

anyhow, this method always worked for me (only 4 kexts needed in my system)

and i'm betting that its the way most of Clover use it and all of Ozmosis users use it.

 

What is value of csr-active-config in nvram?

 

EDIT: Also I'd like to see that you actually restarted and didn't just enable it in recovery and screen shot.

EDIT2: I don't get why this would be documented if it does not check extensions at boot:

The kernel refuses to boot if unsigned extensions are present, showing the user a prohibition sign instead.

Yes. I have SIP enabled. I suggest replacing the line :

gPartIndex=$(gpt -r show "/dev/${gDisk[i]}" 2> /dev/null |grep -i "${gEfiUID}" |awk '{print $3}')

with

gPartIndex=$(diskutil list "/dev/${gDisk[i]}" 2> /dev/null | awk '{print $1,$2}' | grep EFI | awk -F : '{print $1}')

(I am currently not on my machine, so I am not 100% sure of the syntax, but I hope you get the idea).

 

diskutil is not available when this is run. Also it is restricted just as gpt is.

[barijaona]

 

diskutil is not available when this is run. Also it is restricted just as gpt is.

 

??? You are probably referring to another script than the one I am referring to. My proposal is for 80.save_nvram_plist.local which currently already uses diskutil on multiple places.

I am pretty sure that (at least on High Sierra) `diskutil list` has no restriction while `gpt show` on the boot disk is restricted when SIP is enabled.

[RehabMan]

Yes. I have SIP enabled. I suggest replacing the line :

gPartIndex=$(gpt -r show "/dev/${gDisk[i]}" 2> /dev/null |grep -i "${gEfiUID}" |awk '{print $3}')

with

gPartIndex=$(diskutil list "/dev/${gDisk[i]}" 2> /dev/null | awk '{print $1,$2}' | grep EFI | awk -F : '{print $1}')

(I am currently not on my machine, so I am not 100% sure of the syntax, but I hope you get the idea).

 

"diskutil list|grep EFI" is not a reliable way to determine the EFI partition.

Any partition can be named EFI. There is nothing sacred about the name, it is the GUID that determines whether it is the ESP.

 

For example, one of my systems I have a disk with EFI, EFI0 and EFI1 partitions... Wanna guess which one is the ESP?

[barijaona]

"diskutil list|grep EFI" is not a reliable way to determine the EFI partition.

Any partition can be named EFI. There is nothing sacred about the name, it is the GUID that determines whether it is the ESP.

 

For example, one of my systems I have a disk with EFI, EFI0 and EFI1 partitions... Wanna guess which one is the ESP?

I am not testing the partition name, I am testing the type (cf. the `awk` thing before the `grep`).

[RehabMan]

I am not testing the partition name, I am testing the type (cf. the `awk` thing before the `grep`).

As long as TYPE=EFI for the partition with the ESP GUID, then might be ok.

Now I'm trying to remember why I didn't use that for my own mount_efi.sh.

 

But @apianti's comment is very relevant here:

diskutil is not available when this is run.

One possibility to get around that is to have a different script run when 'diskutil' *is* available, and have it store the info for later.

[tluck]

@barijaona

 

Note: as is the script should be putting the nvram.plist in / of OS as the logic is if no ESPs are found then write the file there.

but to get the script to write to ESP(s) when SIP is enabled, perhaps test this code using diskutil vs gpt - which is a 1 line change -  (looks for TYPE EFI):

#gPartIndex=$(gpt -r show "/dev/${gDisk[i]}" 2> /dev/null |grep -i "${gEfiUID}" |awk '{print $3}')
gPartIndex=$(diskutil list "/dev/${gDisk[i]}" | grep "  EFI " | sed -e's/^.*disk.s//')

seems to work for me on a SIP enabled system.

$ sudo ./80.save_nvram_plist.fixed
v1.16.6 (c) 2017 syscl/lighting/Yating Zhou, tluck, Sherlocks, lvs1974
2017-10-24-09:39:12  disk0: ESP -- Ignored -- No CLOVER directory located
2017-10-24-09:39:12  disk1: ------ Ignored -- No ESP on disk
2017-10-24-09:39:12  disk2: ESP -- Target  -- /Volumes/ESP-21/EFI/CLOVER
2017-10-24-09:39:13  disk3: ESP -- Ignored -- No CLOVER directory located
2017-10-24-09:39:13  disk4: ------ Ignored -- No ESP on disk
2017-10-24-09:39:13  disk5: ------ Ignored -- No ESP on disk
2017-10-24-09:39:13  NVRAM: No change since last update in /Volumes/ESP-21/nvram.plist

[Sherlocks]

can we use nvram reset in gui?

 

@cecekpawon implemented nvram reset features in his github

seems very useful feature. because i had big problem.

 

recently, i faced big problem about nvram when test hiberationfixup.

https://sourceforge.net/p/hibernationfixup/discussion/general/thread/93f601f6/

 

my laptop doesn't support native nvram. so i have to use EmuVariableUefi + rc script.

 

when test hiberationfixup, i forgot to add "-hbfx-dump-nvram"  boot arg. my system slept with hiberation mode. then i turned on my system.

i can't see my high sierra disk (hibernated tag). can see above link

0:572 0:005 Loading nvram.plist from Vol 'Macintosh HD' - loaded, size=2636

 

because of this part in nvram storage and always add this keys

0:578 0:000 Adding Key: IOHibernateRTCVariables: Size = 44, Data: 41 41 50 4C 01 00 00 00 A3 26 09 2D BA 87 74 47 BF DA DD 87 F0 A9 ED 15 27 19 95 73 6E 01 DA EA EE 6A 15 2E 92 FF 15 59 7E 29 48 D1 
0:578 0:000 Adding Key: Boot0082: Size = 118, Data: 01 00 00 00 6E 00 00 00 02 01 0C 00 D0 41 03 0A 00 00 00 00 01 01 06 00 00 17 03 12 0A 00 01 00 00 00 00 00 04 01 2A 00 02 00 00 00 00 48 06 00 00 00 00 00 00 28 2A 08 00 00 00 00 D6 D5 94 54 8F 9D 5E 4B AC 99 BF 55 4C E2 38 82 02 02 04 03 24 00 F7 FC 74 BE 7C 0B F3 49 91 47 01 F4 04 2E 68 42 8F 7F 32 3C 06 B8 EB 44 AB F7 A6 C8 D8 0D 5E 49 7F FF 04 00 

 

I can not boot any disk for mac (macos installer usb, recovery, any macos disk) because clover always reads nvram on macintosh HD. my system doesn't support hibernatefixup method properly.

The symptom is that the osxaptiofix message will be briefly rebooted immediately. I can not do anything.

Furthermore, because of the apfs format, there is no way to force a hard disk to find the nvram file by mounting a macintosh hd disk in Windows.

So I forced to format the macintosh hd in Windows(only way to resolve this problem) and booted it via mac installer usb.

 

also seems to help this case link

 

If clover has the ability to initialize nvram in the gui, it seems to be able to solve the problem without formatting even in this worst case.

 

thanks in advance

[apianti]

 

@barijaona

 

Note: as is the script should be putting the nvram.plist in / of OS as the logic is if no ESPs are found then write the file there.

but to get the script to write to ESP(s) when SIP is enabled, perhaps test this code using diskutil vs gpt - which is a 1 line change -  (looks for TYPE EFI):

#gPartIndex=$(gpt -r show "/dev/${gDisk[i]}" 2> /dev/null |grep -i "${gEfiUID}" |awk '{print $3}')
gPartIndex=$(diskutil list "/dev/${gDisk[i]}" | grep "  EFI " | sed -e's/^.*disk.s//')

seems to work for me on a SIP enabled system.

$ sudo ./80.save_nvram_plist.fixed
v1.16.6 (c) 2017 syscl/lighting/Yating Zhou, tluck, Sherlocks, lvs1974
2017-10-24-09:39:12  disk0: ESP -- Ignored -- No CLOVER directory located
2017-10-24-09:39:12  disk1: ------ Ignored -- No ESP on disk
2017-10-24-09:39:12  disk2: ESP -- Target  -- /Volumes/ESP-21/EFI/CLOVER
2017-10-24-09:39:13  disk3: ESP -- Ignored -- No CLOVER directory located
2017-10-24-09:39:13  disk4: ------ Ignored -- No ESP on disk
2017-10-24-09:39:13  disk5: ------ Ignored -- No ESP on disk
2017-10-24-09:39:13  NVRAM: No change since last update in /Volumes/ESP-21/nvram.plist

 

No with diskutil the issue is different during shutdown, I believe that there is some service no longer available that diskutil depends on. Same as if you startup single user.

[tluck]

@apianti - well i am not sure what you mean exactly about being different?   this script (80.save_nvram_plist.local) (as well as any others in /etc/rc.shutdown.d) is kicked off by the LogoutHook method, therefore diskutil is available.

 

$ sudo defaults read com.apple.loginwindow LogoutHook
/Library/Application Support/Clover/CloverDaemon-stopservice

[WinstonAce]

What is value of csr-active-config in nvram?

 

EDIT: Also I'd like to see that you actually restarted and didn't just enable it in recovery and screen shot.

EDIT2: I don't get why this would be documented if it does not check extensions at boot:

The kernel refuses to boot if unsigned extensions are present, showing the user a prohibition sign instead.

Do you see any reason I will enable it in recovery and take a screenshot?

[barijaona]

 

@barijaona

 

Note: as is the script should be putting the nvram.plist in / of OS as the logic is if no ESPs are found then write the file there.

but to get the script to write to ESP(s) when SIP is enabled, perhaps test this code using diskutil vs gpt - which is a 1 line change -  (looks for TYPE EFI):

#gPartIndex=$(gpt -r show "/dev/${gDisk[i]}" 2> /dev/null |grep -i "${gEfiUID}" |awk '{print $3}')
gPartIndex=$(diskutil list "/dev/${gDisk[i]}" | grep "  EFI " | sed -e's/^.*disk.s//')

seems to work for me on a SIP enabled system.

Yes, work for me too.

 

But as @Rehabman also noticed, there is a slight chance that you get a false positive with a non EFI partition which is named "EFI".

This is why I feel safer with the following version which makes sure that the "EFI" string is present in the partition type indicator :

#gPartIndex=$(gpt -r show "/dev/${gDisk[i]}" 2> /dev/null |grep -i "${gEfiUID}" |awk '{print $3}')
gPartIndex=$(diskutil list "/dev/${gDisk[i]}" 2> /dev/null | awk '{print $1,$2}' | grep EFI | awk -F : '{print $1}')

[tluck]

well exactly. i am not searching for "EFI" but for "  EFI " (blank blank EFI blank) 

 

EDIT: and i prefer to look at Identifier column so one does not have to assume 1-1 correspondence between partition number and disk0sX identifier.

[gujiangjiang]

My laptop also don’t have native nvram support and I don’t use emu driver because when I use this driver the LastBootVolume will not works anymore because Clover can’t write lastbootvolume data to nvram.plist.

 

Second,I found when I use apfs in 10.13 they always create nvram.plist both in system partition and esp partition.Does 80nvram rc script don’t support APFS partition?

 

Last I want to know why many laptop can’t use native nvram?I going to Ubuntu and look up our efi variables and it can read and write well and I found Clover can read and write nvram successfully.So why system can’t read and write native nvram?

 

As I know the acre Swift 3 laptop with kabylake processor and 200-series motherboard can use native nvram well and I don’t know the reason.

 

So I want to compare and found why cause this?we can compare efi variables between real Mac and our hackitosh to find if the format is wrong or other problem.

 

Or we can read and write efi variables var Clover because Clover can support nvram r&w well.

 

 

从我的 iPhone 发送，使用 Tapatalk

[apianti]

...Who knows what I'm talking sometimes... 

[RehabMan]

Yes, work for me too.

 

But as @Rehabman also noticed, there is a slight chance that you get a false positive with a non EFI partition which is named "EFI".

This is why I feel safer with the following version which makes sure that the "EFI" string is present in the partition type indicator :

#gPartIndex=$(gpt -r show "/dev/${gDisk[i]}" 2> /dev/null |grep -i "${gEfiUID}" |awk '{print $3}')
gPartIndex=$(diskutil list "/dev/${gDisk[i]}" 2> /dev/null | awk '{print $1,$2}' | grep EFI | awk -F : '{print $1}')

 

I decided to do this in my mount_efi.sh.... it uses plist output and PlistBuddy to parse it, maybe a bit less subject to false positives:

# Find the associated EFI partition on DiskDevice
diskutil list -plist "/dev/$DiskDevice" 2>/dev/null >/tmp/org_rehabman_diskutil.plist
for ((part=0; 1; part++)); do
    content=`/usr/libexec/PlistBuddy -c "Print :AllDisksAndPartitions:0:Partitions:$part:Content" /tmp/org_rehabman_diskutil.plist 2>&1`
    if [[ "$content" == *"Does Not Exist"* ]]; then
        echo "Error: cannot locate EFI partition for $DestVolume"
        exit 1
    fi
    if [[ "$content" == "EFI" ]]; then
        EFIDevice=`/usr/libexec/PlistBuddy -c "Print :AllDisksAndPartitions:0:Partitions:$part:DeviceIdentifier" /tmp/org_rehabman_diskutil.plist 2>&1`
        break
    fi
done

# should not happen
if [[ -z "$EFIDevice" ]]; then
    echo "Error: unable to determine EFIDevice from $DiskDevice"
    exit 1
fi

$DiskDevice is something like 'disk0'.

$EFIDevice would be disk0s1 (EFI as first partition on disk0).

[tluck]

I decided to do this in my mount_efi.sh.... it uses plist output and PlistBuddy to parse it, maybe a bit less subject to false positives:

# Find the associated EFI partition on DiskDevice
diskutil list -plist "/dev/$DiskDevice" 2>/dev/null >/tmp/org_rehabman_diskutil.plist
for ((part=0; 1; part++)); do
    content=`/usr/libexec/PlistBuddy -c "Print :AllDisksAndPartitions:0:Partitions:$part:Content" /tmp/org_rehabman_diskutil.plist 2>&1`
    if [[ "$content" == *"Does Not Exist"* ]]; then
        echo "Error: cannot locate EFI partition for $DestVolume"
        exit 1
    fi
    if [[ "$content" == "EFI" ]]; then
        EFIDevice=`/usr/libexec/PlistBuddy -c "Print :AllDisksAndPartitions:0:Partitions:$part:DeviceIdentifier" /tmp/org_rehabman_diskutil.plist 2>&1`
        break
    fi
done

# should not happen
if [[ -z "$EFIDevice" ]]; then
    echo "Error: unable to determine EFIDevice from $DiskDevice"
    exit 1
fi

$DiskDevice is something like 'disk0'.

$EFIDevice would be disk0s1 (EFI as first partition on disk0).

 

 

nice. i will look at incorporating this method with diskutil into the script - which is seems to take the uncertainty out the EFI type vs name.

[tluck]

RE: nvram save script and SIP

 

@syscl

here is rewrite of the nvram_save_script (v1.16.6) using diskutil to find the EFI partition on disks vs gpt (which has restrictions when SIP is completely enabled).  The section to find EFI device is based on the RehabMan's parse method from above - but adapted for this script. The point was to check find a disk's EFI partition (not by name) and its associated device name (e.g disk0s1)

 

the key section looks like this now:

for ((i=0; i<${#gDisk[@]}; ++i))
    do
      local gESP=""
      local plist=$( diskutil list -plist "/dev/${gDisk[i]}" 2> /dev/null )
      for ((part=0; 1; part++));
      do
            content=$( /usr/libexec/PlistBuddy -c "Print :AllDisksAndPartitions:0:Partitions:$part:Content" /dev/stdin <<< $plist 2>&1 )
            if [[ "$content" == *"Does Not Exist"* ]];
            then
                break
            fi
            if [[ "$content" == "EFI" ]];
            then
                gESP=$( /usr/libexec/PlistBuddy -c "Print :AllDisksAndPartitions:0:Partitions:$part:DeviceIdentifier" /dev/stdin <<< $plist 2>&1 )
                break
            fi
      done
      gLogTimeStamp=$(date +%Y-%m-%d-%H:%M:%S)
      if [[ $gESP != "" ]];
      then
            printf "${gLogTimeStamp}  ${gDisk[i]}: ESP --"
                     local gMountPoint=$(_mountESP ${gESP})
      ...
      else
            printf "${gLogTimeStamp}  ${gDisk[i]}: ------ Ignored -- No ESP on disk\n"
      fi
    done

save_nvram_script.1.16.6.zip