Jump to content
ErmaC

Clover Problems and Solutions

2,946 posts in this topic

Recommended Posts

Note: I was going to do each of these as a separate post, but the stupid site wouldn't do that.
So... all in one!
 
--
 
restore "Without caches" option
 
This is still a relatively commonly used option and therefore should be easy to do (eg. without adding -f to Boot/Arguments from Clover Options).
 
Affected files: loader.c

 

---
 
SSDT generation changes:
 
ACPI/SSDT/Generate/APSN
ACPI/SSDT/Generate/APLF
ACPI/SSDT/Generate/PluginType
 
Allow separate control over these object injections in generated PM SSDT.
This is useful when using SSDT.aml generated from ssdtPRgen.sh, but dropping the OEM CPU related SSDTs.  In that case you want to use Generate=true (to generate CStates/PStates, aka _PSS, _CST, etc), but you don't want to generate APSN, APLF as these objects are already in ssdtPRgen.sh generated SSDT.aml.
 
Generate/PluginType is useful for injecting only plugin-type=1 on CPU0.  Used by itself, it can be used to enable native CPU PM on Haswell and later.  This option was already "sort of" in there but required HWP to be used as well.  This change makes it applicable even if not using HWP. 
 
Affected files: Settings.c, Platform.h, StateGenerator.c. AcpiPatcher.c
 
Related commits (this one took me a while to get backward compatibility right):
 
--
 
Minor cleanup: "remove unused identifier kernelXCPMAllowed"
 
 
--
 
Fixing SSDT extracted names: "strip trailing spaces from SSDT OemTableId for origin dump"
 
Recent change was made to place OemTableID as a suffix for extracted SSDTs (eg. "SSDT-7-SaSsdt.aml"), but often you end up with trailing spaces
(eg. "SSDT-7-SaSsdt  .aml").
 
Afffected files: AcpiPatcher.c
 
 
--
 
Adding OemTableId to extracted SSDTs is not always convenient.
Added config.plist/ACPI/SSDT/NoOemTableId option to disable it.
 
Affected files: AcpiPatcher.c, Platform.h, Settings.c
 
 
 
--
 
Changed numbering scheme for dynamic SSDTs (this is for AutoMerge feature below).
By numbering the dynamic ones differently, the number assigned to static SSDTs can be used to find the placement in the XSDT for automatic merge/replacement.
 
New numbering scheme for dynamic SSDTs is:
- For dynamic SSDT pointed by DSDT.aml: SSDT-xDSDT_#-id.aml (# is child reference count)
- For dynamic SSDT pointed by an SSDT: SSDT-x#_#-id.aml (first # is static SSDT reference#, second # is child reference #)
 
Static SSDTs always end up with a contiguous numbering scheme, SSDT-0*.aml through and including SSDT-n*.aml, where n is the number of static SSDTs minus 1.
 
Affected files: AcpiPatcher.c 
 
 
--
 
AutoMerge feature for merging/replacement of SSDTs (or other AMLs) by content in ACPI/patched
 
By setting config.plist/ACPI/AutoMerge=true (default is false to retain old behavior), content in ACPI/patched will attempt to be matched against native bits referred to by the XSDT.  Much like how DSDT.aml placed in ACPI/patched *replaces* native DSDT, you can use this feature to replace SSDTs (or other tables) automatically without using DropTables, or DropOem. More importantly, the relative order of the tables is retained.  It means you can replace only a single table without resorting to DropOem=true and SortedOrder (which implies placing all SSDTs in ACPI/patched). 
 
The matching is based on file name and OemTableID/signature.
 
For SSDTs, the number in the file name is used to find the index in XSDT.  So, a file named SSDT-5.aml in ACPI/patched will replace the 6th SSDT in XSDT (because SSDTs extracted start at SSDT-0.aml).  Additional checking is done with regard to the OEM table ID, to avoid obvious mistakes (eg. placing an SSDT-x.aml that is not a patched SSDT, or mixing up the naming/numbering of the SSDTs in ACPI/patched).
 
With the change to dynamic SSDT extraction file names (above) and this change, it means you can take any SSDT that was extracted, patch it, and place in ACPI/patched, and without making changes to DropOem or DropTables (or using SortedOrder) it will replace the original SSDT with the patched version, retaining SSDT order.  In other words, Clover does the right thing with AutoMerge=true, contrary to what it does by default.
 
This setting also affects how config.plist/ACPI/DSDT/Patches are treated.  Normally, such patches do not apply to SSDTs.  But with AutoMerge=true, such patches are now applied to patched OEM SSDTs in ACPI/patched.  Still, add-on SSDTs (eg. those that didn't match existing tables in XSDT), are not affected by ACPI/DSDT/Patches.  It means that no major surprises happen when you place a patched SSDTs in ACPI/patched.
 
The default of AutoMerge is false, so it is a feature you must explicitly select.
 
Files affected: AcpiPatcher.c, Platform.h, Settings.c, menu.c
 
 
--
 
Add config.plist/ACPI/DSDT/Fixes/FixMutex optioin
 
The ACPI runtime in macOS/OS X does not work correctly with Mutex objects with a non-zero SyncLevel, even when used in a valid scenario.
 
Such Mutex definions must be changed to use SyncLevel 0.
 
The FixMutex feature is an easy way to fix all of them in DSDT.
 
Affected files: FixBiosDsdt.c, Platform.h, Settings.c, menu.c
 
 
Note: That commit calls it "FixMutex_40000000", but a later commit renames the option to "FixMutex".
 
--
 
There are cases in AcpiPatcher.c where a file is loaded using AllocatePool, but freed with FreePages.
Should be FreePool.
 
Also, no need to zero a buffer before loading the file into it (as all bytes in the buffer will be set by file content).
 
Affected files: AcpiPatcher.c, image.c
 
 
--
 
Friendly names for config.plist/ACPI/DSDT/Fixes
 
There is no need to burden the user with the bitmask values for DSDT/Fixes.
Old names are provided for backward compatibility.
Also, made the code table driven.
 
Also, changed (new) names to have consistent capitalization.
 
Affected files: Settings.c
 
My readme describes mappings from old name to new name:
 
--
 
Add with/without injected kexts.  "Cancel hibernate" conditional.
 
Affected files: loader.c
 
 
--
 
Fixed menu navigation regarding space/enter/esc keys
 
Affected files: menu.c
 
 
--
 
Remove hand padding/alignment in Platform.h
 
Easier to maintain.  Let the compiler work for us, not against us.
Also removed unecessary ADDRESS_OF macro (taking the address of a member within instance is not complex)
 
Affected files: Platform.h, menu.c
 
 
--
 
Refactor platformdata.c to use a single array instead of separate arrays
 
Separate arrays leave open the possibility of mistakes...  Single array of struct allows all data for a given SMBIOS model to be seen in one place, and allows easier edits.
 
The new data was generated mostly programatically from original platformdata.c itself.
 
Affected files: Settings.c, platformdata.c
 
 
--
 
malloc/free/realloc implementation in lodepng.c was wrong.
Correct implementation requires storage of the original allocation size for use in realloc.
 
Affected files: loadpng.c
 
 
--
 
Original "embedded" images had hand-coded/hard-coded sizes.  
Not necesary.
The compiler provides sizeof() for this.
Alignment is also possible with __attribute__((__aligned__(8))) 
(no compiler guarantee that one data definition followed by another end up in that order anyway)
 
Affected files: egemb_font.c, scroll_images.c, icns.c, menu.c, libegint.h
 
Related commits:
 
--
 
Add config.plist/ACPI/SSDT/NoDynamicExtract option
 
Dynamic SSDTs confuse users and are amost never needed.  Added an option to config.plist to disable extraction of them via Clover F4 (default is false).
 
Affected files: AcpiPatcher.c, Platform.h, Settings.c
 

Share this post


Link to post
Share on other sites
Advertisement

@RehabMan

Thanks for your work. I will accept all your changes during next week. Let users decide if it good and useful.

 

Great.

Here's another:

 

--

 

Updated config-sample.plist files for friendly ACPI/DSDT/Fixes names; added commented APLF/APSN/PluginType; AutoMerge=true

 

https://github.com/RehabMan/Clover/commit/f80d52218f0c0aa091fe7557e3e3841961d66905

Share this post


Link to post
Share on other sites

It appears many of my changes were not properly/faithfully applied to the sourceforge sources.

 

seems to be the case.

 

I took your AcpiPatcher.c file (https://raw.githubusercontent.com/RehabMan/Clover/master/rEFIt_UEFI/Platform/AcpiPatcher.c) and removed this section:

if (gSettings.NoDynamicExtract) {

    return;

  }

Dropped into 4286 -  it compiled and runs just fine.

 

Main problem with Slice's version of AcpiPatcher.c is this (it is wrong):

 

VOID GetAcpiTablesList()
{
...
  if (Xsdt) {
    // RehabMan: we want to patch only the SSDTs that were original or were loaded and merged
    EntryCount = XsdtOriginalEntryCount;
    //EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
Should be (version on my github):

VOID GetAcpiTablesList()
{
...
  if (Xsdt) {
    EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
Contrary to the comments in the sourceforge version of the file, that change is not one I made (I made no changes to the GetAcpiTablesList function).

 

XsdtOriginalEntryCount is used in PatchAllSSDT in order to patch native SSDTs and patched SSDTS that were merged into existing XDST slots with config.plist/ACPI/DSDT/Patches. We want to patch those SSDTs with ACPI/DSDT/Patches, but not those that are pure add-on SSDTs (added to the end of the XDST) table.

XsdtOriginalEntryCount is not even initialized when GetAcpiTablesList is called.

Its calculation is very carefully placed after dropping tables, but before adding tables from ACPI/patched.

 

I don't know why Slice made this change, but it is likely the cause of the recently reported problems.

 

Edit: It appears the required change was also NOT made to PatchAllSSDT. Sourceforge version of PatchAllSSDT reads:

  EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
But should be (my change):

  // RehabMan: we want to patch only the SSDTs that were original or were loaded and merged
  EntryCount = XsdtOriginalEntryCount;
  //EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
There were also incorrect changes in menu.c, so I would not be surprised if the menus don't work properly when compared to my Clover fork.

Share this post


Link to post
Share on other sites

@all

This thread is for code propositions.

Unrelated posts moved to "General discussion".

 

I want to keep this thread as clean as possible for easy development.


 
 
Main problem with Slice's version of AcpiPatcher.c is this (it is wrong):
 

VOID GetAcpiTablesList()
{
...
  if (Xsdt) {
    // RehabMan: we want to patch only the SSDTs that were original or were loaded and merged
    EntryCount = XsdtOriginalEntryCount;
    //EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
Should be (version on my github):
VOID GetAcpiTablesList()
{
...
  if (Xsdt) {
    EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
Contrary to the comments in the sourceforge version of the file, that change is not one I made (I made no changes to the GetAcpiTablesList function).

XsdtOriginalEntryCount is used in PatchAllSSDT in order to patch native SSDTs and patched SSDTS that were merged into existing XDST slots with config.plist/ACPI/DSDT/Patches. We want to patch those SSDTs with ACPI/DSDT/Patches, but not those that are pure add-on SSDTs (added to the end of the XDST) table.
XsdtOriginalEntryCount is not even initialized when GetAcpiTablesList is called.
Its calculation is very carefully placed after dropping tables, but before adding tables from ACPI/patched.

I don't know why Slice made this change, but it is likely the cause of the recently reported problems.

Edit: It appears the required change was also NOT made to PatchAllSSDT. Sourceforge version of PatchAllSSDT reads:
  EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
But should be (my change):
  // RehabMan: we want to patch only the SSDTs that were original or were loaded and merged
  EntryCount = XsdtOriginalEntryCount;
  //EntryCount = (Xsdt->Header.Length - sizeof (EFI_ACPI_DESCRIPTION_HEADER)) / sizeof(UINT64);
There were also incorrect changes in menu.c, so I would not be surprised if the menus don't work properly when compared to my Clover fork.

 

The work is not finished. Seems your partial commits do not lead to the same codes.

I had to copy platformdata.c as a whole file.

 

I not agree with your comment about Mutex().

Making DSDT for my Dell Latitude E6430 I tested an advice to zero them. NO! This did worst.

MacOS know Mutex and able to use it. My best working DSDT contains non-zero Mutexes.

Anyway the feature is optional. Let it be.

Share this post


Link to post
Share on other sites

The work is not finished. Seems your partial commits do not lead to the same codes.

Not true. You simply applied the changes to the wrong location. My commit for AutoMerge=true was a single/complete commit.

 

When you are done, I will review your work.

 

I had to copy platformdata.c as a whole file.

That is the best way.

 

I not agree with your comment about Mutex().

Making DSDT for my Dell Latitude E6430 I tested an advice to zero them. NO! This did worst.

MacOS know Mutex and able to use it. My best working DSDT contains non-zero Mutexes.

Anyway the feature is optional. Let it be.

Actually, it is well known that Mutex with non-zero SyncLevel *must* be changed to zero.

You probably have other issues in your ACPI code (such as multibyte EC fields).

If you read by battery patching thread, you will find many examples.

 

If you have Mutex objects with non-zero SyncLevel, it is just that the code is not reachable.

Non-zero SyncLevel does not work on macOS/OS X implementation of ACPI.

BTW, the code you have in Settings.c for friendly ACPI/DSDT/Fixes names is wrong.

 

You have:

        Prop = GetProperty (Dict2, "Fixes");
        if (Prop != NULL) {
          UINTN Index;
 //         DBG ("Fixes will override DSDT fix mask %08x!\n", gSettings.FixDsdt);

          if (Prop->type == kTagTypeDict) {
            gSettings.FixDsdt = 0;
          }
          
          for (Index = 0; Index < sizeof(FixesConfig)/sizeof(FixesConfig[0]); Index++) {
            Prop2 = GetProperty(Prop, FixesConfig[Index].newName);
            if (!Prop2 && FixesConfig[Index].oldName) {
              Prop2 = GetProperty(Prop, FixesConfig[Index].oldName);
            }
            if (IsPropertyTrue(Prop2)) {
              gSettings.FixDsdt |= FixesConfig[Index].bitData;
            }
          }
        }
Should be:

        Prop = GetProperty (Dict2, "Fixes");
        if (Prop != NULL) {
          UINTN Index;
 //         DBG ("Fixes will override DSDT fix mask %08x!\n", gSettings.FixDsdt);

          if (Prop->type == kTagTypeDict) {
            gSettings.FixDsdt = 0;
            for (Index = 0; Index < sizeof(FixesConfig)/sizeof(FixesConfig[0]); Index++) {
              Prop2 = GetProperty(Prop, FixesConfig[Index].newName);
              if (!Prop2 && FixesConfig[Index].oldName) {
                Prop2 = GetProperty(Prop, FixesConfig[Index].oldName);
              }
              if (IsPropertyTrue(Prop2)) {
                gSettings.FixDsdt |= FixesConfig[Index].bitData;
              }
            }
          }
        }
One thing I noticed while merging: I will change my Clover fork Settings.c to clear FixDsdt before processing the entries in config.plist/ACPI/DSDT/Fixes such that it behaves as intended if both are specified.

Share this post


Link to post
Share on other sites

Actually, it is well known that Mutex with non-zero SyncLevel *must* be changed to zero.

You probably have other issues in your ACPI code (such as multibyte EC fields).

If you read by battery patching thread, you will find many examples.

 

If you have Mutex objects with non-zero SyncLevel, it is just that the code is not reachable.

Non-zero SyncLevel does not work on macOS/OS X implementation of ACPI.

I know about multibyte EC fields. It is not my case. It seems Dell knows too

            Method (ECR2, 1, NotSerialized)
            {
                Local0 = ECR1 (Arg0)
                Arg0++
                Local1 = (ECR1 (Arg0) << 0x08)
                Local0 += Local1
                Return (Local0)
            }

About Mutex see

            Method (_BST, 0, NotSerialized)  // _BST: Battery Status
            {
                Name (BST0, Package (0x04) {})
                ECG6 (One, BST0)
                Return (BST0) // \_SB_.BAT0._BST.BST0 
            }

The method ECG6 read battery status

        Mutex (ECM1, 0x01)
        Method (ECG6, 2, NotSerialized)
        {
            Acquire (ECM1, 0xFFFF)
            Local2 = ECG2 ()
            ECWB (0x03, Arg0)
            Arg1 [Zero] = ECRB (0x10)
            Local0 = ECRW (0x12)
            If (Local0 == Zero)
            {
                Local0++
            }
            ElseIf (Local2 != Zero)
            {
                If (Local0 & 0x8000)
                {
                    Local0 = Ones
                }
            }
            ElseIf (Local0 & 0x8000)
            {
                Local0 = (Zero - Local0)
                Local0 &= 0xFFFF
            }
            Else
            {
                Local0 = Ones
            }

            Arg1 [One] = Local0
            Local0 = ECRW (0x16)
            Arg1 [0x02] = Local0
            Local0 = ECRW (0x14)
            Arg1 [0x03] = Local0
            Release (ECM1)
        }

It works if Mutex (ECM1, 0x01)

and doesn't work if Mutex (ECM1, 0x00)

I can provide screenshots or any other proof you want.

Share this post


Link to post
Share on other sites

I know about multibyte EC fields. It is not my case. It seems Dell knows too

            Method (ECR2, 1, NotSerialized)
            {
                Local0 = ECR1 (Arg0)
                Arg0++
                Local1 = (ECR1 (Arg0) << 0x08)
                Local0 += Local1
                Return (Local0)
            }

About Mutex see

            Method (_BST, 0, NotSerialized)  // _BST: Battery Status
            {
                Name (BST0, Package (0x04) {})
                ECG6 (One, BST0)
                Return (BST0) // \_SB_.BAT0._BST.BST0 
            }

The method ECG6 read battery status

        Mutex (ECM1, 0x01)
        Method (ECG6, 2, NotSerialized)
        {
            Acquire (ECM1, 0xFFFF)
            Local2 = ECG2 ()
            ECWB (0x03, Arg0)
            Arg1 [Zero] = ECRB (0x10)
            Local0 = ECRW (0x12)
            If (Local0 == Zero)
            {
                Local0++
            }
            ElseIf (Local2 != Zero)
            {
                If (Local0 & 0x8000)
                {
                    Local0 = Ones
                }
            }
            ElseIf (Local0 & 0x8000)
            {
                Local0 = (Zero - Local0)
                Local0 &= 0xFFFF
            }
            Else
            {
                Local0 = Ones
            }

            Arg1 [One] = Local0
            Local0 = ECRW (0x16)
            Arg1 [0x02] = Local0
            Local0 = ECRW (0x14)
            Arg1 [0x03] = Local0
            Release (ECM1)
        }

It works if Mutex (ECM1, 0x01)

and doesn't work if Mutex (ECM1, 0x00)

I can provide screenshots or any other proof you want.

Changing SyncLevel only in Mutex() is not enough. Acquire() and Release() must be adjusted as well.

Share this post


Link to post
Share on other sites

It works if Mutex (ECM1, 0x01)

and doesn't work if Mutex (ECM1, 0x00)

I can provide screenshots or any other proof you want.

I think you have something else going on.

But FixMutex is available for those that need it.

And if you don't need it, like any other Clover fix, simply don't use it.

 

Someone really needs to fix the sourceforge version of AcpiPatcher.c.

The code I see checked into the project is still very wrong (as I fully described previously).

 

Changing SyncLevel only in Mutex() is not enough. Acquire() and Release() must be adjusted as well.

Not true. The Acquire/Release code in Slice's snippet is valid.

Share this post


Link to post
Share on other sites

@all

This thread is for code propositions.

Unrelated posts moved to "General discussion".

 

I want to keep this thread as clean as possible for easy development.

 

Is it possible to change permission on a thread/topic to only allow coders, developers and the various forms of moderators/admin? Because I like the idea of discussion threads for random clover talk, clover bug/issue/request reports, and clover development (which is only locked to developers). I think that most users see this as a place to report problems or request feaures, which because of the thread title seems correct. So either we should create a separate developer only thread about development, or rename this thread to development only and create another separate bug/issue/request thread. No?

Share this post


Link to post
Share on other sites

Is it possible to change permission on a thread/topic to only allow coders, developers and the various forms of moderators/admin? Because I like the idea of discussion threads for random clover talk, clover bug/issue/request reports, and clover development (which is only locked to developers). I think that most users see this as a place to report problems or request feaures, which because of the thread title seems correct. So either we should create a separate developer only thread about development, or rename this thread to development only and create another separate bug/issue/request thread. No?

I will take a look to accomplish this request...

 

Maybe a permanently looked topic or dedicaded subforum.

 

ErmaC

Share this post


Link to post
Share on other sites

@Slice

 

Those changes in r4289 commit look like they should fix the ACPI problems (and others), so thanks for correcting the code to better match my original.

 

FYI, I will probably have no chance to test/merge/diff/review/etc until early next week sometime.

Share this post


Link to post
Share on other sites

Some stuff that may interest detail menu:

 

There's not really much you can do but I would like to be able to boot into safe mode (and variant modes) and resume directly from clover, but this requires instead of using \EFI\Microsoft\Boot\bootmgfw.efi using the OS volume's winload.efi or winresume.efi in the System32 folder of the Windows folder. However, apparently both of these folders could be named differently, and you'd have to parse the windows BCD to determine where to actually load those from. Also determining whether to resume or not, no idea how that happens in windows. In fact you can't even skip bootmgfw.efi, I tried to decompile, UefiDumpCalls, and figure out what it was doing to be able to load those but it doesn't appear to really do much and I tried to copy what it did but it did not work.... Also when resuming from firmware, I see a little circle spin for like a second, maybe two, and I get login screen, login, everything is still there. From clover, I get a really long time with spinning circle, then separate completely black screen with spinning circle, then login screen, login, nothing is there. So what is going on that's causing it to fail?

 

There have been many people asking about netboot for not just windows but pretty much every OS. UEFI spec now includes Wifi and supplicant among other stuff, that make it more plausible now. I just have no idea how we would implement it. Since there would be no local installation, the only thing could be that the user would have to create a custom entry, but that would mean modifying that to work remotely....

 
EDIT: Or we could add another tool, disabled by default that you can enable, to netboot. That might be the best approach.
 
I know some people have been asking about patching/dropping tables and injecting others, more than the limited amount we allow now. I'm not sure what purpose this accomplishes in windows, most of those tables were designed and tested only with windows, so I can only imagine that there is a bug in one of the tables or they wish to change p-states/c-states? I'm not sure what else there could be...

 

Some stuff that has to do with windows and clover in general:

 

Some method to be able to choose the boot disk from any OS to just restart to once, like if you have everything set to just start immediately with no interaction or timeout to macOS. The only way I could see this is if we stuck another little plist on a partition just like nvram emulation, and searched, parsed, then removed it. Any script or executable could be made for any OS then to change the startup disk for just the next boot, we could actually probably have it change the default too.

 

There appears to be some sort of issue when chainloading windows through clover, I believe it is related to memory or something because I have issues if not booted directly from my firmware. Which is weird because nothing should be happening, only a few ACPI tables might be injected but I currently am not injecting. Although I was injecting my SLIC back on my old mobo because I had flashed a leaked beta firmware that had no branding and never had a problem always booting through clover. Maybe I just didn't notice and problems I was having, I was blaming on windows. Like this .mkv bug where I couldn't play any .mkv videos in any player until I got windows 10, they just froze and looped a fraction of the beginning. No way to do anything but completely power off, restarting sent into infinite boot loop (that may have been the firmware though, it did that often). I'm not sure what and how much we can actually affect because of the windows boot manager, it seems to want things in an exact way. The UEFI spec was actually written around exactly what microsoft wanted, down to the exact modes and frame buffers the graphics output protocol HAS to support to be UEFI compliant. As well as safe boot, with only microsoft keys in the default key dbs.

 

I'm sure there's more but I can't think of anything off the top of my head. It may be a question to ask users.

Share this post


Link to post
Share on other sites
to developers
some part remains for reset nvram.
basic reset nvram features is working.

 

1. consider more reset keys. i just added some keys. 

https://sourceforge.net/p/cloverefiboot/code/4299/tree//rEFIt_UEFI/Platform/Nvram.c#l45

https://sourceforge.net/p/cloverefiboot/code/4299/tree/rEFIt_UEFI/Platform/Platform.h#l624

 

2. translation (en/kr were done)

https://sourceforge.net/p/cloverefiboot/code/4299/tree//rEFIt_UEFI/refit/menu.c#l1356

 

3. now can remove nvram file for reset on ESP(EFI) partition, but on APFS/HFS+, can't remove. show message "block blah blah"

actually, DeleteFile is work but. still there is nvram file on mac partition(APFS/HFS+). i tested to add nvram.plist as manual.

clover always find nvram.plist when booting on emulvariables. if there is hibernation mode info in nvram.plist on mac partition without nvram file on ESP.

we can face with problem if not support hibernation on user system. link

need to remove nvram.plist on all partition for reset. but now, only works on ESP. i don't have idea to remove nvram.plist on APFS/HFS+. need to improve this part.

https://sourceforge.net/p/cloverefiboot/code/4299/tree//rEFIt_UEFI/Platform/Nvram.c#l223

 

thanks in advance.

Share this post


Link to post
Share on other sites

To delete a file from HFS+ partition we have to rewrite driver VBoxHFS.efi to be RW driver while it is RO driver for now.

But I think you should not delete this file. You have just not read it.

Share this post


Link to post
Share on other sites

No, he wants to delete this file because it contains erroneous information and is not allowing for boot. You can't delete from an HFS+ during boot like Slice said, that's why you should not install directly to a HFS+ volume. You should always install to the ESP, even legacy booting. I think maybe this should be a change made to the installer package. Since installing to an MBR disk requires patching the macOS installer anyway. Plus the problem also lies in why EmuVariable is not allowing for deletion of variables, that's the real solution. Sherlocks method is just work around, as clearing these variables will write out correct nvram.plist next logout.

Share this post


Link to post
Share on other sites

No, he wants to delete this file because it contains erroneous information and is not allowing for boot. You can't delete from an HFS+ during boot like Slice said, that's why you should not install directly to a HFS+ volume. You should always install to the ESP, even legacy booting. I think maybe this should be a change made to the installer package. Since installing to an MBR disk requires patching the macOS installer anyway. Plus the problem also lies in why EmuVariable is not allowing for deletion of variables, that's the real solution. Sherlocks method is just work around, as clearing these variables will write out correct nvram.plist next logout.

Usually nvram.plist is stored into EFI partition where it can be easy deleted.

But there is Lilu+HibernationFixup who can save nvram.plist only on root folder which is HFS+ or even APFS. So Sherlocks method is not compatible with this plugin.

 

I am still not understading what is the reason to reset NVRAM? Can you provide me full report showing the issue? May be we must cure the reason and not the sequence?

 

May be we can create HFS+ RW driver but the problem much harder for APFS.

Share this post


Link to post
Share on other sites

Usually nvram.plist is stored into EFI partition where it can be easy deleted.

But there is Lilu+HibernationFixup who can save nvram.plist only on root folder which is HFS+ or even APFS. So Sherlocks method is not compatible with this plugin.

 

I am still not understading what is the reason to reset NVRAM? Can you provide me full report showing the issue? May be we must cure the reason and not the sequence?

 

May be we can create HFS+ RW driver but the problem much harder for APFS.

i reported this

http://www.insanelymac.com/forum/topic/321371-lilu-—-kext-and-process-patcher/?p=2534000

 

if there is nvram.plist with hibernation info on root which is HFS+/AFPS, happen instant reboot.

http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page-768?do=findComment&comment=2532230

here is his log

http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/?p=2532298

my log.

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

 

i think that there is not best for nvram.plist with hibernation info in root which is apfs/hfs+. it causes issue on some system. i tested before. just confirm that hibernationfixup works or not

in my case, specially, I can not take any action. it's critical issue until format apfs disk(nvram.plist) from windows. My system always happen instant reboot when enter any osx disk(usb installer/HS/recovery/everything related in mac).

 

So, if nvram has hibernation info on ESP, if user system can't use hibernation mode from test, just press f11, then clover remove nvram.plist. no need to extra behavior.

to avoid instant reboot after shortly shown osxaptiofix message. example in windows, mount ESP, remove nvram.plist to reset.

 

sorry for my bad english.

 

EDIT1.

i dont know MBR case and legacy for hibernation.

I'm considered UEFI+GPT.

Share this post


Link to post
Share on other sites

Clover can't remove nvram.plist produced by HibernationFixup plugin. 

The plugin can't write nvram.plist anywhere but in root.

Understand?


Meanwhile when you have a problem after hibernation then you have to choose Details Menu -> Cancel Hibernation

Share this post


Link to post
Share on other sites

Clover can't remove nvram.plist produced by HibernationFixup plugin. 

The plugin can't write nvram.plist anywhere but in root.

Understand?

Meanwhile when you have a problem after hibernation then you have to choose Details Menu -> Cancel Hibernation

 

now, i understand. thanks.

can we avoid this issue if clover read nvram.plist witih hibernation info on not supported hibernation system? any trick or etc?

one way, don't use EmuVariableUefi. then clover not read nvram.plist in mac installed partition. but my laptop should use EmuVariableUefi to avoid AppleEFINVRAM time error.

 

Meanwhile when you have a problem after hibernation then you have to choose Details Menu -> Cancel Hibernation

-> already i tried it and all in GUI. but no luck. still happen instant reboot. i don't know why. 

 

also i don't see there is no "hibernated" on Macintosh HD in my log and GUI

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

0:588 0:000 - [07]: 'Macintosh HD'

0:619 0:031 AddLoaderEntry for Volume Name=Macintosh HD

0:637 0:017 Check if volume Is Hibernated:

0:637 0:000 Check sleep image 'by signature':

0:663 0:025 read prefs \Library\Preferences\com.apple.PowerManagement.plist status=Success

0:663 0:000 using default sleep image name = \private\var\vm\sleepimage

0:674 0:011 sleepimage not found -> Not Found

0:674 0:000 hibernated: no - sign

 

i remember hibernationfixup with "-hbfx-dump-nvram" makes nvram dump in ESP long time ago. not remember that time. i wrote it before in clover thread.

Maybe I'm wrong or not. I can not say I'm sure.

Share this post


Link to post
Share on other sites

No, hibernationfixup never able to write to other volume then it is.

 

I know that EmuVariable can't be dropped. Some systems will not boot. My computer #1 is among them.

 

May be set HibernationFixup=NO in Clover's config.plist? And set it in priority on automatic check!

I see no reason why you can't boot if boot0082 is present. It used ONLY for hibernation.

And if we detect that hibernation is disabled

0:674 0:000 hibernated: no - sign

then we can safely delete all hibernations variables: boot0082 , boot-image, boot-switch-var etc. As well delete 0082 from boot-order and set boot-next to 0000.

All this happen with hibernation except your case and I think we can do this with ordinary boot.

Share this post


Link to post
Share on other sites

No, hibernationfixup never able to write to other volume then it is.

 

I know that EmuVariable can't be dropped. Some systems will not boot. My computer #1 is among them.

 

May be set HibernationFixup=NO in Clover's config.plist? And set it in priority on automatic check!

I see no reason why you can't boot if boot0082 is present. It used ONLY for hibernation.

And if we detect that hibernation is disabled

0:674 0:000 hibernated: no - sign

then we can safely delete all hibernations variables: boot0082 , boot-image, boot-switch-var etc. As well delete 0082 from boot-order and set boot-next to 0000.

All this happen with hibernation except your case and I think we can do this with ordinary boot.

 

i didn't have HibernationFixup=NO and any hibernation keys in config.plist at that time.

anyways, in my system, seems I would rather not use hibernationfixup.

 

today, i tested -f(without caches option) on snow leopard.

boot-args -f, actually not works. not operation this part from "-f". spacbar option(-f) is not work too in GUI

https://sourceforge.net/p/cloverefiboot/code/4301/tree/rEFIt_UEFI/Platform/Settings.c#l7131

 

clover first load \\System\\Library\\Caches\\com.apple.kext.caches\\Startup\\Extensions.mkext file in 10.6.8 when booting.

snow leopard installer, there is only \\System\\Library\\Caches\\com.apple.kext.caches\\Startup\\Extensions.mkext.

so clover can't patch binary patch. example AppleICPUPM in config.plist. because of mkext file. so always get its kext panic.

i can't pass this. i don't know why clover read mkext file.

 

so i seted 

<key>SystemParameters</key>

<dict>

<key>NoCaches</key>

<true/>

</dict>

without "-f"

 

then, clover block to load \\System\\Library\\Caches\\com.apple.kext.caches\\Startup\\Extensions.mkext. then i can get boot without kp.

spent some times for message "........................."(nocache is working).

 

then after setting snowleopard, i have to rebuild cache to use clover kexttopatch(AppleICPUPM) and get fastboot by using kernelcache. then 

<key>NoCaches</key>

<false/>

post-980913-0-09144400-1510676939_thumb.png

 

if there is 2 files(mkext, kernelcache file), clover read kernelcache file except mkext.

i don't know why if there are 2 files, first read kernelcache. i didn't debug this.

 

as result, "-f" actually not work to avoid kernelcache or operation Blacklist

need to improve if using -f flag or make nocache option to enable in GUI.

if you want snow's boot.efi file, i will upload.

 

summary.

- "-f" not work. if user use "-f" flag, clover have to operate blacklist option.

- 10.6 installation in clover, first, always use nocache option. because there is only mkext file in Startup folder.

  there is no default kernelcache file. then rebuild cache file, then disable nocache option. then can use normal macos like 10.7~10.13

 

sorry for bad english.

 

EDIT1.

"\\System\\Library\\Caches\\com.apple.kext.caches\\Startup\\kernelcache-******

in snow leopard, after rebuild cache, There always is a specific name after kernelcache above pic. This is given randomly..

if there is 2files(mkext,kernelcache), then user use nocache option, seems clover now can't block kernelcache-****file.

seems need to improve blacklist part for snow leopard.

 

thanks in advance.

Share this post


Link to post
Share on other sites

All would be fine except EmuVariable doesn't appear to be able to delete specific (maybe any?) variables. Sherlocks showed that in the general discussion. I don't know if cancel hibernate will work since he didn't appear able to delete the variables necessary. I see no problem having a reset for variables that we mostly set, or are set by macOS. It is helpful if you want to reset to original state because you did something stupid. As for the adding randomness to the end of a path, just check the beginning matches up to kernelcache, the rest is irrelevant, don't load any of them since trying to skip them anyway. As for the fixup, why would a kext not have access to other volumes? Are they all unmounted? It's being hibernated, there shouldn't really be a change, why would a kext not be able to gain access to the EFI volume?

 

EDIT: You can use the collation protocol's meta match method, to block wildcard paths, and everyone except one person knows -f does not work in clover....

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By fusion71au
      Clover r4747 ISO compiled with GCC and minimal config.plist compatible for use in VMWare Workstation.
       
      Tested with unlocked Workstation 15 running OSX 10.9 -->10.14 guest in Windows X64 host.
       
      Installation
      1. Download and unzip "EFI_Clover_r4747 for VMware.zip". Mount Clover-v2.4k-4747-X64 by double clicking on it.
      2. Mount your VM's EFI System Partition eg in terminal
      sudo diskutil mount disk0s1   3. Copy EFI folder from step 1 into the EFI partition
      4. Shutdown the VM, add bios.bootDelay = "3000" to your VM's vmx file
      5. Reboot your VM, press <F2> to access the VMware Boot Manager and add CLOVERX64.efi to the boot menu.
       
      Substitute your own unique and valid MLB and ROM variables in the /EFI/CLOVER/config.plist (Rt Variables section) to activate iMessage/Facetime on your VM.
    • By superdooper71
      Hi all,
      I hope someone can help me as I am struggling with this bloody installation.
      I am running on several problems that I can't face : (
       
      First of all my config:
      Mobo: ASROCK H81M-DGS R2
      CPU: Intel Xeon E3-1220 v3 @3.10ghz
      RAM: 16gb DDR3 1600Mhz
      SSD: Crucial BX100 120Gb SSD
      Monitor: Hp 27w Hdmi
       
      POST Installation CLOVER
       
      Current Issues:
      • System will not boot (clover boot loader do not shows up) from SSD
         - System boot only with USB stick
      • Screen Resolution is only 1024x768
      • Monitor recognised as 17" instead of 24"
      • Monitor identified as secondary
      • Grafic Card Geforce GT710 shows 0 Mb
      • System info do not match Config.plistin Clover
       
      I attach screenshot of System Info, Kext in Clover, Resolution etc etc.
       
      Please can someonhelp me?
       
      Please can you tell me what is the Clover Parameter to activate when installing Clover  (Clover_v2.4k_r4722) into Boot Disk?
       
      I hope someone can help me out of this little troble: )
       
      Cheers
      Franco
       
      system info.tiff
      kext.tiff
      resolution.tiff
      system.tiff
      config.plist
    • By gengik84
      Ciro82==>>Thanks
      Uno dei tre Requisiti:
      Hack funzionante Mac vero Macchina virtuale Impostazioni Bios per il boot:
      Cercate una voce  del tipo “Sata Mode”e settatela  in AHCI
      Secure Boot: disabilitare o altri sistemi operativi
      CSM: UEFI o LEGACY, oppure a secondo del tipo di installazione
      VT-x / VT-d disable
      *Nota: Secure boot e csm valido solo per bios UEFI
      Materiale Occorrente 
      "OS X (Versione App.Store)”
      USB 8GB  *nota: nel caso di usb superiori dovrà essere partizionata, in modo da avere una partizione su cui "lavoreremo,di questa dimensione
      ShowAllfiles 
      kext Wizard 
      Bootloader Clover_2.3k_r xxx:                   http: //sourceforge.n.../cloverefiboot/
      Clover Configurator:                                    http: //mackie100proj...a.org/download/
      FakeSmc.kext:                                            https://github.com/kozlek/HWSensors/releases
      In allegato,a fondo pagina troverete un "pacchetto" contenente : ShowAllfiles, Kext Wizard, FakeSmc.kext: 
      App alternative:
      ESP Mounter Pro: per montare la partizione EFI
      Vi illustrerò tre metodi per creare la usb, ma sono ben distinti… quindi usatene soltanto uno
      Metodo 1: “Install Mac_OS_X.command” Metodo 2: “Create Install Media di Apple” Metodo 3:  Metodo Manuale Alla fine delle preparazione dell’installer, tutti i metodi necessitano l’installazione del Bootloader Clover sulla a vostra USB.
      “CONDIZIONI OBBLIGATORIE”
      PUNTO 1: che la vostra usb sia stata preventivamente nominata USB (caratteri maiuscoli) Tabella di partizione GUID e la formattazione in  Mac esteso Journaled.
      PUNTO 2: che l’installer di OSX si trovi in Applicazioni
      Utility Disco 
      Selezionate la pendrive, andate su “partizione”, selezionate “1 partizione”, impostate Mac OS esteso journaled e date il nome USB, poi in basso cliccate su opzioni e scegliete Tabella partizione (GUID), poi “applica”.
      Immagine 
      Riporto nuovamente l’operazione sopra citata adoperando dal nuovo Utility Disco introdotto su El Capitan.
      Rimane ovviamente invariato nome della usb in ==>> USB (maiuscolo), la formattazione in Mac esteso Journaled e sia la mappa partizione in GUID
      Da utility disco selezionate la usb, cliccate su inizializza.
      dal menù a tendina scegliete la relative impostazioni
      Immagine  
      Procedura effettua da High Sierra è la stessa della precedente, l'unica attenzione e operazione da aggiungere in primis  è cliccare nel menù a tendina in alto sulla sinistra di utility disco e selezionare "mostra tutti i dispositivi"
      Immagine 
       
      =====================
        METODO 1: "Install_Mac_OS_X.Command" Lo script che trovate allegato in fondo alla guida permette la creazione dell’installer in maniera automatica
      Include la possibilità di scelta di tre versioni di osx
      Yosemite El Capitan Sierra Il risultato finale è come quello del metodo "manuale" descritto nella guida, per cui l'installazione avverrà in un solo passaggio, non in due come con il metodo createinstallmedia. 
      Offre inoltre la possibilità di inserire un kernel patchato, utile, per esempio, per chi usa AMD.
      Rimane invariato il nome dato alla usb in USB, mappa partizione e tipo di formattazione
      Se la vostra usb non sarà rinominata nel modo corretto, verrete avvisati dal terminale, quindi non dovrete far altro che apportare la relativa modifica e rilanciare nuovamente lo script
      Esempio
      ===========================
      Metodo 2 
      L'intento è quello di usare la procedura fornitaci direttamente da Apple, "createinstallmedia", introdotta  con Mavericks. 
      Tale metodo prevede l’uso del terminale che via via se ne sta perdendo il “valore e l’uso”
      Inizialmente per i neofiti potrà sembrare problematico ma alla fine non è così.
      Durante il post installazione alcune operazioni ne richiedono l’ uso.
      Perciò mi sono chiesto perchè, qualora uno volesse, non far conoscere da subito un po’ questo “strumento”???
      Per favorirvi vi ho allegato i comandi già  “pronti”, i quali li potrete copiare ed incollare sul terminale.
      A questo punto aprite il terminale, copiate ed incollate il comando sottostante e premete invio, digitate la vostra password e premete nuovamente invio.
      Comando per creare USB con Yosemite:
      sudo /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia --volume /Volumes/USB --applicationpath /Applications/Install\ OS\ X\ Yosemite.app --nointeraction  
      Comando per creare USB con El Capitan
      sudo /Applications/Install\ OS\ X\ El\ Capitan.app/Contents/Resources/createinstallmedia --volume /Volumes/USB --applicationpath /Applications/Install\ OS\ X\ El\ Capitan.app --nointeraction Comando per creare USB con Sierra 
      sudo /Applications/Install\ macOS\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/USB --applicationpath /Applications/Install\ macOS\ Sierra.app/ --nointeraction Per creare USB con Hight Sierra o Mojave usate --> C_I_M (aggiornato per 10.14)
       
      Funziona con il drag & drop sul terminale, in questo caso non vi è necessità che la usb sia nominata in un determinato modo ed essendo basato su create install media ovviamente funziona da 10.9 a 10.14.... 
      BENE…IL PROCESSO DI CREAZIONE E’ INIZIATO…
      AVREMO CIRCA 20/30 MINUTI DI TEMPO LIBERO A CUI DEDICARSI A CIO’ CHE VOGLIAMO………………………………………..  
      COLGO L’OCCASIONE PER FARVI NOTARE LA VELOCITA’ E LA SICUREZZA DI QUESTO METODO
      CONFRONTATE QUESTO CON IL TERZO METODO E NOTERETE CHE CON UN SOLO PASSAGGIO, OSSIA IL COMANDO DATO AL TERMINALE, FACCIAMO IN UNA SINGOLA OPERAZIONE TUTTI I VARI STEP DESCRITTI SULL’ ALTRO METODO.
      DETTO QUESTO, MOLTO IMPORTANTE E’ SOTTOLINEARE CHE COSI’ FACENDO EVITEREMO ERRORI  DI DISTRAZIONE RIGUARDO AI PASSAGGI O FRAINTENDIMENTI.
      Immagine 
      Potete adesso passare ad installare il bootloader Clover sulla vostra usb.
      *NOTA*:
      Avendo usato questo metodo l'installazione si dividerà in due fasi, perciò dopo il primo riavvio e necessario far partire nuovamente l'installer, selezionare lo stesso disco senza formattarlo.
      Finita questa ulteriore fase , l'installazione sarà terminata
      =========================
      METODO "MANUALE"....  (lascio per futura memoria-Compatibile fino a 10.12)
      ==========================
      Bootloader
      **Nota:** Installazione in UEFI  dipenderà dalla scheda madre in vostro possesso, quindi se non supporta tale opzione , il bootloader dovrà essere installato in  modalità Legacy.
       Vi invito, qualora non sapeste questa informazione, a recarvi nel sito ufficiale del produttore e controllare le informazioni a riguardo
      Fatto questo dobbiamo installare  Clover sulla usb.
      A seconda del tipo di Bios o al tipo di installazione che vogliamo fare UEFI o Legacy avremo ovviamente configurazioni diverse in questa fase.
      Lanciate il pkg.
      Immagine 

       
      Cambiate la destinazione di installazione ad USB oppure Install Mac_OS_X (a secondo del tipo di creazione eseguita)
      Successivamente clicchiamo su "Ad Hoc"
      Per Installazione UEFI
      Mettete i flag   : Installazione solo per avvio UEFI
                               : installare Clover nella ESP
                               : Driver64UEFI  selezionate OsxAptioFixDrv-64
                             *  :Se nel vostro sistema è presente una scheda grafica (discreta) della serie 9xx nVidia selezionate OsxAptioFix2Drv-64 al posto di  OsxAptioFixDrv-64 *
      ** OsxAptioFix2Drv :E' necessario per poter impostare CsrActiveConfig= 0x3 **
      ***OsxAptioFix3Drv oppure AptioMemory --> (consigliato) devono essere usati su hardware Skylake o successivi perché permettono alla nvram di lavorare correttamente
           (mi raccomando o uno o l'altro)
      Proseguite con l’installazione.
      Immagine 
      ** Ricordate che avrete accesso a questa cartella dopo aver montato la partizione EFI**
      ===========================
      Per installazione Legacy
      Immagine 
      ===========================
      Impostazione per config.plist:
      Con clover configurator “montate” la partizione EFI della usb.
      1) Per fare questo nel menù di sinistra, cliccate su “Mount EFI”
      2) individuate la partizione relativa alla vostra usb, a questo punto montiamo la relativa partizione EFI  selezionando l’apposito pulsante “Mount Partition”
      Immagine 
      3) Successivamente cliccate su “Open Partition”.. recatevi in EFI/Clover ed aprite il config.plist
      4) Sezione ACPI: Disabilitate tutti i fix sia del menù 1 che del menù 2
      Immagine 
      5) Sezione BOOT: Sole se si sta installando Yosemite mettete il flag su kext-dev-mode=1
      Immagine 
      6) Sezione RT Variables: Se si sta installando El Capitan oppure Sierra, aggiungere i valori: BooterConfig= 0x28, CsrActiveConfig= 0x67
      Immagine 
      7) Sezione System Parameters: Su inject kext mettete YES
      Immagine 
      ===========================
      Nota: Su El Capitan, è stato introdotto SIP (System Integrity Protection)
      Info:
      ===========================
      Recatevi in EFI/Clover/kext/10.x 
      X= alla versione di osx che state installando. Per esempio se installerete Yosemite dovrete recarvi nella cartella 10.10, con El Capitan in 10.11….ecc
      Se non ci fosse tale cartella, createla e nominatela voi a “modo”.
      Copiatevi all’interno FakeSmc.kext
      *Nota se venite già da altre vostre configurazioni, oltre kext sopra citato ,potete mettere gli altri necessari per il vostro hardware
      Stessa cosa se avete DSDT e/o SSDT potete copiarli in EFI/Clover/Acpi/Patched
      Immagine 
      
      Per High Sierra:
      Scaricare il driver apfs.efi a fine guida, collocarlo:
          --> EFI/clover/Driver64UEFI se stiamo usando UEFI
      --> EFI/Clover/Driver64 se stiamo usando Legacy
       
      Per chi volesse continuare ad usare HFS vi rimando a questo post:
        Come installare High Sierra in HFS direttamente dalla usb  
      Utenti Laptop:  Nel 99% è obbligatorio disattivare la grafica discreta Nvidia/Amd per installare questo nuovo osx
                                     Quindi aggiungete --> SSDT-Disable_DGPU.aml.zip
                                     in EFI/Clover/acpi/Patched della usb
      --------------------------------------------------------------------
      Per Mojave:
      Scaricare il driver apfs.efi per 10.14 a fine guida, collocarlo:
          --> EFI/clover/Driver64UEFI se stiamo usando UEFI
      --> EFI/Clover/Driver64 se stiamo usando Legacy
      Versione di clover non antecedente a V_4015
      Volete usare HFS?
      E' possibile fare un installazione diretta su altro disco o partizione, nel caso può essere usato anche per effettuare aggiornamenti...
      nel caso guardate...
       Mojave in HFS 
       Oppure direttamente da usb  
       
      Fatto questo avrete la vostra USB bootable per installare OSX.
      ………Non scordatevi Fakesmc.kext da mettere nella relativa cartella…. senza il quale non farete mai il Boot......
      *NOTA: se usato il terminale per la creazione della usb, l'installazione si dividerà in due fasi, perciò dopo il primo riavvio e necessario far partire nuovamente l'installer, selezionare lo stesso disco senza formattarlo.
      Finita questa ulteriore fase , l'installazione sarà terminata
      **NOTA** Se avete processori Broadwell,Skylake o Kabylake...usate FakeSmc.kext e relativi sensors che trovate all'interno del secondo pacchetto.. (potete usarlo anche sui precedenti senza problemi, essendo una versione più aggiornata ha ulteriore supporto per le cpu più recenti)
      Update: Fakesmc e sensors versione 6.26
      Post installazione... post #2           
       Buon Hack….. 
      Aggiornamento:Install_Mac_OS_X.command.zip (compatibile da 10.10 a 10.12)
      le info le trovate a questo post
      Ringrazio @Ciro82 che mi ha aiutato nel preparare questa guida.
      Pacchetto.zip
      Pacchetto-2.zip
      apfs.efi-10.13-NoLog.zip
      Pacchetto-Fake+Sensors 6.26.1440.zip
      apfs.efi-10.13.1-No_LOG.zip
      apfs.efi-10.13.2_No_Log.zip
      apfs.efi-10.13.3-No_Log.zip
      apfs.efi-10.13.4-No_Log.zip
      apfs.efi-10.13.5_No_Log.zip
      C_I_M.zip
       
      apfs.efi-10.14-beta1_No_Log.zip






    • By shmn
      Hi, I have been trying to follow @RehabMan 's guide to disable my dGPU ( https://www.tonymacx86.com/threads/guide-disabling-discrete-graphics-in-dual-gpu-laptops.163772/ ) for two days now, but haven't found a way to disable my 1080 Ti on my desktop Clover hack.

      I have a dual-boot (Win/Mac) machine on a Z370 Aorus 7. Since there's no nvidia drivers for Mojave atm, I want to stick with the iGPU under Mac, but still use the 1080 Ti under Win.

      The hack boots just fine when I remove the 1080 Ti, if it's plugged in via PCIe I get a kernel panic.
      Please find attached my ACPI folder, my clover config.plist and the kernel panic details.

      Might there even be a less hacky way than patching these ACPI files? I appreciate any kind of support! Thanks!
      ACPI.zip
      config.plist

      systemReport.txt
    • By Alexandru
      Hello InsanelyMacForum,
       
      I managed to boot into Mac OS Sierra with my Intel Core 2 Duo, Nvidia 9400 GT and 4 GB of Ram machine, got internet and sound working, but the issue appears when I boot with Nvidia Web Driver. I get these acid colours, but Graphics Acceleration is working fine. I tried to inject EDID from my display, but no results as well. Would be really grateful if someone could provide some help. Thank you!

×