Does this project actually function?

[OmerFlame]

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:

https://user-images.githubusercontent.com/17903236/170825563-ee6fad35-8d37-431e-b659-45c914ff6930.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.

[relalis]

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.

[OmerFlame]

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.

[taylorkline]

@relalis would you kindly re-open this issue so that others (like me) stumbling across this project realize it's still a WIP?

[relalis]

Done. Until a BTRFS filesystem is mountable, this issue will remain open.

[alessaba]

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.?

[relalis]

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.

[OmerFlame]

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!