iGPU
-
Posts
573 -
Joined
-
Last visited
-
Days Won
17
2 Followers
About iGPU
iGPU's Achievements
Senior Member (3/3)
389
Reputation
-
I realize this is an old post (and if I've missed the solution shown here and I'm repeating what is known, my apologies), but the problem posted has plagued me on Ventura on both the AMD and Intel platforms, until a couple of days ago when I stubbled across two steps to fix the problem. (While I do read this thread, I've been absent due to various family matters of life and death that fortunately resulted in life.) The fix shown below works for both AMD and Intel platforms. Anyhow, previous to Ventura, one could type the following (spoiler) and get a listing of macOS versions to download: In Ventura, you get the error as shown at the top of this post. The fix is to install python 2.7.x, which can be downloaded here (a copy is attached to this post). After installing, perform the certificate confirmation step: The certification will open Terminal and show this result: Next, open a new window in Terminal and enter "pip install xattr", which will return the following: Finally, you can now enter a modification of the old command (spoiler), which simply uses a new path to python: Once completed, you'll be shown the familiar macOS selection within Terminal (spoiler): python-2.7.18-macosx10.9.pkg.zip
- 3,920 replies
-
- 3
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Two issues. First, I get the same error msg that @valmeida mentioned above even on Z690 system under Ventura when trying to use python. I'll give the RunMe_Downloader a try. 2nd issue: a couple of weeks ago, I updated the Big Sur drive to the latest 11.6.7 version and after it re-booted, the adjacent NVMe drive containing Ventura disappeared from the desktop. This past weekend I finally had time to investigate (I was too busy getting COVID for the 3rd time the previous week; so annoying!). The Ventura drive was located in the M2_1 (CPU) slot; Big Sur is in the M2_2 (CPU) slot and Win11 is in the M2_3 (PCH) slot, as shown below on my MSI TRX40 Creator mobo: To initially trouble-shoot, I swapped the Ventura and Big Sur drives with each other. The Ventura still did not show up on the desktop (nor was the Ventura drive visible within Disk Utility and it did not show up in BIOS). The faulty drive is a Sabrent Rocket Extreme 1TB NVMe SSD. I removed the Ventura containing NVMe drive and placed inside an external NVMe SSD enclosure in order to test with the Z690 computer and a real Mac laptop. It did not show up on the Z690 desktop (both Big Sur and Ventura), but left connected to the laptop (Big Sur), it did appear on the desktop after 5-10 minutes. At this point, the drive tested ok, but its behavior is not normal, so I'm suspicious of it being faulty. I then returned the Ventura containing drive to the MSI mobo. It still will not show in BIOS nor macOS. So I don't know if the mobo is faulty and somehow damaged the NVMe drive, or if the NVMe drive itself is the problem. The Big Sur NVMe works in either the M2_1 or the M2_2 slots, so this suggests that the mobo is working okay. Lately, I've been buying WD_Black NVMe SSDs and they seem more trustworthy and seem to have more positive comments than the Sabrent drives. Have any of you had similar problems?
-
As I recall it had to do with the original DSDT files for each mono being a little different. The mobos with internal TB had that device declared in the DSDT and I tried to add similar declarations to out mobos but it didn't work. On another topic, when items are defined for RestrictEvents in the NVRAM section, the same items need to be Deleted. I'd over-looked that step and recently caught the resulting error. See image below. RestrictEvents works better when set up this way, deleting all items that were added.
- 3,920 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
The USB-C mounting just got more confusing. I have a couple other USB-C drives, all by different companies and each with different macOSes on them. My initial tests were performed with the SSK Media drive that contains Monterey. It turns out that the different drives all behave differently between Big Sur and Ventura. The differences are summarized in the table below. There are differences between Big Sur vs Ventura but fortunately the Z690 and TRX40 mobos behave the same. So there are some differences with Ventura, as shown in red box above. The ASMedia drive is the odd one, since it won't mount on either platform in either OS (I now don't recall when I formatted it and installed Big Sur; maybe it was on a Z390 build). Based on these findings, I don't know which is affecting the mounting: a manufacturer's problem or the macOS on the drive problem. It seems that I'll need to format the bottom 2 drives (ASMedia and SSK) to see if, as empty drives, they will mount in Big Sur and Ventura. If they do mount then the macOS is affecting the mounting. BTW, all 3 drives mount on my real Mac laptop that is running Big Sur without any problems. The screen shots in Spoiler below were taken on the laptop. ***** Spoiler: drive manufacturer and macOS:
-
I've been having issues with USB-C drives not mounting (appearing) on the desktop under Ventura. There are zero problems with previous macOSes. See this post here and here for my initial comments. I posted on the InsanelyMac forum as I thought it was a Z690 issue but when testing on the TRX40, I had the same problem (again, only with Ventura). As shown below in the Hackintool USB section, the USB stick does appear on the desktop, while the external USB-C drive, whether I use a USB-C to USB-C or USB-C to USB-3 cable, does not appear on the desktop. Since the USB-C drive is shown as active within Hackintool (and I get the ejection error if I un-plug it), macOS Ventura is aware of the drive, but yet oddly, the drive does not appear on the desktop. It does not seem to matter which port I put the USB-C into, it does not appear on the desktop, while the USB3 stick does appear, when using the same port. While one response I got from someone on the InsanelyMac forum thought it was a USBMap kext problem, I tried different approaches and had the same result. Furthermore, no USBMap kext are even used on my TRX40 build as no USB device natively has more than 15 ports (therefore none are required). Adding the following Quirks did not help.
-
I've used that AIC and the Fenvi T919, both in the TRX40 and Z690 builds, and each build seems to worksbest if I used extra kexts, esp to get AirDrop working.
-
Despite people saying these cards work OOB, I've never found that to be true. The Fenvi T919 works just fine in Mojave through Ventura, but you need different kext files based on the OS version. For Monterey and Ventura you need the following:
-
Thanks for your hope: I got it to work. using the latest kexts and OC commits, and by setting Platforminfo/Generic/ProcessorType to 0. Your config file showed me the main difference of the ProcessorType value. I had been using 3841. Before this fix, the same error was occurring in the latest Big Sur update 11.6.7. (So whatever changes were in Ventura causing this broken RestrictEvents issue, were also added to 11.6.7.) I also was able to inject my specific verbiage using these arguments:
- 3,920 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
Strange, but despite using latest RestrictEvents and Lilu (and re-setting NVRAM), my processor still shows up as Unknown (works okay in Big Sur).
-
Yes, attached in my post above.
-
I've done all these things (aside from patches, same set up for Z690). I looked over your config file and we have the same Patches and Quirks. It continues to fail at about the same point (which is just before log-in; shown in Spoiler below). I'll try to re-install and if that fails, then I'll do a fresh install. Re-formatting and a fresh install did not help: things still got stuck at the final boot heading to login. More investigation... ***** Success! The key was adding AppleMCEReporterDisabler kext (which I noted in your config file, fabiosun; thanks!) and disconnecting the Aquantia port. The AppleMCEReporterDisabler kext file allowed me to boot Ventura, but it would crash before I could complete the sign-in. I thought perhaps an internet issue, so disconnected the Aquantia port and left the AIC ethernet, which I've described early in this thread (it uses the LucyRTL8125Ethernet kext file), connected. Attached is the config.plist file I used, less SNs. This config file boots late Big Sur, Monterey and Ventura beta 1. No custom ACPI or kext files are included. Of note is that I don't use WEG and instead inject DevProp for the GPU along with a customized ACPI file. Most of the kext files are for BT/Wifi turning on/off based on whether BS, Monterey or Ventura is being booted, providing good function including AirDrop. config-BS-Monterey-Ventura-public.plist.zip
-
I'm not able to yet test TB on the TRX40 as I cannot manage to log into Ventura. (Update on the Z690 was ok, but not yet for the TRX40). I decided on the TRX40, instead of a fresh install, to update the Monterey drive for Ventura (I'm presently writing this from the BS drive). The update process seemed to go well, but I believe cannot complete the final boot into Ventura. From the OC menu, I do have the option to boot into Recovery, but that too fails as shown in Spoiler below, where I think many Ventura updates fail. I usually do not have Above 4G enabled, so I tried that, but had no success with or without it enabled. fabiosun, in looking at your posted EFI, you did have one extra Patch that I'd not been using, but that extra patch made no difference in booting into BS or Ventura (Spoiler below). I must get to work, so I'll try other approaches tonight. (One option is a fresh install.)
-
Same: I too was never able to clean install Windows on the TRX40.
- 3,920 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
I got the Z690 working in Ventura tonight (here) doing a fresh install. It went very smoothly and installed really fast (no 10-30 min count downs on any re-boots during the install). I'll give the TRX40 a go tomorrow night (I've already adjusted a TRX40 config file for Ventura with updated patches, etc).
- 3,920 replies
-
- 1
-
-
- amd vanilla patches
- amd kernel patches
- (and 3 more)
-
There are 2 updates to Lilu and VirtualSMC that are supposed to help with 13 (and the "-lilubetaall" boot argument is not required). Maybe these will help you?
