Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,155 posts in this topic

Recommended Posts

MakAsus
MakAsus
Posted
Posted
4 minutes ago, miliuco said:

@MakAsus

You boot Sonoma with SIP enabled but is the Fenvi wifi working in this way?

I booted into Sonoma with SIP enabled and kexts blocked. At the same time, the Fenvi wifi does not work for me, but the realtek wifi utility and wifi USB dongle stick are works.

  • Like 1
Link to comment
Share on other sites
fabiosun
fabiosun
Posted
Posted
9 minutes ago, MakAsus said:

no one is stopping you from temporarily moving these Kexts to the off folder. I

I use only Sonoma

THis feature would be use to update to new Sonoma beta.

It is possible as we know, but we have this feature at bootmenu level and  i hoped in a future implementation in the config.plist :)

 

  • Like 1
Link to comment
Share on other sites
MakAsus
MakAsus
Posted
Posted (edited)
On 1/23/2024 at 8:12 PM, mariosun said:

I use only Sonoma

THis feature would be use to update to new Sonoma beta.

It is possible as we know, but we have this feature at bootmenu level and  i hoped in a future implementation in the config.plist :)

 

I understand.😉 Bat as far as I know, such a similar function is available in the OС because all kexts there are stored in a common folder, so each aded kext is entered into the config in a certain order, and the ability has been added not to delete a line, but to disable it.
Which is not very convenient if there is no way boot to desktop.
Unlike the OC, a problematic kext can be blocked once by a space or permanently moved to the off folder, which can be done even from the Clover shell.
In Clover, unlike the OC, a problematic kext can be blocked once with a space or permanently moved to a disabled folder, which can be done even from the Clover shell. Therefore, I guess that this function will be duplicate.

Edited by MakAsus
  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
23 hours ago, tluck said:

Ok interesting.  OEM/boardID/kexts works up to now. meaning some change in december for 5157.

What do you see in preboot.log as me? 

0:706  0:010  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Standard PC (Q35 + ICH9, 2009)--52-54-00-12-34-56'. Dir doesn't exist.
0:707  0:000  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Standard PC (Q35 + ICH9, 2009)'. Dir doesn't exist.
0:707  0:000  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Standard PC (Q35 + ICH9, 2009)-2000'. Dir doesn't exist.
0:707  0:000  _checkOEMPath looked for config file at '\EFI\CLOVER\OEM\\config.plist'. File doesn't exist.
0:707  0:000  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\-2000'. Dir doesn't exist.

 

  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

No such path. There is a path

OEM\BoardName\...

but there is no path

OEM\BoardID\...

So why I see these messages in QEMU 

0:693  0:000  Running on: 'Standard PC (Q35 + ICH9, 2009)' with board ''

BoardName is empty. 

0:707  0:000  _checkOEMPath looked for config file at '\EFI\CLOVER\OEM\\config.plist'. File doesn't exist.

this is empty board name.

  • Like 2
Link to comment
Share on other sites
tluck
tluck
Posted
Posted
On 1/24/2024 at 7:56 AM, Slice said:

What do you see in preboot.log as me? 

0:706  0:010  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Standard PC (Q35 + ICH9, 2009)--52-54-00-12-34-56'. Dir doesn't exist.
0:707  0:000  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Standard PC (Q35 + ICH9, 2009)'. Dir doesn't exist.
0:707  0:000  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\Standard PC (Q35 + ICH9, 2009)-2000'. Dir doesn't exist.
0:707  0:000  _checkOEMPath looked for config file at '\EFI\CLOVER\OEM\\config.plist'. File doesn't exist.
0:707  0:000  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\-2000'. Dir doesn't exist.

 

so the latest clover loads everything but kexts from OEM/board

 

tluck@Toms-T420 /Volumes/ESP/EFI/CLOVER

$ grep OEM /Library/Logs/CloverEFI/boot.log

0:105  0:000  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\41786UU--00-21-CC-4A-13-10'. Dir doesn't exist.

0:105  0:000  _checkOEMPath Look for oem dir at path '\EFI\CLOVER\OEM\41786UU\UEFI'. Dir doesn't exist.

0:105  0:000  _checkOEMPath: set OEMPath: '\EFI\CLOVER\OEM\41786UU'

0:106  0:000  Using config.plist at path: \EFI\CLOVER\OEM\41786UU

11:673  0:000  DSDT found in Clover volume OEM folder: \EFI\CLOVER\OEM\41786UU\ACPI\patched\DSDT.aml

11:674  0:000  Inserting SSDT-T420-PS2K-keys.aml from \EFI\CLOVER\OEM\41786UU\ACPI\patched: size=1418 OCABC: AllocPages 1 0xB6FC2000 (1) - Success

11:674  0:000  Inserting SSDT-PNLF.aml from \EFI\CLOVER\OEM\41786UU\ACPI\patched: size=1128 OCABC: AllocPages 1 0xB6FC1000 (1) - Success

11:674  0:000  Inserting SSDT-RMCF.aml from \EFI\CLOVER\OEM\41786UU\ACPI\patched: size=911 OCABC: AllocPages 1 0xB6FC0000 (1) - Success

11:674  0:000  Inserting SSDT-CpuPm.aml from \EFI\CLOVER\OEM\41786UU\ACPI\patched: size=1515 OCABC: AllocPages 1 0xB6FBF000 (1) - Success


meaning i had to copy OEM/*/kexts to EFI/CLOVER

tluck@Toms-T420 /Volumes/ESP/EFI/CLOVER

$ ls -l /Volumes/ESP/EFI/CLOVER/

total 3521

-rwxrwxrwx  1 tluck  staff  1798912 Jan 25 20:10 CLOVERX64.efi

drwxrwxrwx  1 tluck  staff      512 Jan 25 20:35 NU

drwxrwxrwx  1 tluck  staff      512 Jan 20 09:16 OEM

drwxrwxrwx  1 tluck  staff      512 Jan 19 15:45 drivers

drwxrwxrwx  1 tluck  staff      512 Jan 25 20:10 kexts

drwxrwxrwx  1 tluck  staff      512 Jan 18 22:34 misc

drwxrwxrwx  1 tluck  staff      512 Jan 19 15:47 themes

drwxrwxrwx  1 tluck  staff      512 Jan 25 20:10 tools

 

tluck@Toms-T420 /Volumes/ESP/EFI/CLOVER

$ ls -l /Volumes/ESP/EFI/CLOVER/OEM/41786UU/

total 55

drwxrwxrwx  1 tluck  staff   1536 Jan 18 19:41 ACPI

-rwxrwxrwx  1 tluck  staff  12268 Nov 11  2021 config.plist

-rwxrwxrwx  1 tluck  staff  13369 Apr 28  2021 config.works.plist

drwxrwxrwx  1 tluck  staff    512 Jan 21 18:01 kexts


oh but the graphics are working again! thanks!

Link to comment
Share on other sites
Stefanalmare
Stefanalmare
Posted
Posted

Maybe somebody need OC quirk DisableIoMapperMapping, Clover equivalent:

 

Spoiler

<key>KextsToPatch</key>
        <array>
            <dict>
                <key>Comment</key>
                <string>DisableIoMapperMapping</string>
                <key>Disabled</key>
                <false/>
                <key>Find</key>
                <data>ww==</data>
                <key>InfoPlistPatch</key>
                <false/>
                <key>MaskFind</key>
                <data>AA==</data>
                <key>MaskReplace</key>
                <data>/w==</data>
                <key>Name</key>
                <string>com.apple.iokit.IOPCIFamily</string>
                <key>Procedure</key>
                <string>__ZN8AppleVTD14addMemoryRangeEyy</string>
                <key>Replace</key>
                <data>ww==</data>
            </dict>
        </array>

 

Or @Slice can insert it as quirk. It was necessary for me in my z390 Aorus Master.

 

@Slice I had some time and added Clover as boot option in my rigs. Please explain me how can I make the latest Clover to boot legacy BIOS Core2 machines. I have 3 of them and I can't reach Clover picker. Always send me to BIOS boot options.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

@Stefanalmare,

OK, one more explanation.

1. You should format HDD to GUID partition scheme with 200Mb EFI partition (ESP) formatted to FAT32. SIC! It should not be FAT16! Check carefully.

2. Sector 0 of raw device HDD must contain 442 bytes of loader boot0af (first stage loader)

3. Sector 0 of ESP must contain 512 bytes of loader boot1f32 (second stage loader)

4. At the root of ESP there must be file (it can be invisible) BOOT which can be renamed BOOT6 or BOOT7. For Core2 machines BOOT7 is preferable. Rename BOOT7 -> BOOT (third stage loader)

5. This third stage loader will search a file ESP/EFI/CLOVER/CLOVERX64.EFI. It will not search /BOOTX64.EFI. This is Clover GUI.

Avoid third party first, second or third loaders because they will bot boot Clover.

How to install these loaders read again  https://github.com/CloverHackyColor/CloverBootloader/wiki

  • Like 2
Link to comment
Share on other sites
Stefanalmare
Stefanalmare
Posted
Posted (edited)
7 hours ago, Slice said:

@Stefanalmare,

OK, one more explanation.

1. You should format HDD to GUID partition scheme with 200Mb EFI partition (ESP) formatted to FAT32. SIC! It should not be FAT16! Check carefully.

2. Sector 0 of raw device HDD must contain 442 bytes of loader boot0af (first stage loader)

3. Sector 0 of ESP must contain 512 bytes of loader boot1f32 (second stage loader)

4. At the root of ESP there must be file (it can be invisible) BOOT which can be renamed BOOT6 or BOOT7. For Core2 machines BOOT7 is preferable. Rename BOOT7 -> BOOT (third stage loader)

5. This third stage loader will search a file ESP/EFI/CLOVER/CLOVERX64.EFI. It will not search /BOOTX64.EFI. This is Clover GUI.

Avoid third party first, second or third loaders because they will bot boot Clover.

How to install these loaders read again  https://github.com/CloverHackyColor/CloverBootloader/wiki

 

Thank you!

 

Spoiler

1.png

 

Edited by Stefanalmare
  • Like 4
Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted

Testing macOS Sonoma with Clover ESP Legacy booting on DELL Optiplex 790 base CPU Sandy bridge Graphics Kepler Geforce 710 :D

Works

 

Spoiler

image.png

 

  • Like 3
Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted
6 hours ago, Slice said:

@chris1111,

check please saving NVRAM.plist during reboot (rc.shutdown etc). I remember you know what I am saying about.

What is the NVRAM issue?

OK I can see but tell me more about because correct me if Iam wrong a lot of change in clover in the NVMAM side from you

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
5 hours ago, chris1111 said:

What is the NVRAM issue?

OK I can see but tell me more about because correct me if I am wrong a lot of change in clover in the NVMAM side from you

There should be nvram2 utility in /usr/local/bin/

It works similar to native nvram utility but saves more variables.

New nvram.plist can be read by Clover 5155+.

But I forgot if rc.shutdown should have special permissions.

 

nvram2.zip

Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted
57 minutes ago, Slice said:

There should be nvram2 utility in /usr/local/bin/

It works similar to native nvram utility but saves more variables.

New nvram.plist can be read by Clover 5155+.

But I forgot if rc.shutdown should have special permissions.

 

nvram2.zip 10.33 kB · 0 downloads

 

With the Clover install Package nvram2 installs well in /usr/local/bin no problem on that side
Regarding rc.shutdown and permissions, I don't think there is a problem because I have no Shutdown problem even on Legacy based config

 

  • Like 1
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
27 minutes ago, chris1111 said:

@Slice

I don't have any nvram.plist but you can't trust me because I'm on a Legacy-based machine, and I even tried to put EmuVariableUefi.efi without success

So why I asked you. I want to see nvram.plist on legacy-based machine.

It looks like rc.shutdown will not work in Sonoma. Some other solution?

Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted (edited)
5 hours ago, Slice said:

So why I asked you. I want to see nvram.plist on legacy-based machine.

It looks like rc.shutdown will not work in Sonoma. Some other solution?

It seem not working also in Ventura, I just testing booting Ventura

EDIT *****

But it work on Catalina :yes:

image.png

Edited by chris1111
But it work on Catalina
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...