[Guide] How to keep Clover working when installing Windows and Linux

[jpz4085]

Looks like Windows is on the WDC WD20EARX-22PASB0 and Catalina is on the KINGSTON SV300S37A240G.

Does the "bootclover" entry work if you manually select it from the firmware boot menu?

The Windows Boot Manager and the two other UEFI disk entries are listed before it so they will boot first. You may just need to change the order if "bootclover" works.

The problem is I am not quite sure how the firmware eventually saw the HDD as a UEFI device. Possibly occurred with an nvram reset by OC. Do remember being stricken that the OC nvram reset changed things in the firmware settings like boot order.

Yes, the OC nvram reset will wipe the UEFI boot entries and order. The firmware will then automatically rebuild the list with default entries in the order the disk/partitions exist.

 

[chumdoggin]

No. Bootclover was made with bootice and was pointed at efi/clover/cloverx64.efi seemed to have worked in other systems before.

got oc to reset nvram and ssd still is just seen as hard drive. Not sure what it was that i did that made the Toshiba usb and the hard drive to be recognized as uefi devices.

played with some jumpers on bios to try to update it maybe. So many variables to pay attention to. need to be more systematic in this work.

 

[jpz4085]

No. Bootclover was made with bootice and was pointed at efi/clover/cloverx64.efi seemed to have worked in other systems before.

Then Clover is not actually installed where ever "bootclover" is pointing to.

got oc to reset nvram and ssd still is just seen as hard drive. Not sure what it was that i did that made the Toshiba usb and the hard drive to be recognized as uefi devices.

Open Terminal and type "diskutil list" then mount any EFI partitions and check which one has Clover installed.

 

[chumdoggin]

Then Clover is not actually installed where ever "bootclover" is pointing to.

Open Terminal and type "diskutil list" then mount any EFI partitions and check which one has Clover installed.

Just went in and ran the clover 5148 pkg on the EFI of the Kingston and realized it added nothing to the boot folder and removed the cloverx64.efi. Odd ok but got the zip version and put the boot folder and the clover boot file where it usually goes before using bootice and recreated the cloverboot entry but no go. Used the NVRAM reset from OC and it gets rid of the cloverboot entry.

Maybe its the firmware is just old. I have had it freeze after saving a couple times. Maybe the cmos battery needs a new one. Seems to be the most logical explanation.

 

[jpz4085]

Just went in and ran the clover 5148 pkg on the EFI of the Kingston and realized it added nothing to the boot folder and removed the cloverx64.efi.

You might want to review the instructions here if trying the install package again. The only difference is you'd be installing to the SSD.

...got the zip version and put the boot folder and the clover boot file where it usually goes before using bootice and recreated the cloverboot entry but no go.

Attach a screenshot of the Kingston EFI folder with all subfolders expanded so I can check the structure. A screenshot of the "diskutil list" output in Terminal could be helpful too.

 

[chumdoggin]

You might want to review the instructions here if trying the install package again. The only difference is you'd be installing to the SSD.

Attach a screenshot of the Kingston EFI folder with all subfolders expanded so I can check the structure. A screenshot of the "diskutil list" output in Terminal could be helpful too.

Tried changing the cmos battery but that did not work with trying again with entries in both linux and bootice. Also did a diskutility first aid on the two that work, the usb and the HDD which reported corrupt file structures on the EFIs. Got them repaired and copied over the version preferred in case they had copied over something corrupt from before but it did no good either.

Just looking at the diskutil list read out. Not sure of the normal order but the SSD named catalina drive shows first at zero (expected that is where it is) but what I did not expect was the Exfat disk to show next before the rest of the SSD. Anyway the EXfat disk is one I threw into the removable drive tray at the front of the machine. Just juggled around some of the cables so I could get the SSD at 0.

The file structure on the target may be right, but until the firmware will recognize the device is UEFI it will refuse to acknowledge it. It was the same for the other ones that work now but how they came to be I am still not sure. At this point I will look up the issue on these machines "Predator G3610" but does not seem to have a problem with windows or linux structures.

 

[jpz4085]

The file structure on the target may be right, but until the firmware will recognize the device is UEFI it will refuse to acknowledge it. It was the same for the other ones that work now but how they came to be I am still not sure. At this point I will look up the issue on these machines "Predator G3610" but does not seem to have a problem with windows or linux structures.

Yeah, the file structure looks fine and there are no other obvious problems. The last suggestion I can think of is to remove all drives from the machine and clear the NVRAM then reattach only the macOS SSD and see if it shows up. If so add the others one by one.

Looks like possibly a firmware related bug. You might want to check if there's a newer version BIOS available.

Also make sure Fast Startup is disabled in the Windows power settings. That's all I can think of at this point.

 

[chumdoggin]

Yeah, the file structure looks fine and there are no other obvious problems. The last suggestion I can think of is to remove all drives from the machine and clear the NVRAM then reattach only the macOS SSD and see if it shows up. If so add the others one by one.

Looks like possibly a firmware related bug. You might want to check if there's a newer version BIOS available.

Also make sure Fast Startup is disabled in the Windows power settings. That's all I can think of at this point.

Hey thanks,

I was thinking about trying some of those ideas. Tried to update bios once and got wrong size error. Should double check that it was the right one.

Update: Yep that was what the doc ordered, started working when rebooted with the SSD being the only disk available. Clover did not work at first but copied over the best working EFI folder and the name changed from "UEFI (not UEFI device)DeKingston" to as the pic here shows... after clover first started on it.

 

[chumdoggin]

Yeah, the file structure looks fine and there are no other obvious problems. The last suggestion I can think of is to remove all drives from the machine and clear the NVRAM then reattach only the macOS SSD and see if it shows up. If so add the others one by one.

Looks like possibly a firmware related bug. You might want to check if there's a newer version BIOS available.

Also make sure Fast Startup is disabled in the Windows power settings. That's all I can think of at this point.

Hi,

Ran into the problem again and found the more solid solution. In case anyone runs into this.

[SOLVED] BIOS does not load any bootloader in UEFI mode / Installation / Arch Linux Forums

bbs.archlinux.org

Nifty little article. Had got to a place where even though the system was seeing the drive as UEFI when it was the only drive, would not see the efi contents.

 

[jpz4085]

Nifty little article. Had got to a place where even though the system was seeing the drive as UEFI when it was the only drive, would not see the efi contents.

Interesting. So the attributes were wrong for the EFI folder? I'm curious, how was the EFI partition and folder structure created?