kettek2/wiki/articles/zfs-macos-arch-linux-dual-boot.qwk

# Dual-boot High Sierra and Arch Linux with Shared ZFS
## Preface
Having had some failed system updates on my MacBook Pro5,5 that caused Mac OS to be nigh unusable, I decided to swap out the original 500GB HDD for a much smaller -- but much faster -- 128GB SSD I had on hand.

Although this is certainly a size constraint, I keep majority of my large data elsewhere and can easily access them via remote sharing or various web interfaces, so it is a moot point.

## The Notion
The original idea was to have three major partitions: Mac OS High Sierra, Arch Linux, and a shared partition that would store my user/home directory. The initial setup and install -- which took some time due to learning how to setup rEFInd and much fury at the more modern Disk Utility.app's insane pie chart partitioning system -- used HFS+ for High Sierra, Ext4 for Arch, and HFS+ for the shared partition.

The total partitions, with the important self-made ones noted, were:

| #   | Name       | Description                       | FS         | Size     |
|-----|------------|-----------------------------------|------------|----------|
| 1   | EFI        | EFI boot partition                | FAT        | 200 MB   |
| 2   | **Tyger**  | High Sierra system partition      | HFS+       | 36.6 GB  |
| 3   | Recovery HD| High Sierra recovery partition    | Apple boot | 619.9 MB |
| 4   | **Lyon**   | Shared partition                  | ?          | 55.9 GB  |
| 5   | **Lyger**  | Arch Linux system partition       | EXT4       | 18.3 GB  |

Before and after each of the Tyger, Lyon, and Lyger partitions I also placed 128MB of free space as per Apple's recommendations.

## The Problem
After the initial install of both Arch Linux and Mac OS -- along with rEFInd -- I was met with a potential problem. HFS+ write access under Linux is experimental and must be enabled with the force option during mount. Although I was uncertain as to what potential issues could arise from forcing R/W HFS+ access, as it seemed to work during initial tests, I did not feel comfortable with keeping HFS+ as the shared partition in the event of file loss or corruption.

After an initial review of the potentially shared options of NTFS, HFS+ R/W or using EXT4 via FUSE on Mac OS, I came to the conclusion that none of these were very good options. In the case of HFS+, it was uncertain what extended use would lead to, and in the case of EXT4, the only reliable EXT3/EXT4 R/W "driver" came at a bit of a cost (not much, by any means). NTFS was denied on the principle of it -- if I was triple booting, NTFS might have been the choice, although permission incompatibility would probably deny the shared user directory design.

With this, I then thought of another project I was working on...

## The Solution
Having recently delved into ZFS -- a filesystem I hadn't touched since late-2000s with Solaris -- for a Debian office server, I realized that the answer to my problems could potentially be **ZFS**.

A quick search revealed that the [OpenZFS on OS X](https://openzfsonosx.org) project had matured much since my last viewing (as I had noticed of the [ZFS on Linux](https://zfsonlinux.org) project some weeks prior).

I began first by installing and setting it up on Arch Linux, following the guide [here](https://wiki.archlinux.org/index.php/ZFS). Once this was complete, I simply issued the basic commands to setup a zpool:

    sudo zpool create Lyon /dev/sda5

With this, the zpool *Lyon* was created, allowing me to copy over my home directory and begin using it by setting my entry in `/etc/passwd` to point to the appropriate Lyon zfs volume. I rebooted into Mac OS and issued the standard `sudo zpool import` and discovered that the Linux-made ZFS pool had setup an extended Linux-centric option that rendered it only able to mounted as read-only in Mac OS. This would not do, so I issued `sudo zpool destroy Lyon` and recreated it on Mac OS. With this in place, I switched back to Linux and confirmed that it had R/W access to the same pool.

With the zpool working and visible between both, I decided to set up a generic *Users* volume within the *Lyon* zpool in the event of adding additional volumes or otherwise. This was merely a matter of issuing `zfs create Lyon/Users`, moving the Mac OS partition's *Users* contents to it, and setting up the appropriate mount paths. I additionally enabled the *com.apple.mimic_hfs* setting in the event that I might run into problems otherwise: `sudo zfs set com.apple.mimic_hfs=on Lyon/Users`.

On Mac OS, I backed up the root */Users* directory, deleted the original, issued `zfs set mountpoint=/Users Lyon/Users`, then moved the original */Users/* contents into the mounted share.

On Linux, I logged in as root, simply used the same */Users/* mount point and set my */etc/passwd* user entry to use */Users/kts*, as I do not know if it is possible to have a ZFS volume have different mount locations based upon the current host. Additionally, I modified my user entry in */etc/passwd* to use the same UID as used in Mac OS so there wouldn't be mismatched ownership. I additionally added a new group that matched Mac OS's *staff* GUID and made it my primary.

With all this in place -- and omitting some some minor mistakes along the way -- I safely rebooted back to Mac OS. However, upon attempting to login, it seemed the ZFS filesystem *Lyon/Users* was not automatically mounting on boot. To solve this -- and perhaps this is the wrong way to go about automounting ZFS -- I created two files responsible for mounting *Lyon/Users* on boot:

### /usr/sbin/mount-Lyon

    #!/bin/bash
    zfs mount Lyon/Users

### /System/Library/LaunchDaemons/net.kettek.Lyon.plist

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple$
    <plist version="1.0">
    <dict>
        <key>Label</key>
        <string>net.kettek.Lyon</string>
        <key>ProgramArguments</key>
        <array>
            <string>/usr/sbin/mount-Lyon</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
        <key>KeepAlive</key>
        <true/>
        <key>UserName</key>
        <string>root</string>
    </dict>
    </plist>

With these files in place, and with the appropriate root:wheel ownership set to both and the executable flag set on */usr/sbin/mount-Lyon*, I rebooted back to Linux, mounted the HFS+ boot as R/W, moved the old /Users to /Users2 (non-destructive move due to HFS+ driver spottiness), and rebooted back to Mac OS...

...And was met with the account setup dialog. I then presumed that, potentially, the zpools were not being loaded at the appropriate time. On this hunch, I checked */Library/LaunchDaemons* and saw multiple ZFS-related launch scripts. I thereafter moved these to */System/Library/LaunchDaemons* (although moving them to this directory seems to be highly discouraged by launchd documentation), rebooted, non-destructively moved the old "/Users" directory from Linux, booted back into Mac OS and was able to log in to my ZFS-based user just fine. To ensure everything was functioning properly, I rebooted and logged in to and from the Linux and Mac OS systems multiple times without error.

And, with that, it seemed that the ZFS filesystems were sticking and everything was working as desired!

**Finally, shared ZFS on Mac OS & Linux was a success!**