Please Add Option For Using Locally Downloaded Builds of (Opencore, Clover)

[casioforever]

Dear @corpnewt, Some Environments Doesn't Have An Active Internet Connection, That's Why It Would Be Very Useful If The Users In Such Places, Can Put Their Downloaded Copies (From Github Or Elsewhere) Inside Main Folder of gibMacOS. Also The Tool Requests Files Ended With (*.tar.lzma) Which Isn't Helpful When Downloading The Latest Version Of Clover (V5155) Which Doesn't Have Such File For Its Relevant Version. gibMacOS Only Grabs r5153 of CloverHackyColor (Unlike Latest version of Clover-Builder Which Can Be Grabbed Successfully). I'd Be Grateful, If Your Amazing Tool Got Updated With USB Creation Using Locally Downloaded Builds Of Clover/Opencore. Thanks for Amazing Tool @corpnewt

[corpnewt]

Can you test out this commit and see if that can get the newer Clover versions - as well as allows the local archives? I've done some rather quick preliminary tests, but have not verified everything yet.

I added a new option in the main menu (L) which will prompt for a local archive - but if you intend to pass it a Clover archive, it still requires the C argument as well. Clover archives can be either .tar.lzma or .7z - OpenCore archives are expected to be .zip files.

-CorpNewt

[casioforever]

Hi @corpnewt It's Me, Again :) Your Modification Works As You Can See In That Screenshot Just Some Retouches Here And There :

1. The Problem #281 Can Now Be Closed, Which Caused By Following Syntax [drive Number] [options] r[clover Revision (Optional)] -----------that Line Needs To Be Replaced With------------- [drive Number] [options] r[opencore Revision (Optional)] --> The Line Shows That The Default Bootloader Will Be Clover, Which Is Not True, Because Clover Needs Option C To Be Used.

2. When Using The Following Syntax (Without L Option) : [drive Number] [options] r[clover Version (Optional)] The Result Always Be Based On Clover Versions By slice (CHC), Can You Optimize Your Code To Compare Input Before Applying The Final Command? I Mean [drive Number] [options] r (N) If N<=5122 Then The Tool Gets The Version Made By Dids. (Clover Wo. Oc Augments). If N>5122 Then The Tool Gets The Version Made By Slice (Clover W. Oc Augments).

3. Can You Please Integrate Ddrelease64.exe Into Your Tool ? Downloading That Component On Every Time I Need To Use Your Tool Is Really Annoying Task. I Thought The Bug Was On Your Side Until I Discovered Its Absence From Your Files.

4. Can You Integrate Rufus 2.18 (Xp, Vista) Or 3.22 (7sp1+) ? Using Your Tool again For Mbr Formatting Causes This Strange Error And When Used again For Gpt Formatting Causes This Strange Error This Errors Can Be Solved Using Rufus. If You Can't Integrate It, Do You Have A Solution? finally, Thanks For Quick Response And For Hearing Carefully To Your Community. Have A Nice Day.

[corpnewt]

Hey there - glad it fixed the initial issue. Regarding the list of additions:

1. I'll look into that and see about closing it when I have time, but worth noting that I updated the syntax of the example to include C to imply the Clover revision used. When using OpenCore, it always gets the latest, there is no r[OpenCore revision]. The current example usage is as follows:

   Usage: [drive number][options] r[Clover revision (optional)]
   (eg. 1B C r5092)

   But I could change it so that it states the following for clarity:

   Usage: [drive number][options] r[Clover revision (optional), requires C]
   (eg. 1B C r5092)

2. Is there an advantage to using Dids builds? I haven't touched Clover for a number of years, so I'm not up to speed on what works and where. If it's just that CHC doesn't provide older builds - I can look into making that more flexible though.

Regarding the ddrelease and rufus questions - I'd rather not host tools that have active pages where possible - as that can violate the authors' licensing. I attempted to look into the BOOTICEX64.exe license when adding it - but was unable to find any info on the original author (referenced as pauly or iPauly depending on where you look). If asked, I'll remove that tool from this repo and pull from a hosting site of their choosing.

I know that diskpart can be picky - but I tried to rely as little on third party tools as I can. I may look into other solutions at some point, but with OpenCore's dmg loading capabilities and the advent of macrecovery.py, I've not spent nearly as much time maintaining this project - so I cannot promise I'll devote a ton of time to it.

-CorpNewt

---

Just a small edit - I pulled up the about for BOOTICE, and it seems that the dev does not restrict distribution as long as it's for non-commercial purposes, so that should be fine to keep hosted in this project.

[casioforever]

Hi @corpnewt, Thanks for Quick Response

1. This Suggestion Would Be Very Nice, Win-Win For All Sides :

   Usage: [drive number][options] r[Clover revision (optional), requires C]
   (eg. 1B C r5092)

2. Clover-builder R5122 (Made By Dids) Doesn't Contains Any Opencore Modifications, I've Faced Many Hackintoshers Which Got Stuck In Problems Because Of Instability Of Cloverhackycolor After Being Augmented With Opencore In Its Recent Releases By (Slice) Such As R5155. This Can Be Resolved By Your Latest Modification Of Makeinstall (i mean providing dids releases locally through your amazing tool). But, For The Integrity Of Your Code, It'd Be Awesome If Your Tool Can Be Automated To Search For Revisions According To Number 5123 (N<5123 >>> Get Dids Releases) (N>5123 >>> Gets Slice Releases).

3. Regarding Ddrelease64 & Rufus, I Understand Your Concerns. At The End, You Know About Software Licenses Better Than Me.

4. No Need To Remove Diskpart Scripts, It Is The Only Way To Integrate Bootloaders Successfully On Usb Flash Drive. Trust Me, Among Many Tools To Create MBR\GPT Partition Scheme For Opencore\clover Usb Loader, The Diskpart Hits The Mark Precisely. I Just Can't Override Its Errors When Using Your Tool Again, And Again. Thus, I Run For The Help Of Rufus Tool. If You Found A Way To Format Usb Driver Before Using Diskpart Commands, No One Will Complain From Diskpart Errors Anymore.

Have A Nice Day !

[corpnewt]

Alright - as of this commit it should pull from the proper place depending on the r[version] passed. I also updated the example usage in the main menu to clarify the r[version] section is for Clover specifically.

I can look into skipping portions of the diskpart code in the event you've already formatted a disk I suppose - that's not something I'll likely be able to implement quickly though, and will likely take a fair bit of time. Currently, there's the B option which only attempts to install the bootloader to the first partition of the disk - but I could also implement some other flag to skip attempting to format.

Please let me know if the above commit works as expected, and I'll see if there's a sane way to skip using diskpart to format.

-CorpNewt

[corpnewt]

Alright - that wasn't as painful as I thought. I fixed a couple bugs, updated some singleton comparisons, and added another main menu flag (F) that allows skipping formatting of the drive. Due to the way dd works though, it still requires the drive's first partition be FAT32 and second be RAW.

The commit is here if you want to check it out.

I imagine that covers most of the requested additions - please let me know if you have more questions.

-CorpNewt

[casioforever]

Hi @corpnewt Here Is My Timeline of Testimonials :

1. First Screen First ! (USB Formatted As MBR Using Windows)
2. Writing 6C r5122 (CURRENT PARTITION SCHEME :MBR)
3. Writing 6FC r5155 (CURRENT PARTITION SCHEME :MBR)
4. VVV (Verification Via Vmware) (CURRENT PARTITION SCHEME of USB :MBR)
5. Writing 6GC r5122 (CURRENT PARTITION SCHEME :MBR) | Solved by Un-plug USB Then Re-plug USB
6. Writing 6GC r5122 (CURRENT PARTITION SCHEME :MBR)
7. Writing 6FC r5155 (CURRENT PARTITION SCHEME :GPT)
8. VVV (Verification Via Vmware) (CURRENT PARTITION SCHEME of USB :GPT)
9. Writing 6C r5155 (CURRENT PARTITION SCHEME :GPT)

Notes : A. No Usage of Rufus (At Alllllllllllllllll) B. No Usage of Options B, E, U, L & D What Do You Think ? -Casio4Ever

[corpnewt]

I take it that aside from the instance where diskpart failed to format, the rest went alright?

-CorpNewt

[casioforever]

I take it that aside from the instance where diskpart failed to format, the rest went alright?

The Diskpart Only Fails In Very Specific Condition :

1. When 200 Mb Partition Only Is Visible
2. When Converting Usb From Diskparted (Mbr) To Diskparted (Gpt)

Other than that, Everything Is Awesome 👍 💯 🥇

[corpnewt]

Glad to hear it. I'll go ahead and mark this issue thread as solved then.

-CorpNewt