Does this project actually function?
OmerFlame opened this issue · comments
I recently tried messing around with the source code for this project and make it conform to the different macOS Monterey limitations that exist (for example, loading the kext from /Library/Extensions and not /System/Library/Extensions) as well as successfully performed filesystem trickery to successfully copy the mount_btrfs executable to /sbin in order to make the mount tool actually recognize the btrfs type when specified using the -t switch. However, getvfsbyname(btrfs, &vfs) in the mount_btrfs code here always fails and says that the kext wasn't loaded when it definitely is loaded.
Here is a video demonstrating this weird behavior:
Screen.Recording.2022-05-28.at.15.29.07.mov
After trying to look at the output of getvfsbyname in a test project, I can see that the function returns an error code -1, meaning that the virtual filesystem could not be found.
After seeing this happen, I started asking myself if this project actually functions. So, does it?
Nevertheless, this project seems to have a bit of potential if someone would take the job and start working on it.
After seeing this happen, I started asking myself if this project actually functions. So, does it?
No. This is kind of a weekend project that's been backlogged all year because of more pressing personal and professional stuff; the only "feature" implemented so far, is detecting that a filesystem is, in fact, BTRFS. Generally speaking, this serves my purpose of avoiding the annoying "this disk you inserted was not readable by this computer" notification I get when macOS boots up.
You have, however, hit the nail on the head with what's missing, and the next big goals of this repo (when I get around to it, or if someone is willing to contribute): the VFS portion of mount_btrfs, and the kext. For that purpose I've been slowly working on documenting the different structs in btrfs_filesystem.h, while copying some of the code from Apple's NTFS implementation to cut on time.
I hope this sheds some light on this repo's shortcomings, and I strongly encourage anyone interested in contributing to it to do so. I will leave this issue open, until some progress is made in, at least, the VFS plugin.
I see everything now. If I knew anything or knew how to implement support for VFSes, I would've contributed, but I don't know much about this.
Closing this issue.
@relalis would you kindly re-open this issue so that others (like me) stumbling across this project realize it's still a WIP?
Done. Until a BTRFS filesystem is mountable, this issue will remain open.
This is slightly unrelated to the issue, but since the author mentioned the current purpose of the project is avoiding the "unreadable disk" alert at boot, I am going to ask here
I am new and I am not 100% sure about how to install the built kext/binaries so the prompt disappears. I am using a Hackintosh and I tried injecting the kext using Clover instead of the /L/E method, and that might be the issue, but I am not sure as to how to install the binaries properly. Do I just need to copy the mount_btrfs to /sbin like @OmerFlame said?
If you think this message is unrelated I'll open a new issue
EDIT: Actually, it seems like I am having trouble with modifying the system snapshot to install the binary to sbin. is there a proper way to do it without disabling sip, editing snapshots in recovery etc.?
This is slightly unrelated to the issue, but since the author mentioned the current purpose of the project is avoiding the "unreadable disk" alert at boot, I am going to ask here
I am new and I am not 100% sure about how to install the built kext/binaries so the prompt disappears. I am using a Hackintosh and I tried injecting the kext using Clover instead of the /L/E method, and that might be the issue, but I am not sure as to how to install the binaries properly. Do I just need to copy the mount_btrfs to /sbin like @OmerFlame said?
If you think this message is unrelated I'll open a new issue
EDIT: Actually, it seems like I am having trouble with modifying the system snapshot to install the binary to sbin. is there a proper way to do it without disabling sip, editing snapshots in recovery etc.?
I haven't built a hackintosh in years to answer this with authority, so I'm afraid this would be a question better suited for the docs of your bootloader in question.
Apple changed the way Big Sur and onward load kexts and the only convoluted way I found to install unsigned kexts is to disable SIP, reboot, load the kext, and reboot, which I find even more annoying than dual-booting macOS and linux. I'm sure there's a simpler way to do it, but Apple's developer documentation is lacking on many fronts.
EDIT: Actually, it seems like I am having trouble with modifying the system snapshot to install the binary to sbin. is there a proper way to do it without disabling sip, editing snapshots in recovery etc.?
I managed to install the FS tool in /sbin only by modifying the system snapshot.
PLEASE DO NOT REPEAT THIS ON YOUR PERSONAL SYSTEM. I performed this on a fresh macOS install devised purely for testing on my Hackintosh setup (at the time - macOS Big Sur using the OpenCore bootloader) because I had important stuff on my main install that was too valuable to lose. Snapshot modification has a nonzero chance of causing irreversible corruption to your install. I managed to make the tool be recognized by the system but the tool didn't actually work, obviously. This is the right direction, but it's extremely difficult (and perilous) to execute!