kts
/
kettek2
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Wow, more ZFS stuff

master
kts of kettek (nanomo) 2018-08-09 00:45:45 -07:00
parent 4ec611cf8c
commit a491ae81d1
1 changed files with 14 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
wiki/articles/zfs-macos-arch-linux-dual-boot.qwk
View File

@ -1,11 +1,11 @@
[[toc]] [[toc]]
## Preface # 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. 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. 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 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 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: The total partitions, with the important self-made ones noted, were:
@ -20,25 +20,30 @@ The total partitions, with the important self-made ones noted, were:
Before and after each of the Tyger, Lyon, and Lyger partitions I also placed 128MB of free space as per Apple's recommendations. 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 # 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 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. 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... With this, I then thought of another project I was working on...
## The Solution # 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**. 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). 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: 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 sudo zpool create Lyon /dev/sda4
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 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 `sudo zpool create Lyon /dev/disk0s4`. 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`. 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:
sudo zfs create Lyon/Users
sudo zfs set com.apple.mimic_hfs=on Lyon/Users
and thereafter moving the Mac OS partition's *Users* contents to it and setting up the appropriate mount paths. As noted, I additionally enabled the *com.apple.mimic_hfs* setting in the event that I might run into problems with programs such as Photos (as indicated by the OpenZFS wiki).
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 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.
@ -46,12 +51,12 @@ On Linux, I logged in as root, simply used the same */Users/* mount point and se
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: 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 #### /usr/sbin/mount-Lyon
#!/bin/bash #!/bin/bash
zfs mount Lyon/Users zfs mount Lyon/Users
### /System/Library/LaunchDaemons/net.kettek.Lyon.plist #### /System/Library/LaunchDaemons/net.kettek.Lyon.plist
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple$ <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple$