PlutoDelic

It's the layout in loading the Tools (or drivers). You can use OpenCore Auxilary Tool which does the conversion for you. You need to pay good attention to Configuration Changes on every OC release.

Indeed. I've lost the selection of 1440p, but that might be due to my spoiled up device properties that i played around with from WhateverGreen's patching instructions. Scaling now does not have the list of resolutions, but the choice of "how big you want your text" (with a resolution under it). Seems only 1440p is missing. No deal breaker.

@Jake Lo Hero of the week mate. Thanks a lot. It makes sense, the fbmem and stolenmem ones are when you cant go around having the DVMT changes. No need to use them when you can switch them. What is very weird is that i did these values, i even checked them up to confirm. Your modified grub must be the difference maker, and this explains why unlocking CFG never actually worked for me and i had to use the quirks for it. Much appreciated sir. I cannot believe i am writing this from a virtually complete hackintosh.

Guys, I did report this in the past and i never found a workaround let a lone a solution. Basically, Windows can do 4K@30Hz in HDMI (it's a 1.4 HDMI), and 4K@60Hz through the miniDP 1.2. MacOS maxes at 1440p@60Hz on both ports. I did get curious about this and stumbled on the WhateverGreen patching for Intel iGPU's. Here i am, having tried virtually a Dr Strange amount of times of entries, to no avail. This is my latest Device Properties for it. I have to say there's virtually no difference in performance from Jake Lo's original package. Another entry that seems to cause issues is the hdmi20-enable, which causes a well known blank/black screen. I guess that should be very normal considering we have HDMI 1.4. WhateverGreen patching guide give us these values to play around:

Installing macOS without the Windows one being present seems to avoid the issue, completely differnet outcome with the same EFI.

I am going through the debug log once again, and i can only guess that it's trying to find macOS EFI files in the wrong disk, at least that's the impression i am getting with the GUID's. The "blessed" entries dont make much sense to me cause there's no information that seems to distinguish the entries to separate disks. EDIT: Here's a debug file of an attempt that actually booted, It still reverted to OCB: StartImage Failed - Aborted after two restarts.

@Jake Lo Many thanks for the tip, made me quite curious too as it worked out. I Disabled the WWAN/GPS interface on BIOS. For odd reasons, restarting and shutting down is extremely slow now, and this is happening on POST and BIOS. OC is also affected, the debug version took +5 minutes to load its drivers off, where as macOS booted in less then 15seconds. Obviously this may have been better if i physically removed the 2nd SDD where Windows is at. macOS used to be in that SSD in the past, and Big Sur would always corrupt the APFS containers after a few restarts. Of course Dell did not intend to have this device have two internal drives, so i cant really blame them for any kind of negligence happening in the Dell Firmware. What would be the next step on this? I am reading about "blessed drives" in OC but i cant find any configuration guide for them. PS, would i be avoiding this issue if per say i leave the OC on the Windows EFI, and leave macOS completely vanilla'd in its drive? Would OC have a better view if it sits next to the Windows boot manager? EDIT: Never mind, it's really foolish of me to completely forget ScanPolicy. I removed NTFS and ESP from the list, and it's working perfectly and got Windows rid completely. PS, when i re-enabled the WWAN/GPS port (which of course it's under Wireless Devices), UEFI/BIOS and OC speed caught up. Reporting this to Dell is most probably worthless. An additional side-effect i am noticing is, neither Windows nor Open Core can create EFI Entries anymore. I am strictly booting the "UEFI: DEVICENAME" auto entries. Is there any downfall on this, should i add direct entries for OC and Windows manually? EDIT 2: Incredible. Boot once again in Windows, and all problems return. Tough wall.

Can't make any sense as why i managed to boot and install successfully, just to never be able to boot once again. Here's my latest debug output. Anyone with a hint of a ray of hope would be greatly appreciated.

Team, I am facing this issue when trying to boot the Installer from the SSD. Initially, i faced the same issue when using the 0.7.0 OC package from the Guide thread, but that happened on booting the USB installer. After cross comparing and adapting a Debug version of 0.7.2 with the Guide package, i managed to boot the USB installer, went half-way through booting/installing from the SSD Installer, but on the 3rd restart, the "OCB: StartImage Failed - Aborted" issue came back once again. Apart from updating carefully to the recent OC Debug, i made sure i updated all the kext as well (except the ones from the Guide which are custom). Here's the OC Debug output. Additionally, when i try to sanitize the config,plist with OpenCore Auxiliary Tool, i get this output: Original path: PciRoot(0)/Pci(0x1f,3) Path after internal conversion: PciRoot(0x0)/Pci(0x1F,0x3) DeviceProperties->Add[0]->DevicePath is borked! Please check the information above! CheckDeviceProperties returns 1 error! Hardware wise, my e7470 is a i5-6200U (2x8GB 2133 RAM), latest BIOS, CFG Unlocked, DVMT done properly, 2242/WWAN SSD running Windows 11 (SanDisk/WD SN520 Gen3 1x NVMe, this ran macOS in the past) and a WD SN750 Black for macOS. I am keeping the EFI entries separate in UEFI and don't plan to DualBoot through OC. The config.plist that i used as a reference from the guide, is the Intel Wifi one. Would appreciate your help a lot. EDIT: I've traced Err(0xE) to CFG, so i enabled the CFG Quirks in OC, seems it went through. Unusual as even the OC CFG Driver reports CFG to be Unlocked. Installer went through which resulted in a successful install, and booting "macOS" gave me "OCB: StartImage Failed - Aborted". Weird enough, i noticed a difference in output after a retry, now im on the Log In page. Weird success story, but inconsistent boot try with different results always worry me.

Having the exact same issue as i do it seems. This could be tied to 11.1, as i did not test it with 11.0.1. I keep reading that Installing Catalina first and upgrading directly proves to be a workaround.

From the many questions that i have researched for a similar question, the main slot is x2 unfortunately, although it should be x4. I've read through quite a few dell community threads reporting the same. It could depend on the model, i.e, i have the low-spec i5-6200u. I have windows residing on the main m.2, and it reports x2 lanes speed.

Tested Catalina out of curiosity,, it's working quite well. This is probably Big Sur related.

Nothing to be isolated, this is definitely being caused by the update, confirmed. But it always happens on the 3rd restart, always. Accidentally, on that third restart, I left the disk1s1: device error. and void IONVMeController output going on, which resulted in a large LOG, what I could at least on the surface troubleshoot is that the system was actually booting but extremely slowly due to the error. It took a 20min verbose output, 20min Apple progress bar and a 20 other minute just to log in. System was excruciatingly slow, just barely to made it after an hour to get the restart button, which took another 20 minutes. The issue does not happen on a fresh install, and I did quite a few restarts. I've also tried the main M.2 slot with the same issue. It's probably something related to the WD PC SN520. I am currently on the brink of updating again, but with NVMeFix added from the beginning, just to see if that will change anything. I am a magnet of bizarre issues and unsupported hardware. Nevertheless, I don't seem to be the only one as I've seen a few reddit and insanelymac posts with the same issue, all report not having the issue on the latest Clover however. EDIT: Same results with three restarts in. EDIT2: And with 20B29 now it happens on the fresh install too.

You reckon it'll stay put if installed on the 2280 slot? I'll definitely see to it. I am currently doing a HFS+ install, just want to see if it makes a difference. There are a few people reporting the same issue on r/hackintosh and insanelymac, all have Big Sur with APFS. Edit: well i guess, everyone expected the results, i chose HFS+ but still got it as APFS, this is pribably nothing i should be surprised for.

This was meant temporarely. Main SSD slot is 2280, where i have a Micron 2200S, which triggers macos KPs. I cant install the 2242 SSD from the WWAN on the 2280 slot. I plan to switch roles in the future, leave Windows on the WWAN slot, and move macOS on the main one as soon as i get my hands on a decent NVMe, but i would use this layout for now. Recovery boots well, but cant fix anything.

Hi, Since the Beta threads are closed now, i thought i'd ask here too. I've tried my best to get a proper log file but everything is NUL (or <0x00> after the OpenCore debug output). I've been using Jake Lo's e7470 OC Package with a few of my own touches and have/had a very stable Big Sur environment. But twice, i have went through an APFS Container corruption, but i cant for my own sake of sanity find out what has been causing it. It just randomly happened. First time it happened, i could only isolate the randomness to two things, i logged in on the iCloud welcome screen between the Beta updates, and used Hackintool although only to read some values. None of the cases make sense to create such an issue. However, i've also isolated that i've signed to my Apple AirPort Extreme, which i strictly use as a NAS (SMB), to copy something, in both cases. In both cases, it randomly started happening after a few restarts, mostly of OS switches. It started with the initial first boot showing me this (i've ommited the values after DWORD, this line showed up at least in 5 straight rows): disk1s1: device error. void IONVMeController::HandleCompletionError(AppleNVMeRequest *, uint32_t)::5566:DWORD "SOME VALUES HERE in for a few ROWS" NVMeStatus=0x2004 Followed by the next boot (after a restart obviously): 1. This comes first nx_corruption_detected_int:55: disk1 Container corruption detected by obj_init:2775! alloc_space_for_write_with_hint:15409: spaceman_alloc() FAILED, err: 92 xid: 22501 paddr: 0 blocks requested: 1 blocks allocated: 0 2. Than an immense output of these apfs_vnop_blockmap:13735: disk1s1:0 ### obj-id 738787/738787 err 92 offset 0 size 524208 mapflags 2 destream apfs_fsync_internal:10740: disk1s1:0 cluster_push() failed with err 92 on ino apfs_vfsop_sync:4178: disk1 Container corruption detected by obj_init:2775! obj_write_prepare:4779: disk1s4:0 oid 1199 flags 0x21a1 0x0 type xid 22501 (cur xid 22501) error allocating 3. Until it stops for a bit with this: tx_flush_thread:1496: disk1 tx_flush(22501) failed, 92 # 146 (<- this number keeps increasing) And it keeps repeating this. ITLWM verbose output can be seen scanning networks and finding MAC addresses, so i assume the system itself is working but something has messed up the file system. EDIT: just some extra clarity. Big Sur resides on a 2242 SSD in the WWAN Port, running at 1x speed lanes, but it's a Western Digital PC SN520 (which happens to be SanDisk rebranded from what i could tell). First SSD is disabled via SSDT as OpenCore and MacOS really don't like it.

Incredibly, once again, after a few very normal restarts, system is unbootable, same issue as the B9 to B10 update, but this time i didn't log in to iCloud, so that is definitely not the culprit. It's definitely APFS/Container related, most probably Apple security mechanisms. I can tell that the OS boots correctly as ITLWM kext shows a lot of output, it's literary nothing else except ITLWM and the APFS issue. Initially it gave me this error: void IONVMeController::HandleCompletionError(AppleNVMeRequest *, uint32_t)::5566:DWORD SOME VALUES HERE in for a few ROWS NVMeStatus=0x2004 I had it earlier, but a reboot would fix it, although it happened probably only two times. After that, these lines constantly show up, A LOT, to an extent that i have difficulties looking at the screen as it can trigger epileptic reactions: Of course, some lines are incomplete and many have different values. nx_corruption_detected_int:55: disk1 Container corruption detected by obj_init:2775! alloc_space_for_write_with_hint:15409: spaceman_alloc() FAILED, err:92 xid: 22501 paddr: 0 blocks requested: 1 blocks allocated: 0 apfs_vnop_bloackmap:13735: disk1s1:0 ### obj-id 738787/738787 err 92 offset 0 size 524208 mapflags 2 destream apfs_fsync_internal:10740: disk1s1:0 cluster_push() failed with err 92 on ino apfs_vfsop_sync:4178: disk1 Container corruption detected by obj_init:2775! obj_write_prepare:4779: disk1s4:0 oid 1199 flags 0x21a1 0x0 type xid 22501 (cur xid 22501) error allocating tx_flush_thread:1496: disk1 tx_flush(22501) failed, 92 # 146 It's very odd, and i cant make up what's causing it cause i am not doing ANYTHING. I didn't even try to update from 20B28 to 20B29.

Update to 11.0.1 RC2 went smooth as well. In-system, it seems to show that it's the Final release, but i guess that will be tomorrow. Also fan readings started to work which didnt before. PS, found this nice app for that, Eul, supports notifications widgets too.

Update to 11.0.1 RC went as smooth as one could wish.

-v was there, never took it off. I booted the installer, and noticed that the drive was encrypted. I couldn't even wipe it. I ended up booting to Windows to wipe the drive, and am now sitting on a fresh 11.0.1. And i left the BootProtect and ScanPolicy to the new changes. If it wasnt the iCloud login, than im not sure what could have done this.

Backup Thumb drive has the same issues. Recovery boot works. I did login in the iCloud when i installed 11.0.1 after the setup, but i managed to boot in to the system at least 2-3 times after that, i hardly believe that could've caused this. Why it boots so quick to the Login Menu and goes to the verbose boot after is something very new. But i am pretty sure it wasnt like that when the update completed.

I've stumbled on something bizarre. I changed BootProtect to None in order to keep my Windows on the top of the list, and also tried playing with ScanPolicy to remove the Windows entry from the OC entries. First one worked well, than second one for some reason gave me an immense amount of verbose logs about having problems with "alloc_space_for_write_with_hint:15409" and "nx_corruption_detected_int:55". Reverting to ScanPolicy weirdly didn't do anything, but now the boot sequence of the OS itself changed dramatically. Booting from OC to Login Screen takes virtually 2 seconds. Nothing is verbose. After i type the password in, it switches to a verbose output similar as it was before booting to the login screen before, giving me the two errors from below at an immense speed. I thought i'd give NVRAM a clear, now for odd reasons, Windows remains at 100% CPU with a lot of BSODs. PS, sorry for the continuous posts, just trying to feed back possible bugs too. EDIT: I've reverted the ScanPolicy through Windows with Notepad++, would that cause anything stupid?

Successfully updated to 11.0.1. A bit confused with the version incrementation when it's still a beta. I really hope i didn't just update to another beta with the 11.0.0 final release near. That would be very odd.

Just a final report, again taking in to consideration with the device differences. Bluetooth works, but randomly. If a restart comes from Windows to macOS, it seems to have problems finding devices, a restart from macOS to macOS fixes it. Keeping in mind that i still have the stock Intel 8260 WiFi, however i'm not sure if it shares a BT with it too, vague memory right now. I can live with it as i barely use BT. I'm also trying to calculate the best Scan Policy for removing Windows from the OC boot entry, and am ashamed i've lost all my HEX abilities outside of MAC Addresses. And two issues which i think are NVRAM related, which probably have an easy fix until i learn a bit more about it. NVRAM clearings to test the best EFI, resulted in slow Restarts/Shutdowns/Sleep in Windows, which macOS does a lot faster haha. OC seems to hijack the UEFI priority list and put itself as the first UEFI boot entry, many times rendering the Windows Boot Manager incorrect, frankly the UEFI will always see the NVMe device. Also, impressively, battery drain is a lot less compared to Windows. It's been a really nice learning curve, and OpenCore is really wonderful to work with. Thank you Jake Lo, the board and OP for initiating this thread.

Just the four year break on the scene showing itself. ALL SET here.