Add boot.efi #138
Add boot.efi #138
Conversation
Naive question: what's wrong with
|
The problem is that I would be installing into a DMG file, and there is no way (that I know of) to set the GUID of a partition in a mounted DMG to the required one so it can be considered as a boot partition. I’ve tried |
|
Ah, I'm not using a DMG file - I added an extra harddisk to my macOS VM and am using that. Would it be possible to set the desired flags on a "physical" volume? |
|
I’m sorry, I should have been more clear. I am using a raw image as my “DMG file”. macOS doesn’t support loopback mount, but can mount a raw byte-for-byte filesystem image as a DMG. Disk Utility is the best way to create these images, and it outputs files using the .dmg extension. Since this is a raw image, I can easily have QEMU use that as its hard drive when booting the VM. I would never think of ever letting this code anywhere near a physical hard drive due to the risk of corruption. (Theoretically, wouldn’t you be able to point a command manipulating GPT at a device file and have it perform the same I/O to that device it does when run on an image file?) |
|
What I meant was create the image on a "physical" hard drive, which isn't really physical since I use macOS in a VM, then create an image of that using dd to use with QEMU inside the macOS VM. |
|
(Replying belatedly:)
|
wjk
force-pushed
the
boot.efi
branch
2 times, most recently
from
74f3214
to
3bec36a
Compare
|
Hey you are right LoopbackFS
<https://github.com/osxfuse/filesystems/tree/master/filesystems-c/loopback>,
is totally outdated last commit date 5 years ago
anyway thanks for the work
Am Sa., 11. Mai 2024 um 22:40 Uhr schrieb Bryce Glover <
***@***.***>:
… (Replying belatedly:)
…macOS doesn’t support loopback mount, …
1. macOS actually did have a loop(back) device 'driver' as recently as
10.14.6, if you weren't aware, if I'm understanding the correlation between
macOS and XNU version numbers correctly (though maybe only in development
kernel builds.) Refer to 'bsd/dev/vn'
<https://github.com/apple-oss-distributions/xnu/tree/xnu-8020.140.41/bsd/dev/vn>
in XNU's 8020.140.41 sources
<https://github.com/apple-oss-distributions/xnu/tree/xnu-8020.140.41/>
for its implementation as it last appeared before getting removed. (You'll
want to make special note of note 2 at the top of 'bad/dev/vn/vn.c'
<https://github.com/apple-oss-distributions/xnu/blob/xnu-8020.140.41/bsd/dev/vn/vn.c>,'
however.)
You could maybe start with that and port it forward. That only
helps once PureDarwin can be booted, though, of course. Or perhaps/maybe if
onew were really lucky, unlikely as that might be, that implementation
hadn't diverged too far from FreeBSD's at the time and the current upstream
implementation can just get merged back in again. (Though it might well be
rather surprising if that ended up being the case.)
2. macFUSE has a loop(back) filesystem implementation in LoopbackFS
<https://github.com/osxfuse/filesystems/tree/master/filesystems-c/loopback>,
but it's currently un-maintained. That also only helps from the macOS side.
—
Reply to this email directly, view it on GitHub
<#138 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEMNDMA4NOEJBYNPDFJNYLZBZ63BAVCNFSM6AAAAABBRTGPEWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGAZDMMBRGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
If anyone can help me out here, I am stumped on something. I am trying to locate the |
This will be used to make building boot.efi much easier.
|
I don't know about that myself, but your question has been forwarded on to the Discord server by csekel so you might get a response soon (just to let you know your question has been noticed). |
wjk
force-pushed
the
boot.efi
branch
2 times, most recently
from
436769d
to
f9f5cd9
Compare
|
@ninjadev64 Small update for you. Unfortunately, it doesn’t look like EFI is able to parse HFS+ filesystems natively, so |
This header contains a definition for NULL, as well as a copy of the strcmp() and strncmp() functions. It will be extended to contain an EFI-compatible malloc() implementation later.
These functions come from the boot-132 file i386/libsaio/xml.c. Symbols have been renamed and moved around to better clean up the source code.
These functions come from bopt-132 i386/libsaio/device_tree.c. Some symbols have been renamed for cleanup purposes.
|
(Continuing on from my earlier comment in earlier discussion of loop(back) mounts/filesystems:) Also, the FSKit user-space/user-mode filesystem API framework will be made available for public use as of macOS Sequoia (v15) (and its accompanying backup XNU kernel version) this fall. |
Let’s hope that they open source it |
Have you solved this problem? If not, it may come in handy: https://github.com/acidanthera/OpenCorePkg/tree/master/Staging/OpenHfsPlus. |
|
@AS5410-developer Looks useful, but it still doesn’t fix my main problem: how to determine which EFI volume the currently executing copy of |
Doesn't the boot argument "rd" tell the root device? |
Doesn't it stay loaded as a UEFI driver after running another efi program? |
This PR will add a simple implementation of
boot.efiusing the xnu-loading code from Apple’s boot-132, modified to function as 64-bit and under EFI.Note that I currently have no way to test this, because PureDarwin image creation has not yet been implemented.