Contribute
Register

EFI Agent v1.3.2 (menu bar utility)

Yikes ... 1.6 Gig of RAM in 8 hours thats some memory leak ...

I'm still running MountEFI V1.1.7 ... machine has been running for about two days ...
No sign of memory leak so maybe it's something that crept in, in one of the more recent releases ?

Screenshot 2019-04-13 at 18.30.16.png

Cheers
Jay
 
MountEFI 1.2.0 Released
- Tools to delete APFS container or converting HFS to APFS
- Updated app icon


@headkaze,

Question for you buddy ....

Is the Convert HFS to APFS feature in the new release non destructive ?
Just curious as may have a use for it soon ...

Cheers
Jay
 
Is the Convert HFS to APFS feature in the new release non destructive ?
Just curious as may have a use for it soon ...

No, it's equivalent to "diskutil deleteContainer disk*" so it will format the APFS partition back to HFS. You can read more about "diskutil deleteContainer" here.
 
@headkaze,

Could you please explain how you extrapolate the boot device from IODeviceTree:/chosen/boot-device-path.

Just wondering if i can inject it using a codeless kext so that EFI Agent can highlight the correct device on my desktop.

Cheers
Jay
 
Last edited:
@headkaze,

Could you please explain how you extrapolate the boot device from IODeviceTree:/chosen/boot-device-path.

Just wondering if i can inject it using a codeless kext so that EFI Agent can highlight the correct device on my desktop.

Cheers
Jay
It would be easier to write to IODeviceTree:/options/efi-boot-device. Give me a bit and I'll write a feature to set this for you to try.
 
It would be easier to write to IODeviceTree:/options/efi-boot-device. Give me a bit and I'll write a feature to set this for you to try.


@headkaze,

I was thinking about such a feature earlier but did not want to bother you something that probably only effects a very few users like me who boot MacOS in an unusually way such as booting from a different partition to the one on the system drive.

Basically what i was going to propose was if EFI Agent is unable to get a valid/matching device id or volume UUID from IODeviceTree:/chosen/boot-device-path or IODeviceTree:/options/efi-boot-device then you could enable a right click context menu item on the EFI Partition list called "Mark as Boot Device" .. you could then add a custom variable to NVRAM with the volumes UUID which would then be referenced by EFI Agent and Hackingtool. Using a custom variable would ensure that it does not upset MacOS .... there would be no need to add code to remove the custom NVRAM variable as it can be done using Hackingtool's NVRAM (-) option.

However I do find it very strange that on both my Laptop and Desktop there is no efi-boot-device NVRAM variable so maybe setting that makes more sense as i guess it could fix what is wrong (missing) ....

Will be interesting to see what you come up with .... :)

The only reason I was trying to sort it myself is that on my desktop system I have 4 or 5 GUID drives that have very similar device names so having EFI Agent and Hackingtool id the boot EFI with the green highlight makes it obvious which one it is and as we have already discussed get around the problem of MacOS randomly changing the BSD name.

Thanks for taking the time to look in to it .... appreciate it buddy.

Cheers
Jay
 
Last edited:
Back
Top