Jump to content
9 posts in this topic

Recommended Posts

I can't figure out a place to actually open an issue for the AppleSupportPkg so I am posting here hoping @vit9696, @Download-Fritz, @savvas, @vandroiy2012, or @TheRacerMaster with see this and resolve an issue. There appears to be a mistake in the connection of the apfs.efi loaded from an APFS container and which driver's binding will actually be used to connect. I would point you to this call:

https://github.com/acidanthera/AppleSupportPkg/blob/master/Platform/ApfsDriverLoader/ApfsDriverLoader.c#L195

The second parameter is passed as NULL, so this attempts to use every installed EFI_DRIVER_BINDING_PROTOCOL interface. When you have multiple APFS containers, which this driver will then load multiple apfs.efi drivers, which driver binding is used to connect the controller? Shouldn't this be supplied in the call? Otherwise, this does not seem to ensure connection with the driver that was loaded from that container and the controller handle for the container but whichever apfs.efi's EFI_DRIVER_BINDING_PROTOCOL gets the first chance at connecting. Instead, there should be an enumeration of all EFI_DRIVER_BINDING_PROTOCOL interfaces, and every one that has EFI_DRIVER_BINDING_PROTOCOL->ImageHandle the same as the driver's image handle, the binding's handle should be put in a NULL terminated list and passed as the second parameter.

Also, is there a way to maybe cause a fallback for APFS containers that either have no apfs.efi embedded or the driver fails check? Like determining which is the latest and after connecting each controller it was connected to, go through and use that driver to connect any controllers that failed? Or embedding the latest apfs.efi in the driver itself that is used when the driver fails being loaded from the APFS container?

 

EDIT: The binding's handle should go in the list not the image's.

Edited by apianti
  • Like 1

Thanks, we are aware of this issue, and will handle it in the upcoming ApfsDriverLoader update, which is currently in the works.

I created an issue for easier tracking: https://github.com/acidanthera/bugtracker/issues/298

 

As for connecting "the default" apfs driver or not, this is to be considered later.

  • Like 2

Cool, thanks @vit9696. As to the fallback, although an obvious edge case that he caused, I just had a user with an issue here that was caused by this, he had to revert to using apfs.efi directly instead:

 

Edited by apianti

Yes, but if something happens to the disk and it is corrupted or the user does make a mistake. If the user did this on a mac, they can enter internet recovery from firmware. This is not the case without apple firmware.

Oh, that's cool. How would this be implemented? Like you mean the recovery disk image would need to be on an accessible volume? Or that the image will be downloaded? Also, completely unrelated but I'm surprised one of you hasn't attempted to determine the protocol for target disk mode.

 

EDIT: There may be a problem that there may not be network drivers available to actually connect to the internet in a lot of firmwares, especially wifi...

Edited by apianti

As for OpenCore directly, the image must be on an accessible volume and we might set up a protocol (that'd mean RAM was fine too), I'm not sure what Goldfish64's plan with the download code is. Downloading in-OS will be fine either via CorpNewt's gibMacOS, or via vit's Recovery downloader script which is yet to be released

Target Disk Mode seems pretty uninteresting to me at this point, maybe for some future...

  • Like 1

Okay, this is what I thought but it doesn't solve the issue of if you can't boot and don't already have things in place to do such a thing... I have no interest in TDM really either (although it gets asked about a lot) but I'm still surprised one of you hasn't reversed the TDM module(s).

×
×
  • Create New...