[GUIDE] Dell XPS 15 (9550) Mojave 10.14 / 10.15 Quick Installation

[agrafuese]

Also, just a note about VoodooI2C if you are still considering going back to using it - I am still having trouble with the trackpad not loading randomly (like I said, it's about 50/50). I am not sure if this is specifically due to trying the 2.4 version or if it is a memory allocation issue, but I am going to try to revert back to 2.3 and see if there is any success there. (EDIT: Nope... 2.3 still causes sleep/wake panics, so never mind that.) I will do anything to avoid using VoodooInput, because it is so terrible on my trackpad that I would rather not use it at all and just always use a wireless mouse instead.

 

EDIT: I am testing with VoodooI2C 2.4 and removing the VoodooInput and VoodooTrackpad plugins from inside VoodooPS2Controller. I still believe that these conflict with VoodooI2C, and I had success in Mojave when doing this (removing VoodooTrackpad back then before VoodooInput was implemented).

Edited April 16, 2020 by agrafuese

[golimpio]

4 hours ago, agrafuese said:

Also, just a note about VoodooI2C if you are still considering going back to using it - I am still having trouble with the trackpad not loading randomly (like I said, it's about 50/50). I am not sure if this is specifically due to trying the 2.4 version or if it is a memory allocation issue, but I am going to try to revert back to 2.3 and see if there is any success there. (EDIT: Nope... 2.3 still causes sleep/wake panics, so never mind that.) I will do anything to avoid using VoodooInput, because it is so terrible on my trackpad that I would rather not use it at all and just always use a wireless mouse instead.

 

EDIT: I am testing with VoodooI2C 2.4 and removing the VoodooInput and VoodooTrackpad plugins from inside VoodooPS2Controller. I still believe that these conflict with VoodooI2C, and I had success in Mojave when doing this (removing VoodooTrackpad back then before VoodooInput was implemented).

I've upgrade Clover to r5112 yesterday, but I didn't run the full install, I just replaced the CLOVERX64.efi and BOOTX64.efi files. I haven't noticed any difference so far.

Edit: I have the 9550 4K 16GB i7-6700HQ model with PM951 NVMe SAMSUNG 512GB

Edited April 16, 2020 by golimpio

[agrafuese]

Ah ok, so our systems are essentially identical except for the hard drive. I got stuck with the Lite-on version  I have to tweak a key in the config.plist for it, but other than that it seems okay.

 

On an unrelated note, I discovered that I am unable to write to /usr/bin for the ComboJack fix, even though I had SIP disabled and am running in sudo. I'm not sure if that is normal, but if anyone else has the same problem, I found a solution. Anything that was supposed to be in /usr/bin can go into /usr/local/bin instead. I submitted this to the github account that distributes ComboJack, but here are the changes that need to be made to install.sh and the launchagent plist:

 

Install.sh...

 

sudo cp ComboJack /usr/local/bin
sudo chmod 755 /usr/local/bin/ComboJack
sudo chown root:wheel /usr/local/bin/ComboJack
sudo cp hda-verb /usr/local/bin
sudo chmod 755 /usr/local/bin/hda-verb
sudo chown root:wheel /usr/local/bin/hda-verb

com.XPS.ComboJack.plist...

<key>ProgramArguments</key>
	<array>
		<string>/usr/local/bin/ComboJack</string>
	</array>

Everything else can stay the same.

[golimpio]

3 hours ago, agrafuese said:

Ah ok, so our systems are essentially identical except for the hard drive. I got stuck with the Lite-on version  I have to tweak a key in the config.plist for it, but other than that it seems okay.

 

On an unrelated note, I discovered that I am unable to write to /usr/bin for the ComboJack fix, even though I had SIP disabled and am running in sudo. I'm not sure if that is normal, but if anyone else has the same problem, I found a solution. Anything that was supposed to be in /usr/bin can go into /usr/local/bin instead. I submitted this to the github account that distributes ComboJack, but here are the changes that need to be made to install.sh and the launchagent plist:

 

Install.sh...

 

sudo cp ComboJack /usr/local/bin
sudo chmod 755 /usr/local/bin/ComboJack
sudo chown root:wheel /usr/local/bin/ComboJack
sudo cp hda-verb /usr/local/bin
sudo chmod 755 /usr/local/bin/hda-verb
sudo chown root:wheel /usr/local/bin/hda-verb

com.XPS.ComboJack.plist...

<key>ProgramArguments</key>
	<array>
		<string>/usr/local/bin/ComboJack</string>
	</array>

Everything else can stay the same.

I think that it's better to keep it in the "/usr/local/bin" folder like you have done (it's the proper way to do it in Catalina), but if for some reason you need access to the "/usr/bin" folder, you can mount the system volume as writable by running:

sudo mount -uw / && killall Finder

 

[agrafuese]

Interesting, thanks for mentioning that.

 

One more thing I wanted to point out - this may have been random, but I noticed that Airplay wasn't working with my iPhone (and visa versa) despite having BT4LEContinuityFixup.kext loaded. So, I removed it, and now Airplay is working as expected. I'm not entirely sure, but I believe this kext was originally built for 10.10/10.11, judging by the description on acidanthera's github. At least it doesn't seem to be needed, unless it has a very specific use case that I'm unaware of. YMMV.

[golimpio]

@agrafuese Thanks for your feedback. Are your system more stable now? Do you still have issues with double tap to drag? 

[agrafuese]

Unfortunately you are right that the dragging isn't working. I actually didn't know about that feature until you mentioned it a few days ago (I had to google it), and I don't use tap at all. Perhaps the next I2C release will be improved for that, since you mentioned it to them.

 

My system is more stable than it was when I first installed Catalina earlier this week, but it still has flaws. The trackpad randomly not loading sometimes is the main problem. Sleep/wake is still troubling me a little, even though it is better now than it was. I thought it was fixed until I realized that having the lid closed for a long time still puts the system into hibernate mode - which I definitely turned off with pmset - then I get a KP when I open it back up. The error report is really strange too. It doesn't blame any particular kext (like it used to with I2C 2.3). Instead it just says "Sleep Wake failure in EFI" and then a failure code.

 

The system does boot a lot more reliably than it used to with Mojave - i.e. there hasn't been an allocation error yet like the ones I used to get back then, but it will run out of memory during boot from time to time and loop back to the start. That's really uncommon, however, and not such a terrible thing.

Edited April 18, 2020 by agrafuese

[golimpio]

On 4/18/2020 at 4:14 PM, agrafuese said:

Unfortunately you are right that the dragging isn't working. I actually didn't know about that feature until you mentioned it a few days ago (I had to google it), and I don't use tap at all. Perhaps the next I2C release will be improved for that, since you mentioned it to them.

 

My system is more stable than it was when I first installed Catalina earlier this week, but it still has flaws. The trackpad randomly not loading sometimes is the main problem. Sleep/wake is still troubling me a little, even though it is better now than it was. I thought it was fixed until I realized that having the lid closed for a long time still puts the system into hibernate mode - which I definitely turned off with pmset - then I get a KP when I open it back up. The error report is really strange too. It doesn't blame any particular kext (like it used to with I2C 2.3). Instead it just says "Sleep Wake failure in EFI" and then a failure code.

 

The system does boot a lot more reliably than it used to with Mojave - i.e. there hasn't been an allocation error yet like the ones I used to get back then, but it will run out of memory during boot from time to time and loop back to the start. That's really uncommon, however, and not such a terrible thing.

Probably one of the reasons I don't notice any sleep/wake issues is because I don't use it too often. Usually I work with a second monitor plugged in and I have sleep turned off, otherwise it will wake up to a black screen (built-in screen only), but this is because I use a different ig-platform-id (Iris 540 - 19260004) to support 2560x1440 HiDPI on a 4K monitor (the original config.plist from the repository will support 2560x1440, but without HiDPI).

After I've updated to Clover r5112, I've noticed a stranger behaviour: I usually don't have verbose mode enabled (-v) and now, doesn't matter what I do, Clover will always boot in verbose mode. I thought I was going crazy, but since it doesn't affect the way my MacOS runs I've stopped looking for any rational reason for it.

About the BT4LEContinuityFixup.kext, it's not part of the original kext from the repository, I added it a few months ago to see if it would bring back support for continuity in my setup, but it didn't work and I forgot to remove it. I ended up getting continuity to work after a system update. I've removed it now.

I've also removed the follow drivers without any visible issue so far: 

- AppleImageLoader.efi

- AppleUiSupport.efi
- AptioMemoryFix.efi
 

[agrafuese]

I had a feeling you would say that about your sleep config  I bet you will find that if you turn sleep on, unplug power, and close the lid, you will wake up to a reboot. Right now it's making me a very unhappy guy, because I can't close the laptop and move to a different place without shutting down first. This is the pmset error that it gives when you type:

sudo pmset -g log | grep -i failure

 

Quote

Failure during sleep: 0xFFFFFFFF0000001F : EFI/Bootrom Failure after last point of entry to sleep

 

I googled it, and no one has any specific answers to the problem. However, I am noticing that many of the results are fairly new, as if this has become a problem more recently - perhaps with Catalina, but I think some had been experiencing it since Mojave.

 

I have compared our current setup to the old Mojave setup (because I never had sleep problems in Mojave), and sadly I couldn't find anything that would cause an issue like this. So, it is either something new with Catalina, or something new with Clover (or perhaps the newer kexts being used).

 

Sorry to hear you are having that problem with invisible -v activation. I wish I knew more about Clover to suggest something. It is very odd. I always have -v on because it helps me predict when my trackpad is randomly not going to work (I have memorized what the error looks like when it scrolls by quickly, haha).

 

I hope one of us here can figure out the sleep issue. Like I said, it only happens on battery power. Sleep works perfectly fine on AC power. I am obsessively looking for the answer. I may even rebuild the USB SSDT, as many results have pointed towards it being a potential fix. But the error above seems to be pointing at something else.

 

 

[agrafuese]

These are the drivers I have loaded. Like you, I took out the others that you mentioned a couple days ago, trying to eliminate anything that might cause problems. Almost all of these came with the r5112 Clover installer, and they are all up to date as of now...

 

AllocFix.efi

ApfsDriverLoader.efi

AppleKeyFeeder.efi

AudioDxe.efi

DataHubDxe.efi

FirmwareVolume.efi

FSInject.efi

HFSPlus-64.efi

NvmExpressDxe.efi

OsxAptioFix3Drv.efi

OsxFatBinaryDrv.efi

VirtualSmc.efi

[golimpio]

2 hours ago, agrafuese said:

I had a feeling you would say that about your sleep config  I bet you will find that if you turn sleep on, unplug power, and close the lid, you will wake up to a reboot. Right now it's making me a very unhappy guy, because I can't close the laptop and move to a different place without shutting down first. This is the pmset error that it gives when you type:

sudo pmset -g log | grep -i failure

 

 

 

Sorry, I couldn't replicate it. I've only tested it 3 times (unplugged) and I haven't any KP. I'll keep an eye on it. I've tested with the lid closed and without closing it.

Note: I've updated Clover to r5113 and I've also updated all the drivers to match your list (so I should have the same EFIs that you have).

At least this last update solved my problem. I think the "-v" was being loaded from the nvram file, and for some reason, even when I was deleting the nvram.plist file before, the "-v" option was coming back.

I've attached an image from Hackintool with a partial list of the kexts/versions I'm using.

The files I have on the kext/other folder are:
 

 AirportBrcmFixup.kext        CPUFriendDataProvider.kext         SMCBatteryManager.kext   VirtualSMC.kext
 AppleALC.kext                FakePCIID.kext                     SMCLightSensor.kext      VoodooPS2Controller.kext
 BrcmBluetoothInjector.kext   FakePCIID_Intel_HDMI_Audio.kext    SMCProcessor.kext        WhateverGreen.kext
 BrcmFirmwareData.kext        Lilu.kext                          SMCSuperIO.kext
 BrcmPatchRAM3.kext           NoTouchID.kext                     USBPorts.kext
 CPUFriend.kext               SATA-100-series-unsupported.kext   VerbStub.kext

 

Edited April 20, 2020 by golimpio

[kennylauer]

On 4/15/2020 at 8:23 PM, golimpio said:

it's a shame that we have to choose between click to drag and better scrolling when we could have both, anyway, I don't have the knowledge for helping fix this, so I'm just glad that I have options for now and it's free.

 

If you can adapt, I use "Three Finger Drag" with voodooi2c and the experience is nothing short of perfect! I never used any of the like prior, so adapting to a new feature was painless. Have you tried configuring the options in the .plist file within voodooi2c for double click to drag as you prefer? -- I'm sure your experience is greater than mine, this just came to mind reading your post. If you find this suggestion elementary, disregard.

 

I came here to see if anybody else had encountered sleep issues with Catalina. Ever since install (first upgrade from Mojave, now a fresh install) I'm getting consistent Kernel Panic on lidwake from sleep. Only when the lid is closed and reopened though. Mouse sleep/wake works as it should. It happens so quickly, it's almost as if opening the laptop acts as I have pressed the power button. I am not sure if it is entering the panic state at the point it goes to sleep, or at the time of wake. Digging into the problem now...

Edited April 20, 2020 by kennylauer

[agrafuese]

2 minutes ago, kennylauer said:

I came here to see if anybody else had encountered sleep issues with Catalina. Ever since install (first upgrade from Mojave, now a fresh install) I'm getting consistent Kernel Panic on lidwake from sleep. Only when the lid is closed and reopened though. Mouse sleep/wake works as it should. It happens so quickly, it's almost as if opening the laptop acts as I have pressed the power button. I am not sure if it is entering the panic state at the point it goes to sleep, or at the time of wake. Digging into the problem now...

 

YES. ME. YES. (haha)

 

Not sure if you have had a minute to read any of the past few posts between golimpio and myself, but it is all about this very topic. We are currently trying to figure out exactly why he is not having trouble but I am, and we both have pretty much the same exact hardware config, minus the hard drive (I believe). I am actually about to post some more info below this. Hopefully between all of us, we can figure out this really annoying problem! It's driving me absolutely nuts.

[agrafuese]

Thank you for your supportive suggestions and information, @golimpio . I am out of possible solutions/answers for now, or at least until I have enough time to rebuild some SSDTs, or do more research to try and figure out what I'm missing. We do indeed have the same kexts loaded as far as I can see (except I don't use NullEthernet.kext or VoodooInput - I took the plugin out of VoodooPS2Controller... but I did put it back in just as a control test, but it didn't affect anything). Here is a list of things I have done, if anyone reads this and has any suggestions:

 

1. Updated from Clover r5112 to r5113 (no affect).

 

2. Tried booting with and without:

 - SSDT-PCI0.aml

 - SSDT-UIAC.aml

  (note: I'm actually not sure what these do (I know UIAC is USB related, right?), but I focused on them because they are the only two UEFI files not in wmchris' repo.)

 

3. I tried turning on or off the following BIOS settings (because I saw them come up in sleep discussions):

 

 - Fastboot (minimal vs thorough)

 - Legacy Boot Rom (I can't remember the real name)

 - Touchscreen (only as a control test, since you don't use it, golimpio)

 

4. I have also taken out the I2C kexts, as another control test (since you don't use those either).

 

5. All of the "pmset" stuff, using all the different -a, -b, -c methods, states, and using "& reboot" after, as suggested by wmchris' guide.

 

Also, like @kennylauer has mentioned, I noticed that the problem is the initial sleep state and not the "wake" part. I found this out after trying to sleep from the menubar as opposed to closing the lid. So yeah, choosing sleep in the menu bar is basically a way of powering off, haha.

 

I have no choice but to give this until the end of the week, and if we don't find a solution, I'm going to have to revert back to Mojave, because I absolutely need this laptop to be able to sleep on battery power.

 

By the way, @kennylauer do you have sleep issues on AC power, or just battery? Mine is only with battery.

[agrafuese]

@kennylauer Some other questions after you read above....

 

- Clover version?

- Are you using kexts/drivers from the repo, or from golimpio's post, or a custom set of your own?

- Did both your upgrade from Mojave AND your clean install of Catalina have the same sleep issue?

- Can you post last line (not the whole thing please) you get when you type the following in terminal:

sudo pmset -g log | grep -i failure

... or, can you post the error you get when you reboot back into the OS after a sleep crash?

[golimpio]

4 hours ago, kennylauer said:

 

If you can adapt, I use "Three Finger Drag" with voodooi2c and the experience is nothing short of perfect! I never used any of the like prior, so adapting to a new feature was painless. Have you tried configuring the options in the .plist file within voodooi2c for double click to drag as you prefer? -- I'm sure your experience is greater than mine, this just came to mind reading your post. If you find this suggestion elementary, disregard.

 

I came here to see if anybody else had encountered sleep issues with Catalina. Ever since install (first upgrade from Mojave, now a fresh install) I'm getting consistent Kernel Panic on lidwake from sleep. Only when the lid is closed and reopened though. Mouse sleep/wake works as it should. It happens so quickly, it's almost as if opening the laptop acts as I have pressed the power button. I am not sure if it is entering the panic state at the point it goes to sleep, or at the time of wake. Digging into the problem now...

I didn't get used to 3 fingers drag in the past, but I'm giving it another try again after you suggested it.

I think I can get used to it, if I can use it for a week or so. When I tried it before, 4 fingers gestures for Mission Control and Expose weren't good enough (so I was using 3 fingers gesture instead of 4), but now it seems to be stable.

Also there is a good advantage of using 3 fingers drag instead of single tap to drag: there is no delay on the normal tap to click.

Thanks for the suggestion.

Anyway, I still haven't experienced issues with sleep. I left it overnight (I've closed the lid) and it woke up just fine. I've tested it again with and without (via menu) closing the lid and still no issues.

I'm not using voodooi2c this time, have you tested without it? I only have the latest VoodooPS2Controller.kext loaded.

All gestures are working fine, I don't have a big issue with cursor jumping around, but scrolling is inferior without voodooi2c (also, I don't use touch screen). I'm just getting used to it for the time being.

Note: All my kexts are "release" versions, I don't have "debug" versions installed. It shouldn't make any difference though.

[agrafuese]

59 minutes ago, golimpio said:

I left it overnight (I've closed the lid) and it woke up just fine. I've tested it again with and without (via menu) closing the lid and still no issues.

 

 You have a lucky machine! Don't mess with it! 

 

59 minutes ago, golimpio said:

I'm not using voodooi2c this time, have you tested without it? I only have the latest VoodooPS2Controller.kext loaded.

 

 

With, and without = same result. The funny thing about this time, it's not like the old KPs we used to get from I2C 2.3... this time it is a "EFI/Bootrom" error - and I have no idea what that means!

 

59 minutes ago, golimpio said:

Note: All my kexts are "release" versions, I don't have "debug" versions installed. It shouldn't make any difference though.

 

Same here. Just to confirm, you aren't doing anything custom inside any kext plists or anything like that? Did you ever make any custom SSDTs that might be dependent on your exact machine? Any terminal commands you can remember? Anything else custom in any settings or anything similar?

[golimpio]

22 minutes ago, agrafuese said:

With, and without = same result. The funny thing about this time, it's not like the old KPs we used to get from I2C 2.3... this time it is a "EFI/Bootrom" error - and I have no idea what that means!

I also don't know about the boot rom, but just out of curiosity, I'll share part of macos' system report:

 

Hardware Overview:

 

  Model Name: MacBook Pro

  Model Identifier: MacBookPro13,3

  Processor Name: Quad-Core Intel Core i7

  Processor Speed: 2.59 GHz

  Number of Processors: 1

  Total Number of Cores: 4

  L2 Cache (per Core): 256 KB

  L3 Cache: 6 MB

  Hyper-Threading Technology: Enabled

  Memory: 16 GB

  Boot ROM Version: 265.0.0.0.0

  Apple ROM Info: Apple ROM Version.

  Board-ID       : Mac-A5******

⌘  Powered by Clover revision: 5113 (master, commit 05d49b78a)

  SMC Version (system): 2.38f8

  Serial Number (system): C02******

  Hardware UUID: 0BB*****-****-****-****-************

  I'm assuming that the Boot ROM version is the same.
 

[golimpio]

30 minutes ago, agrafuese said:

Same here. Just to confirm, you aren't doing anything custom inside any kext plists or anything like that? Did you ever make any custom SSDTs that might be dependent on your exact machine? Any terminal commands you can remember? Anything else custom in any settings or anything similar?

As far as I remember, I still have the change from xxxzc github repository: "Use fake EC and update PMCR", so some of my ssdt are different because of it, like the additional ssdt-pci0 and a few changes to the config.plist.

There is an additional ssdt-uiac, which was exported by hackintool. I was trying to solve an issue with my external usb hdd being disconnected from time to time and my wireless mouse not working properly when the usb adapter was plugged in the left USB port. I don't think it worked, but I never removed this ssdt. Because of it, I also have a different version for the USBPorts.kext

I've removed the ssdt-alc298 from my setup, but I don't even remember why I've done it.

Some of these changes I've done before Catalina and I just lost track of the reasons I've done them.

[agrafuese]

@golimpio !!! @kennylauer !!! I think I found the solution!!! 

 

I'm still very excited, so hopefully I am not missing something obvious here, but ...

 

I went into /Library/Preferences and deleted the two plist files called com.apple.PowerManagement , rebooted, and now I get sleep with battery!! 

 

I have no idea why I have two. One of them is just the normal com.apple.PowerManagement.plist and one of them is com.apple.PowerManagement.Bunch-Of-Random-Numbers-And-Letters.plist . Both of them get regenerated upon reboot. I thought maybe only the normal one would, but that's not the case.

 

I have no way of proving what I am about to say, but... I am highly suspicious of the "bless" problem when Catalina finishes installing. I think we are going to continue to see a lot of issues come up in the future that will eventually all link back to the bless problem. I have an unsupported (for now) theory that without blessing, there are various system file permission problems from the start, and they all need to be resolved within the system, after installing.

 

In this case, I believe that deleting the plists and allowing the system to regenerate them fixes the file permissions in a way that other methods will not. The reason I can't fully support this theory is because fixing permissions manually (via Diskutil) SHOULD fix this problem. I tried doing this days ago outside of the OS (in Recovery Mode), but it did not fix anything. In fact, Disk Utility reported that everything was fine. So, I really don't know what else to say here. Someone with more knowledge could really help us clear this up.

 

All of this aside, I am just VERY happy that I have battery sleep working again!

[agrafuese]

3 hours ago, golimpio said:

As far as I remember, I still have the change from xxxzc github repository: "Use fake EC and update PMCR", so some of my ssdt are different because of it, like the additional ssdt-pci0 and a few changes to the config.plist.

There is an additional ssdt-uiac, which was exported by hackintool. I was trying to solve an issue with my external usb hdd being disconnected from time to time and my wireless mouse not working properly when the usb adapter was plugged in the left USB port. I don't think it worked, but I never removed this ssdt. Because of it, I also have a different version for the USBPorts.kext

I've removed the ssdt-alc298 from my setup, but I don't even remember why I've done it.

Some of these changes I've done before Catalina and I just lost track of the reasons I've done them.

 

I took out "Use fake EC and update PMCR" from mine and removed the related SSDTs a few days ago, and I didn't notice any difference with or without them. 

 

I reverted USBPorts.kext back to the original repository version, but I don't think it matters either. And there was a "high power" USB patch inside config.plist that I took out, because it seemed related to this stuff. I think I am pretty much back to the repository version of config.plist, except for some really minor preference-type stuff and a patch fix related to my hard drive.

 

I removed the ALC298 as well and it had no impact that I could tell (I assume this is supposed to be audio-related?).

 

In saying all of this, I'm not sure whether or not these changes will have an effect on things "behind the scenes" like power consumption or efficiency. I am no expert, and I continue to experiment and research what people say about all of these drivers/SSDTs/kexts. Some of them are harder to find info on than others. Many of them served a purpose at one time and then became outdated as new kexts or versions of Clover were released. 

 

You might remember me mentioning that a USB2 hub (unpowered) helped me with my USB hard drive problems. On the other hand, I use a wireless mouse with the receiver directly plugged in (both sides) and I've never had issues. It's hard to diagnose certain things sometimes with these laptops being about 4 years old now. For example, I recently discovered that my internal mic is physically damaged and that's the reason why it never worked - so it was not related to hackintosh at all.

 

There are still some very minor features missing now that used to exist in the Mojave build. For example, the "slightly dim the display while on battery power" isn't working yet, and I don't think the auto brightness sensor is working anymore. None of this bothers me, but it's just something I have observed so far.

Edited April 21, 2020 by agrafuese

[agrafuese]

To confirm, I allowed my laptop to stay closed overnight for 7 hours, and it woke up perfectly fine. So, the PowerManagement.plist truly was the culprit in all of this.

 

One thing I should also mention, I did my best to clear up any experimental sleep settings I may have applied earlier while I was trying to figure all of this out. I did the following:

 

First I restored all power management defaults, both in the GUI system prefs and then via this Terminal command:

sudo pmset restoredefaults

 

Then, to be safe, I applied the "hibernate mode off + reboot" command to prevent the potential corruption issues described by wmchris in the guide, as shown here:

sudo pmset -a hibernatemode 0 & sudo reboot

 

I also made the sleepimage file unwriteable as an extra precaution to prevent hibernation writing to the drive at all, like so:

sudo rm -f /private/var/vm/sleepimage
sudo touch /private/var/vm/sleepimage
sudo chflags uchg /private/var/vm/sleepimage

I got most of these ideas from wmchris' script ([repo]/10.15/Post-Install/Additional Steps/Hibernation/disablehibernate.sh), but I didn't use the whole script because I'm not sure if I want everything else turned off.

 

Then, I set energy settings in system prefs as I normally would. I'm attaching screenshots of my settings here.

 

[kennylauer]

Sorry to all who replied to me, I am short on time so I cannot write anything lengthy at the moment. I think I have solved my sleep issues simply by changing the dark wake bootflag. In this tutorial it is set as "darkwake=no" -- I simply changed it to "darkwake=0" as I believe it was in the past. No more kernel panics after sleep. I will confirm this resolution and get back to all who took the time to reply to me this evening. Thank you all, your ongoing research and efforts to maintain this platform's operability with macOS are greatly appreciated!

[agrafuese]

55 minutes ago, kennylauer said:

In this tutorial it is set as "darkwake=no" -- I simply changed it to "darkwake=0" as I believe it was in the past.

 

I think I saw the tutorial you are referring to, and I believe you are correct that it should be 0, as (according to what I read) most boot arguments do not allow yes/no values. I changed mine to 0 as well, and I think it would be good if this change were implemented in the guide/repo. In my case, it didn't actually fix anything, but it was helpful in eliminating it as a possibility while I was testing. In any case, glad you got your sleep working so far! If it turns out that you still have trouble, there is now a wealth of information and other solutions available here, haha.

[golimpio]

7 hours ago, agrafuese said:

To confirm, I allowed my laptop to stay closed overnight for 7 hours, and it woke up perfectly fine. So, the PowerManagement.plist truly was the culprit in all of this.

 

One thing I should also mention, I did my best to clear up any experimental sleep settings I may have applied earlier while I was trying to figure all of this out. I did the following:

 

First I restored all power management defaults, both in the GUI system prefs and then via this Terminal command:

sudo pmset restoredefaults

 

Then, to be safe, I applied the "hibernate mode off + reboot" command to prevent the potential corruption issues described by wmchris in the guide, as shown here:

sudo pmset -a hibernatemode 0 & sudo reboot

 

I also made the sleepimage file unwriteable as an extra precaution to prevent hibernation writing to the drive at all, like so:

sudo rm -f /private/var/vm/sleepimage
sudo touch /private/var/vm/sleepimage
sudo chflags uchg /private/var/vm/sleepimage

I got most of these ideas from wmchris' script ([repo]/10.15/Post-Install/Additional Steps/Hibernation/disablehibernate.sh), but I didn't use the whole script because I'm not sure if I want everything else turned off.

 

Then, I set energy settings in system prefs as I normally would. I'm attaching screenshots of my settings here.

 

 

 

There is a script for this already, have you tried before running it manually?

DellXPS15-9550-OSX/10.15/Post-Install/Additional Steps/Hibernation/disablehibernate.sh

Also:
- https://github.com/wmchris/DellXPS15-9550-OSX/blob/10.15/Tutorial_10.15.md#step-4-post-installation

It's a (sort of) mandatory script that we run after every MacOS upgrade or new install.