apianti Posted April 13, 2019 Share Posted April 13, 2019 (edited) 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 April 13, 2019 by apianti 1 Link to comment Share on other sites More sharing options...
vit9696 Posted April 13, 2019 Share Posted April 13, 2019 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. 2 Link to comment Share on other sites More sharing options...
apianti Posted April 13, 2019 Author Share Posted April 13, 2019 (edited) 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 April 13, 2019 by apianti Link to comment Share on other sites More sharing options...
vit9696 Posted April 13, 2019 Share Posted April 13, 2019 Well, this logic follows what Apple does, so that user would have had the same issue on a real mac. I am not sure we should change it. 1 Link to comment Share on other sites More sharing options...
apianti Posted April 13, 2019 Author Share Posted April 13, 2019 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. Link to comment Share on other sites More sharing options...
mhaeuser Posted April 14, 2019 Share Posted April 14, 2019 We will support dmg-booted Recovery in the near future and @Goldfish64 had been working on the code to download the required files too 2 Link to comment Share on other sites More sharing options...
apianti Posted April 14, 2019 Author Share Posted April 14, 2019 (edited) 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 April 14, 2019 by apianti Link to comment Share on other sites More sharing options...
mhaeuser Posted April 15, 2019 Share Posted April 15, 2019 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... 1 Link to comment Share on other sites More sharing options...
apianti Posted April 15, 2019 Author Share Posted April 15, 2019 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). Link to comment Share on other sites More sharing options...
Recommended Posts