Compare commits

...

4 Commits

Author SHA1 Message Date
85e2640471 docs(os): We scan for a zpool in /dev/disk/by-partuuid now, (#3) 2023-03-27 23:15:46 +02:00
535073a3c2 docs(os): Typo (#3) 2023-03-27 23:13:00 +02:00
412eb93c60 docs(os): Typo (#3) 2023-03-27 23:10:47 +02:00
0cd149f8cb docs(os): Typo (#3) 2023-03-27 23:00:19 +02:00

View File

@@ -75,10 +75,11 @@ export ARCHZBM_ZFSPROPS_NO_ENCRYPTION=yup
## Steps
The scripts takes the following installation steps.
The script takes the following installation steps.
1. Install ZFS tools and kernel module with [github.com/eoli3n/archiso-zfs](https://github.com/eoli3n/archiso-zfs)
1. Create one encrypted ZFS zpool on top of `BF00` partition, password `password`
1. Create one ZFS zpool on top of `BF00` partition, encrypted and compressed datasets, password `password`
1. _See paragraphs [Compression](#compression)/[Encryption](#encryption) to optionally disable properties_
1. Create dataset for Arch Linux and `/home`
1. Install Arch Linux into pool
1. Add ZFSBootMenu to `EF00` partition if it doesn't exist already
@@ -216,7 +217,7 @@ In order to generate a new master key after you've changed your user key as ment
- With `-v` we get verbose progress output
- Argument `-u` makes sure the dataset does not get mounted after transfer. ZFS would mount it into `/` which wouldn't be helpful since we're currently using that filesystem ourselves.
- We set encryption properties `keyformat`, `keylocation` and most importantly `encryption`. The latter will turn our transferred dataset into its own `encryptionroot` which in turn generates a new master key. The auto-generated new master key gets wrapped with our updated passphrase in `keylocation`. This basically reencrypts all data in this dataset during transfer.
- We set `mountpoint` and `canmount` as well as a `org.zfsbootmenu:commandline` as we would for any new system dataset.
- We set `mountpoint` and `canmount` as well as an `org.zfsbootmenu:commandline` as we would for any new system dataset.
1. Change zpool's `bootfs` property to new system dataset
```
zpool set bootfs=zpool/root/archlinux-frn zpool
@@ -290,7 +291,7 @@ The ZFS pool and dataset setup that makes this tick, explained in plain English.
1. `-O keyformat=passphrase`: Controls what format the user's encryption key will be provided as. Passphrases must be between 8 and 512 bytes long.
1. At this time the newly created zpool is not mounted anywhere. Next we create the "root" dataset, that's an arbitary term for the parent dataset of all boot environments. Boot environments in your case may be for example different operating systems all of which live on separate datasets underneath the root.
1. `-o mountpoint=none`: Same as above, the root dataset has - just like the pool - no mountpoint configured.
1. `zfs set org.zfsbootmenu:commandline=...`: Set a common kernel command line for all boot environment such as `"ro quiet"`.
1. `zfs set org.zfsbootmenu:commandline=...`: Set a common kernel command line for all boot environments such as `"ro quiet"`.
1. Neither the root dataset nor the pool are mounted at this time. We now create one boot environment dataset where we want to install Arch Linux.
1. `-o mountpoint=/`: Our Arch Linux dataset will be mounted at `/`.
1. `-o canmount=noauto`: When set to `noauto`, a dataset can only be mounted and unmounted explicitly. The dataset is not mounted automatically when the dataset is created or imported, nor is it mounted by the `zfs mount -a` command or unmounted by the `zfs unmount -a` command.
@@ -303,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 <encryptionroot>` which will load the key from `keylocation` after which the `keystatus` property for `<encryptionroot>` 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`.