HackinDROM App for OpenCore EFI Creation and Update

[Inqnuam]

- and the opencore version is not represented (it says 0.0.0)

Will fix this

 

[CaseySJ]

Seems like @CaseySJ dont want to upload new OC versions to HackinDROM. If it is the case then ill update the app to allow everyone updating OC without waiting for someone to upload new EFIs to the app.
The app is already ready for standalone OC updates

Only for OpenCore 0.7.5 I thought it was good for everyone to follow manual method so they can reacquaint themselves with the process.

Starting with OpenCore 0.7.6 I will use HackinDROM again.

 

[joostiphone]

Only for OpenCore 0.7.5 I thought it was good for everyone to follow manual method so they can reacquaint themselves with the process.

Starting with OpenCore 0.7.6 I will use HackinDROM again.

There are positives and negatives to both methods I guess.

HackinDrom to update based on standalone updates
Pro's
- Faster EFI distribution
- Not depending on 1 owner of the EFI

Con's
- Less proven EFI and more open to configuration errors overall

Uploaded by a Golden Build/proven build
Pro's
- Proven EFI and fewer configuration errors overall

Con's
- Slower EFI distribution
- Depending on 1 owner of the EFI


In general, as I look at it, Hackindrom is designed to make it easier for end-users to update OpenCore and it's easier for EFI builders to distribute the EFI. So perhaps the user can choose in Hackindrom if they would like to update based on the standalone OpenCore updates, or proven EFI builds?

 

[MacArthur]

@joostiphone I don't understand when you say:
"HackinDrom to update based on standalone updates" "Not depending on 1 owner of the EFI"
I understood that the EFI was submitted to Inqnuam and/or Casey for validation by one poster who created/modified initially. Therefore there is only one initial owner who can upload and update it (or not ;-) ).
I saw a few posts of some contributors who proposed their EFI on some missing setup for approval

 

[joostiphone]

@joostiphone I don't understand when you say:
"HackinDrom to update based on standalone updates" "Not depending on 1 owner of the EFI"
I understood that the EFI was submitted to Inqnuam and/or Casey for validation by one poster who created/modified initially. Therefore there is only one initial owner who can upload and update it (or not ;-) ).
I saw a few posts of some contributors who proposed their EFI on some missing setup for approval

Inqnuam said:

If it is the case then ill update the app to allow everyone updating OC without waiting for someone to upload new EFIs to the app.

If Inqnuam will release a version where the EFI becomes updated by the app/everyone based on the latest OpenCore release, not by a Golden build owner/verified user, then we are not depending on 1 owner such as myself for the 9020 USFF build, or CaseySJ for the Z390 for example.

 

[MacArthur]

Well, maybe I missed something.
The application is developed to update the EFI by itself? I rather suspect that @Inqnuam has the EFI or 390 on some of his machine and therefore can update and upload it.
But maybe I am wrong

 

[Inqnuam]

@joostiphone @MacArthur
Actually there will no be any difference between updating with "standalone" mode and admin posted EFI. Because in any way HackinDROM bases on users config.plist up make the update.
For proof of concept you can for example select any build in your Settings then Update your OC by selecting/unselecting needed kexts aml drivers. In standalone mode we dont need to select any kext or else, the app will update your existing modules and nothing more will be added
Also standalone mode is optional, it will be available in context menus of EFI list

 

[joostiphone]

Well, maybe I missed something.
The application is developed to update the EFI by itself? I rather suspect that @Inqnuam has the EFI or 390 on some of his machine and therefore can update and upload it.
But maybe I am wrong

Inqnuam is not testing all EFI's uploaded by the verified users (he simply does not own all of these systems). We, as users, trust the verified uploaders to have certain knowledge on the build they are willing to share with us by means of the EFI.

I'm a verified user and I'm uploading the updated EFI every time an OpenCore update comes out. I tested the EFI on my 9020 USFF build for a few days, to make sure it works for all the users who are using the same build.

 

[MacArthur]

Edit
did not see your previous reply
It's clear....
This I understand !
Let's imagine now that you don't update your efi for 6 months.
The EFI that users will get while connecting to the apps will remain based on OC 0.75?
Or the application by itself will update your EFI to the latest OC release every month?
Sorry I am slow this evening

 

[Inqnuam]

Well, maybe I missed something.
The application is developed to update the EFI by itself? I rather suspect that @Inqnuam has the EFI or 390 on some of his machine and therefore can update and upload it.
But maybe I am wrong

Details update the update process
(you can find full procedure in source code on GitHub!)

When you mount your EFI partition the app based on your selected Build in Settings compares your local OC version of your mounted EFI to the latest EFI posted by your EFI provider
If your version is lower than what is uploaded to the database then you see "Update OC" button
After clicking on "Update OC" the app merges your kexts amls and drivers with provider's OC EFI and presents to your the sidebar with AML Kexts Drivers where you decide what you need to update and/or enable

During the update process OC is updated from provider uploaded EFI
for each aml driver kext you have selected the app checks if they are present in providers EFI then "download" it for you if they are newer than yours
If any selected driver kext isn't present in providers EFI then the app checks for a newer version on GitHub and download it for you
Finally providers config.plist is taken as base for the new version and every field's values are checked in your local config.plist
If your local field type is the same as in providers plist then your local value is imported into the new config.plist.
Any field that is not present in your local config.plist and it is required by OC will take providers defined value