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

Minor reformatting

master
kts of kettek (nanomo) 2018-08-09 04:43:39 -07:00
parent 9ae0b72901
commit 3d57c9f380
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -6,11 +6,13 @@ Having had some failed system updates on my MacBook Pro5,5 that caused Mac OS to
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 reason for this is that I primarily do cross-platform development and would like my two preferred operating systems to be available during travel.
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 Dreaded Pie Chart](zfs-macos-arch-linux-dual-boot/dreaded-pie-chart.png)](zfs-macos-arch-linux-dual-boot/dreaded-pie-chart.png) [![The Dreaded Pie Chart](zfs-macos-arch-linux-dual-boot/dreaded-pie-chart.png)](zfs-macos-arch-linux-dual-boot/dreaded-pie-chart.png)
From Linux's perspective, the total partitions, with the important self-made ones noted, were: From Linux's perspective, the total partitions, with the important three noted, were:
| # | Name | Description | FS | Size | | # | Name | Description | FS | Size |
|-----|------------|-----------------------------------|------------|----------| |-----|------------|-----------------------------------|------------|----------|
@ -18,14 +20,14 @@ From Linux's perspective, the total partitions, with the important self-made one
| 2 | **Tyger** | High Sierra system partition | HFS+ | 36.6 GB | | 2 | **Tyger** | High Sierra system partition | HFS+ | 36.6 GB |
| 3 | Recovery HD| High Sierra recovery partition | Apple boot | 619.9 MB | | 3 | Recovery HD| High Sierra recovery partition | Apple boot | 619.9 MB |
| 4 | **Lyon** | Shared partition | ? | 55.9 GB | | 4 | **Lyon** | Shared partition | ? | 55.9 GB |
| 5 | **Lyger** | Arch Linux system partition | EXT4 | 18.3 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. 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...