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

Perhaps final closure on ZFS

master
kts of kettek (Tyger) 2018-08-09 03:30:03 -07:00
parent cb900f19b1
commit 400b02a358
1 changed files with 3 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -49,38 +49,8 @@ On Mac OS, I backed up the root */Users* directory, deleted the original, issued
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:
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 mounted to */Users* when I logged in. After some research into the matter, it appeared that mounting ZFS volumes takes some time to actually mount. After some initial tries with some basic LaunchDaemon scripts, I discovered [ZFSLoadCheck](https://github.com/alexwasserman/ZFSLoadCheck), a rather simple LaunchAgent application that polls for a hidden dot file in the */Users* location and lets you know if it finds that file or not. It does so by showing a small dialog on the Login screen that updates about every 5 seconds to let you know if it is yet time to login.
#### /usr/sbin/mount-Lyon
After putting **ZFSLoadCheck**'s files into place, I rebooted between Mac OS and Arch Linux multiple times and was able to log in perfectly each time -- providing I waited a few moments for the ZFS volumes to actually mount.
#!/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!**
And, with that, finally, **shared ZFS on Mac OS & Linux was a success!**