Network boot #554
Closed
Network boot #554
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Sep 7, 2024
mikebeaton
force-pushed
the
network-boot
branch
2 times, most recently
from
31464d1
to
5411680
Compare
This partially reverts #545.
Apparently macOS strips down HD nodes from VirtIO BLK devices leaving them "infix" shortened, i.e. PCI/APFS instead of PCI/HD/APFS.
While FixupAppleEfiImages is generally not needed, OpenDuet, VMs, and some other firmware need it for proper macOS booting. Given that the quirk is generally harmless, enable it in the samples.
mikebeaton
force-pushed
the
network-boot
branch
from
5411680
to
a5ed2da
Compare
mikebeaton
force-pushed
the
network-boot
branch
from
a5ed2da
to
d63bd2b
Compare
|
Closed in favour of #562. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Assuming the Unload and rename changes were merged, this is what the network boot PR would look like.
I haven't changed the approach to intrinsic lib here yet. I'm planning that that can be addressed on a separate PR to audk, with appropriate very small changes here when finalised. (I'm actually wondering whether the CryptoPkg IntrinsicLib might not be the best one to use; and also wondering whether moving it to MdePkg really makes sense - if it's just going to make future rebases on EDK 2 harder? Anyway, I'll make a PR or two to audk as a place to finalise the intrinsic lib issue.)
There are also a couple of other minor PRs related to the network boot PR that I want to make on audk (e.g. to downgrade some unecessarily verbose logging in the network stack), but they don't stop this working.(Done.)