Jump to content
tonyx86

Catalina on Dell Latitude E6410 (Nvidia Graphics) With Working Sleep

143 posts in this topic

Recommended Posts

After updating to 10.15.3, along with updating the EFI, I'm still unable to use my modular bay drive. As stated before,

  1. macOS reports disk I/O errors during verbose boot
  2. Finder claims it's unable to recognize the disk and asks to initialize it
  3. Disk Utility fails to erase the disk (see attached screenshot)
  4. After a while with the drive plugged in, the screen goes white. Sometimes the laptop will automatically reboot from here; other times I'll need to manually force it to power off and on again

I've generated several debug reports of this issue, and linked to them in this post.

What I find bizarre about this issue is that it doesn't occur in literally any other circumstance:

  • Connecting the bay drive to my desktop (through a frankly horrifying configuration), which is also a hackintosh, works fine
  • Accessing the bay drive within another OS works fine (e.g. Linux)
  • Even Clover properly recognizes the partitions on the disk in the drive
  • The stock DVD bay drive works fine in macOS

I've tried multiple HDDs in the drive; the problem is the same amongst all of them.

@tonyx86 - you say you have a modular bay drive that works with macOS? I wonder if there's an internal difference between our drives. If you wouldn't mind, could you take photos of the internals of your drive? I've attached some of my own to this post.

Screen Shot 2020-02-23 at 12.46.01 PM.png

IMG_20200124_073638.jpg

IMG_20200124_073648.jpg

Share this post


Link to post
Share on other sites
Advertisement

@unilock I originally thought SATA 3 vs SATA 2 might be an issue, but my adapter also indicates SATA 3 like yours.  Pix are attached.

 

Also, there's a switch on the side that I've never played with.  I see your board has one, too.  Does the switch position matter?  I don't know what it does.

thumbnail_IMG_0941.jpg

thumbnail_IMG_0942.jpg

thumbnail_IMG_0943.jpg

Edited by tonyx86

Share this post


Link to post
Share on other sites

@tonyx86

From the casing, it looks like we have the same model of modular bay drive. Though, based off what it says on the circuit board, you seem to have a slightly newer revision than I do. But I can't see any visual differences, other than that yours has a disk activity indicator LED soldered on while mine does not. If you want to disassemble the drive further, there are screws under the stickers on the side where you would insert the HDD (one on the white/black transition line under the cylinder in the top-left corner, one on the text under the book with the "i" in it in the bottom-left corner, and one on the left side of the cylinder in the bottom-right corner).

The switch enables/disables the diags pin, whatever that means. The ON state is towards the laptop-size SATA connector; the OFF state is towards the full-size SATA connector. The state of the switch doesn't seem to have any effect my problem.

I don't think a difference in SATA speed (SATA2 vs. SATA3) is part of the issue, as I believe the bay drive acts only as a passthrough between SATA port standards.

Share this post


Link to post
Share on other sites

@unilock I'm not sure that further disassembly of my aux bay adapter is going to reveal anything helpful.  I was comparing my IORegistry  to the one you last posted and quickly realized that your last debug files do not reflect your current installation.  Could you please post a new set of debug files (generated with black.dragon74's gen_debug tool) for your 10.15.3 installation with the aux bay populated with your data drive (one set of debug files)?  Please make sure that you're running the same file versions as those posted in Post #1 (including the same FakeSMC) as file differences generate different IORegistry attributes that complicate the comparison for me.

 

This will make the comparison easier for me.  Also, I imagine you have at least one BIOS config that is different from the config I specified in Post #1 (e.g. enabling your cellular modem).  Can you provide a list of the differences between your BIOS config and the BIOS config that I have recommended in Post #1?

 

Short of the detailed comparisons of the configs which I'm willing to do after seeing your updated post, I'm not sure what else to consider except for a new aux bay adapter.

 

EDIT: One other thing... When I was examining your last-posted IORegistry dump (I still need an updated set of debug files as explained earlier in this post), I noticed that your IORegistry (as viewed with IORegistryExplorer) has at least one device that I don't (e.g. RP04@1C,3).  It's possible that the presence of other hardware in your laptop (like the cellular modem) requires additional ports to be active, so your BIOS config is different and thus you need a slightly different DSDT.  You may need to try:

 

  1. My DSDT attached to Post #1 in this thread emulates Linux for running macOS.  Attached is a DSDT that emulates Win7 instead of Linux (see more details about this in the Mojave thread).  Try this DSDT to see if this helps.
  2. *** Deleted - no longer believe that you need to extract / patch your own DSDT.

DSDT.zip

Edited by tonyx86
deleted DSDT extract / patch suggestion

Share this post


Link to post
Share on other sites

@unilock I just did a quick compare of your unpatched ACPI to mine and don't see any relevant differences, so I don't think you need to create your own patched DSDT.  I hope I posted this before sending you on a wild goose chase.  I'm stumped.  While it's strange that your aux drive caddy works with other OSes and not macOS, the only thing I can think is to get another caddy.

Share this post


Link to post
Share on other sites

@unilock After I posted my comment below, I realized that the additional SATA ports may be a port expander / docking station or that you have enabled eSATA ports in BIOS.  Are you performing your testing with your laptop in a docking station or with eSATA enabled?  If so, this would be a big difference between your configuration and mine.  I never examined the DSDT (let alone tested) with a docking station or with eSATA enabled.  If that's the case, try testing "undocked" and/or with eSATA disabled in BIOS to see if that affects operation of your aux bay drive.

 

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

 

 

@unilock I finished reviewing your posted files to see if there's anything I can learn from your previously posted configurations.  I'm not sure if those configurations accurately represent your current state, but if they do, this might offer a clue about your SATA problem.  There's one IORegistry difference that leads me to believe we have different BIOS settings, so I'd encourage you to review the BIOS settings I listed in Post #1 and compare to yours.

 

If you look at the two IORegistry screenshots attached to this post, the screenshot of my IOReg lists only two SATA PRT "ports": PRT0 (my primary SSD) and PRT1 (my aux bay SSD).  Your IOReg lists two additional SATA "ports" that I don't have listed on my laptop: PRT4 and PRT5.

 

It's possible that if you can determine the difference between your SATA configuration and mine, this might provide a clue for you.

 

Screen Shot 2020-02-27 at 8.20.02 AM.png

Screen Shot 2020-02-27 at 8.20.42 AM.png

Edited by tonyx86
Added comment about docking station

Share this post


Link to post
Share on other sites

@tonyx86

Apologies for the late response.

I tested your DSDT that emulates Win7 instead of Linux, but no change in bay drive behavior.

I've been testing the laptop undocked. While I believe my BIOS settings are identical to yours, this may not be the case. I'll disable eSATA in BIOS if it is indeed enabled, then upload a new debug report.

 

EDIT:

Looks like disabling the eSATA ports in BIOS did get rid of the extra SATA entries. Unfortunately, it didn't solve the bay drive issue. Attached is the output of black.dragon74's tool.

If you need me to list the changes I've made from the "baseline" specified in post #1, I'd be glad to do so later, but I have a killer headache right now.
Thanks for taking the time to look at this.

debug_2020-02-27.zip

Edited by unilock
add debug files

Share this post


Link to post
Share on other sites

@unilock I see the obvious differences between our configs (listed below) of which you are already aware.  I'm not sure how these would affect the aux drive bay (probably they don't), but I have no other guesses.  If you have already tried the baseline that I've posted and it produces the same result, I have no other guesses.

  • Different version of FakeSMC
  • Different version of Lilu.kext
  • Kexts in E/C/k/O instead of /L/E

Just to clarify the way I'm using the aux drive,

  • I do NOT have an EFI installed on the aux bay drive
  • Aux bay drive is MBR formatted
  • Windows 10 is installed on aux bay drive in Legacy mode
  • I installed Windows 10 on the aux bay drive WITHOUT any other drives installed in the laptop (to be sure that the Windows 10 installer did not modify my macOS drive in any way)
  • I installed Windows 10 on a 100GB partition of the aux bay drive, initially leaving the remainder of the 256GB aux bay drive unformatted
  • On the remaining unformatted portion of the aux bay drive, I created an HFS+ partition on the aux bay drive using "Paragon HardDisk Manager Basic" running IN WINDOWS 10
  • I added the aux bay partitions to Spotlight Privacy tab in macOS so that macOS does not try to index the aux bay drive
  • To boot Windows 10 from the aux bay drive, I press F12 at boot and select the aux bay drive
Edited by tonyx86

Share this post


Link to post
Share on other sites

Attached is a new DSDT for the Latitude E6410.  Details are below.  This DSDT is not yet included in the baseline in Post #1.

 

I don't know much about Clover hot patching, so I was reading to learn and I just learned that I have been incorrectly applying Rehabman's "Instant Wake" DSDT patch.  Rehabman explains that in order to prevent instant wake, any Method (_PRW) that returns Package() { 0x0D, 0xXX } should be changed to return Package() { 0x0D, 0x00 }.  What is a bit harder to find (at least it was for me) is Rehabman's explanation of the proper handling of Method (_PRW) that returns GPRW(0x0D, 0xXX).  In this case, I had incorrectly changed GPRW(0x0D, 0xXX) to GPRW(0x0D, 0x00).  The correct application of Rehabman's instant wake fix is to change GPRW(0x0D, 0xXX) to Package() {0x0D, 0x00} so that GPRW is not called and _PRW simply returns the Package.  You'll find this explanation if you Google "Rehabman Using Clover hot patch ACPI". Rehabman actually changes Method (GPRW), which achieves the same as my correction below.

 

The result of this correction is that my originally patched Method(_PRW):

 

 

                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return ( GPRW (0x0D, 0x00) )
                }

 

 

should be changed to

 


                Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
                {
                    Return ( Package() { 0x0D, 0x00 } )
                }
 

 

I have made this change in the attached DSDT.  This DSDT also includes other minor fixes to resolve DSDT compile warnings (fixes that I found in Slice's E6430 DSDT (thank you, @Slice)).

 

By the way - with this instant wake patch, you will not be able to wake your laptop with USB.  This patch completely disables wake by USB (even if it is enabled in BIOS).

 

 

DSDT.zip

Edited by tonyx86

Share this post


Link to post
Share on other sites

@tonyx86

The way I'm using the aux drive is almost identical:

  • It's formatted as MBR
  • Windows 7 is installed on it
  • Windows 7 was installed without any other drives in the laptop (it wouldn't install correctly otherwise)
  • The Windows 7 partition takes up the entirety of the drive
  • I enabled "legacy" scanning in Clover so I could boot Windows 7 from there

Pardon if the following seems a bit rushed:

I realized the other day that perhaps there truly is a difference between aux drives, as mine was originally purchased for a Thinkpad W500 (which no longer functions for unrelated reasons). I've read online that there could be technical differences between aux drives advertised for different brands concerning how they interface with the laptop. Maybe that's the issue? If it is, fully disassembling your drive might provide some insight, as we could search for any differences in wiring or whatnot that I might be able to solve with a soldering iron.

See here

Share this post


Link to post
Share on other sites

CORRECTION: I thought the circled resistor in the attached pic was missing from my circuit board, but upon closer inspection, I can't be certain.  I would recommend purchasing a new caddy specifically for the E6410.  Sorry I can't be of more help with this.

 

@unilock That sounds logical. I don't want to disassemble my aux bay caddy any more than I have, so I'd suggest purchasing one specifically for the E6410.  I think I found mine for $8 on Ebay.  I splurged and purchased one with the release latch, since reviews I read suggested that other "universal" caddies did not fit well.  My caddy fits perfectly and has the same release mechanism as the original DVD.

IMG_20200124_073638.jpg.2028863b36a274f5cb90dd950a5a9f4b.jpg

Edited by tonyx86
Added picture with suspected extra pull-up resistor

Share this post


Link to post
Share on other sites

@tonyx86

I think I can spy the same resistor on your board from the image you supplied -- it looks like it has something to do with the activity indicator LED.

I'm going to end up spending money on *something* here, anyway, since I accidentally broke the aforementioned release latch off of my aux bay drive. Unfortunately, that was the same one that was on my stock DVD drive...

Thanks for all the help trying to get this working, though. At least we figured out what the white switch on the side of the modular bay drive does, after all this.

Share this post


Link to post
Share on other sites
Posted (edited)

For those who would like to figure out why AppleALC.kext "interferes" with Wi-Fi, causing a delay in the Wi-Fi connection, I might have a clue.  I'm content with VoodooHDA and won't be pursuing an alternative to VoodooHDA, but others may find this of interest.  When using AppleALC.kext for sound instead of VoodooHDA.kext, I have noticed that Wi-Fi won't connect until there is an AppleHDA "event" in Device (HDAU) (observed using IORegistryExplorer).  If you open IORegistryExplorer and watch Device (HDAU) when AppleALC is installed, you'll noticed a change in the status of HDAU, immediately followed by the Wi-Fi connection.  Wi-Fi won't connect until this HDAU status change occurs.

 

I have also noticed that, with AppleALC installed, the layout-id of Device (HDAU) always changes to 0x07, regardless of the injected value in the DSDT.  From what I have read, HDAU should have the same layout-id as HDEF.  With AppleALC installed, I had tried to inject layout-id 0x0b (to match that of HDEF) by including layout-id in HDAU._DSM, but the layout-id doesn't seem to matter when using AppleALC. The layout-id of HDAU is always changed to 0x07 when AppleALC is installed.

Edited by tonyx86

Share this post


Link to post
Share on other sites
Posted (edited)

EDIT: I did a little more research on USB Power and found that Rehabman discussed this issue for Sierra and later ( Google "Rehabman USB power property injection for Sierra (and later)" ). He suggests that the IORegistry keys for USB Power should be injected via the custom SSDT-UIAC for USBInjectAll.kext.  Since we're using USBInjectAll.kext for this HackBookPro6,2, I have modified SSDT-UIAC (attached) to include Rehabman's suggestion (still using the MacBookPro6,2 power values from High Sierra 10.13.6 IOUSBHostFamily.kext).  You can choose your method of injecting these values (the attached SSDT-USBX or the replace SSDT-UIAC in EFI/CLOVER/ACPI/patched with the attached SSDT-UIAC).  Note that if you employ the revised SSDT-UIAC, the USB power keys are properly injected (search for AppleBusPowerController in IORegistryExplorer), but the USBMap utility mentioned below will still report that you haven't created Device (USBX).  I don't think that USBMap's reported status matters as long as the values are injected, but I can't be sure, since I still haven't determined whether these USB Power keys make any difference in operational behavior.

 

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

 

As I continue to try to figure out the Bluetooth Issue mentioned in Known Issues in Post #1, I found this tool that reports USB status:   USBMap.  When I ran the tool and selected option 'U' to Validate USB Power Settings, the tool reported that MacBookPro6,2 is not defined in IOUSBHostFamily.kext/Contents/Info.plist.  The tool proposes installation of a custom SSDT-USBX.aml that injects power values from the MacBookPro12,2 definition.  

 

Instead of using the USBMap tool's proposed power settings, I went back to High Sierra 10.13.6 (MacBookPro6,2 wasn't defined in Mojave's  IOUSBHostFamily.kex either) to find the USB power settings, created the attached custom SSDT-USBX.aml and installed this custom SSDT in EFI/CLOVER/ACPI/patched.  After rebooting Catalina, I don't notice any difference in behavior, other than that the USBMap Tool now says that USB Power is configured correctly.

 

I'm not sure what this custom SSDT is supposed to resolve/address, but I just want to report that it does NOT appear to fix the Bluetooth issue (in Known Issues in Post #1) and Catalina sleep still takes 32 seconds while High Sierra and Mojave sleep in 5 seconds.

 

 

SSDT-USBX.zip

SSDT-UIAC.zip

Edited by tonyx86
Added updated SSDT-UIAC

Share this post


Link to post
Share on other sites
Posted (edited)

A new E6410-Catalina-3v6.zip archive is attached to Post #1 of this thread with the changes listed below.  My Latitude E6410 (Nvidia Graphics) is running perfectly with this configuration.  You may need to execute Step #9 in Post #1 before applying these changes.  Note that I am no longer pursuing a solution for the Display brightness slider, so these changes have no attempts to fix the Display brightness slider (use the Dell brightness keys).  Also, I'm continuing to use CLOVER r5103 since I didn't see any required changes in r5104.  Also, I am using the same EFI for triple-booting High Sierra 10.13.6, Mojave 10.14.6 and Catalina 10.15.3 (with kexts unique to each macOS in /Library/Extensions) and all three OSes run great.

 

Changes in E6410-Catalina-3v6.zip attached to Post #1

  • Addition of SSDT-USBX.aml (install in EFI/CLOVER/ACPI/patched) - injects MacBookPro6,2 USB wake/sleep power properties which have been removed from IOUSBHostFamily.kext after High Sierra 10.13.6
  • DSDT changes
    • Resolve a few ACPI compile warnings (fixes borrowed from Slice's E6430 DSDT)
    • Rename EHCx to EH0x in DSDT (the only instance of these renames is in the DSDT, so no need for Clover to do this)
    • Other minor revisions 
  • Disabled EHCx -> EH0x renames in CLOVER config.plist (no longer necessary after performing renames in DSDT)
  • Upgraded Lili.kext from 1.4.1 to 1.4.2
Edited by tonyx86
Removed note about EH01:HP14 since it is a real external USB2 port

Share this post


Link to post
Share on other sites
Posted (edited)

EDIT: I prefer a revision to this kext injection strategy here.  Leaving this post for historical purposes.

 

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

 

Setting Clover's "Inject Kexts" to YES (not DETECT) and placing the Brcm kexts in E/C/k/O may be a solution to the Bluetooth issue reported in Known Issues in Post #1 of this thread.  See more here.

 

EDIT: I am now running with the following configuration for triple-booting High Sierra 10.13.6, Mojave 10.14.6 and Catalina 10.15.3.  I will continue to test and am not yet recommending this as a baseline, but it looks promising.

 

Clover: Inject Kexts -> YES (not Detect)

 

The following kexts in E/C/k/O (not in /L/E)

  • Lilu.kext v1.4.2
  • BrcmFirmwareData.kext v2.5.1
  • BrcmPatchRAM3.kext v2.5.1
  • BrcmBluetoothInjector.kext v2.5.1
  • AirportBrcmFixup.kext v2.0.6
  • FakeSMC.kext v6.26
  • IntelMausiEthernet.kext v2.5.0
  • USBInjectAll.kext v0.7.1
  • VoodooPS2Controller.kext (Bronxteck) v6.0.0
  • ACPIBatteryManager.kext v1.90.1
  • FakeSMC_CPUSensor.kext v6.26
  • FakeSMC_GPUSensor.kext v6.26

 

The following kexts in /L/E for High Sierra and Mojave (not Catalina)

  • VoodooSDHC.kext 1.1.2

 

EDIT2: It appears that in Mojave (not Catalina), AppleHDADisabler.kext and VoodooHDA.kext need to be installed in /System/Library/Extensions.  In Mojave, I tried moving these kexts to /Library/Extensions and my laptop took forever to boot.  I do not observe this in Catalina 10.15.3 (where I can move AppleHDADisabler.kext and VoodooHDA.kext to /Library/Extensions without any issues).

 

EDIT3: It appears that FakeSMC_CPUSensors.kext and FakeSMC_GPUSensors.kext dependencies are such that they don't load unless they are co-located with FakeSMC.kext.  I haven't needed to set Clover's "Inject Kexts" to "Yes" before (I have always used "Detect"), so I'm not sure if there are problems with including kexts in both E/C/k/O and /L/E when set to "Yes."  It may be necessary to place the FakeSMC Sensor kexts in E/C/k/O as well if running HWMonitor.

 

EDIT4: I have moved all kexts to E/C/k/O as indicated above.  This kext configuration (combined with Clover "Inject Kexts" set to "YES" and not "DETECT") apprears to be working for High Sierra 10.13.6, Mojave 10.14.6 and Catalina 10.15.3.  I have VoodooHDA.kext and AppleHDADisabler.kext installed in /System/Library/Extensions where the VoodooHDA installer package placed them.

Edited by tonyx86
corrected typos

Share this post


Link to post
Share on other sites
Posted (edited)

EDIT: I prefer a revision to this kext injection strategy here.  Leaving this post for historical purposes.

 

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

 

I'm now convinced that the correct way to install the Brcm kexts for Catalina requires placing them in E/C/k/O with CLOVER "Inject Kexts" = YES.  On this Latitude E6410, the BrcmRepo kext does not inject reliably from /L/E.   Placing Brcm kexts in /L/E was reliable in High Sierra and Mojave.

 

I will be updating the baseline with this new (for me) kext installation strategy.  You can all tell me you told me so :)

 

EDIT: My candidate updates are attached.  Note that the LE folder is no longer included, as no 3rd party kexts are installed in /L/E for Catalina.

 

EDIT2: I haven't timed it, but it seems the boot times are slower.  I think that's to be expected now that Clover is injecting all 3rd-party kexts.

 

E6410-Catalina-3v7.zip

Edited by tonyx86
Added E6410-Catalina-3v7.zip attachment

Share this post


Link to post
Share on other sites

hi. need link how to create a bootable flash drive . and where to download the catalina . I have latitude e6410 but can't find , how  zip to make a download from the format

Share this post


Link to post
Share on other sites
1 hour ago, ferfwe said:

hi. need link how to create a bootable flash drive . and where to download the catalina . I have latitude e6410 but can't find , how  zip to make a download from the format

 

Sounds like you're new to hackintosh.  You have a lot to learn - just be patient with yourself.  You will need to know quite a bit in order to maintain your hackintosh, so the learning is essential.  Follow the installation instructions in Post #1 of this thread.  At each step, use Google to search when there are instructions that you don't understand.  There is plenty of available documentation that explains each step in more detail.  Good luck!

Share this post


Link to post
Share on other sites

should I change the wi-fi module?

BCM943225HM
BCM943225HMB
BCM94322HM8L
BCM943224HMS
BCM94352HMB will be alright?

21 час назад tonyx86 сказал:

 

Похоже, вы новичок в хакинтош. Тебе есть чему поучиться - просто будь терпелив с самим собой. Вам нужно будет знать немало, чтобы поддерживать свой хакинтош, поэтому обучение необходимо . Следуйте инструкциям по установке в Посте № 1 этой темы. На каждом этапе используйте Google для поиска, когда есть инструкции, которые вы не понимаете. Существует множество доступных документов, которые объясняют каждый шаг более подробно. Удачи!

Благодарю. Мне нужно изображение. остальное немного понятно

Share this post


Link to post
Share on other sites
4 hours ago, ferfwe said:

should I change the wi-fi module?

 

I personally have only tested the Broadcom BCM 94352HMB as noted in Post #1 of this thread.  Others who have posted in this thread have other cards working with the use of antenna adapter cables.  My instructions in Post #1 have been designed and tested to work with BCM 94352HMB.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By viktr
      A few days ago I faced a problem - installed ocquirks and it somehow breaks my prelinked kernel. System won't boot then, and I spent more than a day restoring from the netatalk  backup to copy working prelinked kernel directory from the backup to the s/l
      So, my question is - how to relink prelinked kernel without that? I found boot args -f UseKernelCache=No but it didn't work. I was able to boot to the recovery, if that can help.
    • By End3rPower50
      Hi, i want install MacOS catalina in my laptop.
      i created a USB bootable with Catalina and Clover but it crashed at startup.
      Thanks in advance. 
       
      P.S I upload my EFI’s folder and crash screenshot
       
      Sorry for my bad english.
       
      This is my laptop: 
      CPU: intel i7 6500U 
      Graphics: Intel HD Graphics 520
      Ethernet: Realtek FE Family 
      Wireless: Dell 1820A (BCM94350ZAE)
      USB 3.0
       

      EFI.zip
    • By anokic
      I have been using clover to install and configuration my Hackintosh High Sierra 10.13.6. It's been a struggle and a pain. Can't restart/shutdown/wake from sleep. Random freezes. When freeze happens mouse works but in loading state. UI and open apps freeze not the mouse. I can make the apps smaller and move them.

      I haven't used any DSDT nor SSDT. Tried 5 or 6 of them from others but sometimes i end up not booting. Could someone explain me do i even need them and why? Do i need DSDT or SSDT or both?

      I'm going to try to install everything OpenCore. The first thing is i can't use a method that needs an internet while installing MacOS cause my ethernet/internet only works when i install MacOS. So i can't use the images i need full installation. Okay i have the full installation for 10.13.6. I need to use a version 10.13.4-6 versions cause application Sketch needs the newer one High Sierra 10.13.4++ version.

      Can you tell me? Can i use same kexts from Clover on OpenCore? Secondly how can i install full USB MacOS installer? (High Sierra 10.13.6 version i have is 7gb i think thats it)
      Is there a version of AMDHigh Sierra version made from the community for 10.13.4++ version?
      If i use the normal 10.13.6 High Sierra should i use this AMD 10.13.6 Kernel when i have installed the MacOS or some other kernel that's better for my system? https://github.com/Shaneee/AMD-High-Sierra-XNU/releases
      Whats the best version of High Sierra to use for Ryzen and Nvidia system?

      Will it be better to use OpenCore?

      Specs:
      Mortar Max B450M
      Ryzen 2600x
      Nvidia GTX 1060
      16gb DDR4 2400mhz
    • By Andy Vandijck
      I decided to extract the immutablekernel for Catalina 10.15.3.
      I had to add a FAT header but it extracts just fine.
      Thanks to this we have the kernel and kexts for the immutablekernel.
      The info dictionary and lists are also included.
      Needs further study if it contains extras compared to the prelinkedkernel.
      Maybe we can find out what those .im4m files (for example immutablekernel.x589iclydev.im4m) are thanks to this.
       
      Enjoy
      immutablekernel.zip
×