Contribute
Register

[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

This usually happens with Linux and even with Windows. It seems Linux has written its EFI bootloader into the EFI partition of your macOS SSD.

Fortunately, this problem is solvable, but you will need to find a way to mount the EFI partition of the macOS SSD. There are ways to do this in Windows and Linux, but you may have to Google for the answer.

An alternative approach is to connect your Bootable Backup Disk and press F12 at BIOS Splash Screen and boot from that disk. Then mount EFI partition from macOS.

Once the EFI partition is mounted (using either Windows, Linux, or macOS), please expand the EFI folder and post a screenshot or a photo. Based on that we can help you move files around to fix the problem.

Does the Linux SSD contain its own EFI partition?
You were right, for some reason Linux just dropped its own folder in the EFI folder for MacOS. (see screenshot using MiniTool Partition Wizard)

I really don't care very much about Linux and I can just run it in a VM like I did before, so should I just delete the Ubuntu folder and try to reboot?

EDIT: I see the BOOT folder there too has yesterday's date from the Linux install. Is that important?
 

Attachments

  • EFI Folder.PNG
    EFI Folder.PNG
    60.2 KB · Views: 53
You were right, for some reason Linux just dropped its own folder in the EFI folder for MacOS. (see screenshot using MiniTool Partition Wizard)

I really don't care very much about Linux and I can just run it in a VM like I did before, so should I just delete the Ubuntu folder and try to reboot?

EDIT: I see the BOOT folder there too has yesterday's date from the Linux install. Is that important?
We should do this:
  • You can move the Ubuntu folder outside of the EFI folder.
    • Perhaps create a folder at the top level called OTHER and move the ubuntu folder there.
    • Also move the BOOT folder into the OTHER folder.
  • Now we will need to download the same version of Clover that is currently installed on that disk.
    • Now create a new folder inside "EFI" called "BOOT"
    • Then copy the BOOTX64.EFI file from the Clover package to the EFI/BOOT folder
  • Reboot
 
Thunderbolt NHI and USB and their bridges always report 2.5 GT/s x4 even though they are faster than that (these devices are internal to the Thunderbolt controller so they don't really use PCIe bus).
You should only worry about the upstream Thunderbolt bridge (8 GT/s x4 is normal/max) and your device (the Presonus is set to 2.5 GT/s x1 which is the minimum ~200 MB/s for PCIe but still much faster than USB 2.0 (~50 MB/s) or FireWire 800 (~80 MB/s).
Presonus support confirmed to me that the connection was correct looking at my hardware report. I would guess that the 2.5 GT/s x1 is plenty sufficient for audio so they implemented the lowest PCIe Thunderbolt chip inside the Quantum (at least, it’s the theory of one of my IT friend...).

USB2 (480 mbps)
This TB device: ~ 2 gbps in theory. Enough for 26 in/out audio streams you think?

**Answering myself by quoting Audient website:

« USB2.0 with a bandwidth of 480Mbps or 480,000,000 bits per second

44 channels * 96000 samples * 24 bit sample depth = 101,376,000 bits per second (100 mbps or ~ 12.5 mb/s) »

Thanks,

Patrice
 
Last edited:
At 70 C the fans should be spinning. Have you created a custom fan/power curve for your Vega? There is a complete guide here:
Thanks for the link.

  • I used VGTab_en_v0.2 to get VegaTab_56.kext
  • Copied VegaTab_56.kext to EFI->OC->Kexts
  • Used gfxutil-1.76b to find the device path in terminal
  • DevicePath = PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)/Pci(0x0,0x0)
  • Added the DevicePath to the config.plist
  • Copied aty_properties from VegaTab_56.kext
  • Pasted code to config.plist under properties
  • Verified no formatting or syntax errors in OpenCore Configurator
  • Reboot
And still no fans running...I know the guide is for Clover but I can see where they apply to OpenCore. Any ideas what I may have done incorrectly?
 
We should do this:
  • You can move the Ubuntu folder outside of the EFI folder.
    • Perhaps create a folder at the top level called OTHER and move the ubuntu folder there.
    • Also move the BOOT folder into the OTHER folder.
  • Now we will need to download the same version of Clover that is currently installed on that disk.
    • Now create a new folder inside "EFI" called "BOOT"
    • Then copy the BOOTX64.EFI file from the Clover package to the EFI/BOOT folder
  • Reboot
Success. I am now back in MacOS. What I did:

- Moved Ubuntu outside EFI folder and created OTHER folder. Also dropped the BOOT into the OTHER. Rebooted. Now Linux, nor Clover would boot and it defaulted to Windows 10 to boot next. Scratched my head.
- Used EasyUEFI in Windows to realize that it claimed the Clover Boot Manager was really in the Windows 10 drive... Why? So I did the following:

  1. Mount the correct EFI partition containing clover using Partition Explorer (can also be done in CMD). Assigned a drive letter.
  2. Go back to EasyUEFI, create a new boot list item, specify the path to Clover EFI.
  3. Move this new Clover Boot to top of the list.
  4. Reboot.
Of course, Linux did not show up inside Clover to boot from, but I will consider that my consequence for cheating on MacOS. At least she took me back, right? I will worry about Linux another time, not a concern or a priority.
 
Success. I am now back in MacOS. What I did:

- Moved Ubuntu outside EFI folder and created OTHER folder. Also dropped the BOOT into the OTHER. Rebooted. Now Linux, nor Clover would boot and it defaulted to Windows 10 to boot next. Scratched my head.
- Used EasyUEFI in Windows to realize that it claimed the Clover Boot Manager was really in the Windows 10 drive... Why? So I did the following:

  1. Mount the correct EFI partition containing clover using Partition Explorer (can also be done in CMD). Assigned a drive letter.
  2. Go back to EasyUEFI, create a new boot list item, specify the path to Clover EFI.
  3. Move this new Clover Boot to top of the list.
  4. Reboot.
Of course, Linux did not show up inside Clover to boot from, but I will consider that my consequence for cheating on MacOS. At least she took me back, right? I will worry about Linux another time, not a concern or a priority.
Any reason for skipping these steps?

Screen Shot 2020-10-29 at 3.48.44 PM.png
 
Any reason for skipping these steps?

View attachment 493597
I think after I tried your first step and couldn't figure out why both now didn't boot, I just created a new boot item, specified the path, and it booted. Wouldn't your second step have done the same thing?
 
I think after I tried your first step and couldn't figure out why both now didn't boot, I just created a new boot item, specified the path, and it booted. Wouldn't your second step have done the same thing?
In order for the system to boot, the EFI folder must contain:
  • BOOT/BOOTX64.efi
  • CLOVER/
Because we moved the original BOOT folder from EFI folder to OTHER folder, we needed to create a new EFI/BOOT folder as mentioned in the second set of steps.

In other words, both steps were necessary. Although I admit there are multiple ways of creating a new EFI/BOOT folder. But the system was guaranteed not to boot after just the first step.
 
In order for the system to boot, the EFI folder must contain:
  • BOOT/BOOTX64.efi
  • CLOVER/
Because we moved the original BOOT folder from EFI folder to OTHER folder, we needed to create a new EFI/BOOT folder as mentioned in the second set of steps.

In other words, both steps were necessary. Although I admit there are multiple ways of creating a new EFI/BOOT folder. But the system was guaranteed not to boot after just the first step.
This makes more logical sense than the way I have it. For some reason It looked like, because the timestamps were off, that the BOOT folder was overwritten by Linux so that's why I moved it outside. This is the way I have it right now and it's working as normal. Though, I will follow your suggestion and make the change
 

Attachments

  • EFI Updated.png
    EFI Updated.png
    140.1 KB · Views: 54
This makes more logical sense than the way I have it. For some reason It looked like, because the timestamps were off, that the BOOT folder was overwritten by Linux so that's why I moved it outside. This is the way I have it right now and it's working as normal. Though, I will follow your suggestion and make the change
I'm surprised that the system is booting without an EFI/BOOT/BOOTX64.EFI. Just when I thought the computing world, of all things, was black and white (zero and one)... ;)

Are you sure that disk is booting or is there an EFI/BOOT/BOOTX64.EFI located on another disk?

EDIT: Nevermind! That was done by EasyUEFI with a new boot entry.
 
Back
Top