From 85e2640471aa5a341ab488f7bcf0183a547bd424 Mon Sep 17 00:00:00 2001 From: hygienic-books Date: Mon, 27 Mar 2023 23:15:46 +0200 Subject: [PATCH] docs(os): We scan for a zpool in /dev/disk/by-partuuid now, (#3) --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index d52edff..c060ff6 100644 --- a/README.md +++ b/README.md @@ -304,7 +304,7 @@ The ZFS pool and dataset setup that makes this tick, explained in plain English. 1. For a `zpool/data/home` child dataset: 1. We do not specify any properties. Since `canmount` cannot be inherited the parent's `canmount=off` does not apply, it instead defaults to `canmount=on`. The parent's `mountpoint=/` property on the other hand is inherited so for a `home` child dataset it conveniently equals `mountpoint=/home`. 1. In effect this `zpool/data/home` dataset is subject to `zfs mount -a` and will happily automount into `/home`. -1. We export the zpool once, we then reimport it by scanning only inside `/dev/disk/by-id`, again setting `-R /mnt` as we did during pool creation a moment ago and we do not mount any file systems. +1. We export the zpool once, we then reimport it by scanning only inside `/dev/disk/by-partuuid`, again setting `-R /mnt` as we did during pool creation a moment ago and we do not mount any file systems. 1. We `zfs load-key ` which will load the key from `keylocation` after which the `keystatus` property for `` and all child datasets will change from `unavailable` to `available`. 1. We mount our Arch Linux boot environment dataset. It automatically get prepended with `-R /mnt` since that's how we imported the pool. 1. We `zfs mount -a` which automounts `zpool/data/home` into `/home`, which again gets auto-prepended by `/mnt`.