quico-os-setup/arch-zbm
1
0
Fork 0
Code Issues 3 Pull Requests Packages Projects Releases Wiki Activity
arch-zbm/README.md

577 lines
34 KiB
Markdown
Raw Blame History

# arch-zbm
Helper script to install Arch Linux with ZFSBootMenu from within a running Arch Linux live CD ISO image
## Prep
We expect minimal prep on your end. Please make sure that before execution the following conditions are met.
### UEFI
On a UEFI system ensure these conditions are met. See [How to prep](#how-to-prep) for details on how to meet these conditions.
- One GPT-partitioned disk
- Arch Linux live CD ISO image sees exactly one partition with partition type code `BF00` ("Solaris root")
- Arch Linux live CD ISO image sees exactly one partition with partition type code `EF00` ("EFI System Partition")
- The `EF00` EFI partition is mountable, in practical terms this usually only means it has a file system.
- No ZFS zpool exists
### Legacy BIOS
If you are instead running a legacy BIOS machine ensure these conditions are met. See [How to prep](#how-to-prep) for details on how to meet these conditions.
- One MBR-partitioned disk
- Arch Linux live CD ISO image sees exactly one partition with partition type code `bf` ("Solaris root")
- Arch Linux live CD ISO image sees exactly one partition with partition type code `83` ("Linux")
- The `83` Linux partition is mountable, in practical terms this usually only means it has a file system.
- No ZFS zpool exists
Neither with a UEFI nor legacy BIOS system are any of these conditions a requirement from ZFSBootMenu. We're just setting requirements to easily identify if you intend to do a UEFI or a legacy BIOS install. Subsequently the script has no logic to detect UEFI or legacy BIOS mode, that's legwork left to the reader :) The Internet seems to agree that a good quick check is to see if your Arch Linux live CD ISO image has directory `/sys/firmware/efi`.
```
[ -d /sys/firmware/efi ] && echo 'Likely a UEFI system' || echo 'Probably a legacy BIOS system'
```
If you're unsure nothing's stopping you from just giving it a go with a best guess and if that fails you know you guessed wrong.
## How to prep
### UEFI
On a blank example disk `/dev/sda` you can fulfill the UEFI requirements (one `EF00` partition with a file system plus one `BF00` partition) for example like so:
```
sgdisk --new '1::+512M' --new '2' --typecode '1:EF00' --typecode '2:BF00' /dev/sda
mkfs.vfat /dev/sda1
```
> `--new '1::+512M'`: Create partition number `1`. The field separator `:` separates the partition number from start sector. In this case start sector is unspecified so start sector sits at whatever the system's default is for this operation. On a blank disk on an Arch Linux live CD ISO image this will default to sector `2048`. Partition ends at whatever the beginning is `+512M` meaning plus 512 Mebibytes.
>
> `--new '2'`: Create partition number `2`. Both field number 2, the start sector, and field number 3, the end sector, are unspecified, there's no field separator `:`. Field number 2 will be the first free sector - in this case right after partition 1 - and field number 3 will be end of disk. Thus partition `2` will fill the remaining free disk space.
>
> `--typecode '1:EF00'`: Partition 1 gets partition type code `EF00`, an EFI System Partition.
>
> `--typecode '2:BF00'`: Partition 2 gets partition type code `BF00`, a Solaris root partition.
The result will be something like this at which point you can start the `setup.sh` script, see [How to run this?](#how-to-run-this) below for more details.
```
# lsblk --paths --output 'NAME,SIZE,FSTYPE,PARTTYPE,PARTTYPENAME,PTTYPE' /dev/sda
NAME SIZE FSTYPE PARTTYPE PARTTYPENAME PTTYPE
/dev/sda 10G gpt
├─/dev/sda1 512M vfat c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System gpt
└─/dev/sda2 9.5G 6a85cf4d-1dd2-11b2-99a6-080020736631 Solaris root gpt
```
### Legacy BIOS
For a legacy BIOS machine you'll be using a Master Boot Record (MBR) on your disk.
```
printf -- '%s\n' 'label: dos' 'start=1MiB, size=512MiB, type=83, bootable' 'start=513MiB, size=+, type=bf' | sfdisk /dev/sda
mkfs.vfat /dev/sda1
```
> `label: dos`: Create the following partition layout in a Master Boot Record.
>
> `start=1MiB, size=512MiB, type=83, bootable`: Partition 1 begins 1 Mebibyte after disk start and is 512 Mebibyte in size. We're setting its bootable flag and setting partition type code `83` ("Linux").
>
> `start=513MiB, size=+, type=bf`: Partition 2 begins right at the start of Mebibyte 513, this is the very next sector after the end of partition 1. It takes up the remaining disk space, we're assigning type code `bf` ("Solaris").
The result will be something like this at which point you can start the `setup.sh` script, see [How to run this?](#how-to-run-this) below for more details.
```
# lsblk --paths --output 'NAME,SIZE,FSTYPE,PARTTYPE,PARTTYPENAME,PTTYPE' /dev/sda
NAME SIZE FSTYPE PARTTYPE PARTTYPENAME PTTYPE
/dev/sda 10G dos
├─/dev/sda1 512M vfat 0x83 Linux dos
└─/dev/sda2 9.5G 0xbf Solaris dos
```
# Partition naming
Since this script works with UEFI and legacy BIOS mode we'll be addressing both disk layout schemes with umbrella terms for better readability: "The zpool partition" will be GPT `BF00` partition and MBR `bf` partition. You'll parse the text accordingly. "The boot partition" will be GPT `EF00` partition as well as the MBR `83` partition.
# ZFS dataset layout
The script will create a single ZFS zpool `zpool` on the zpool partition with dataset child `zpool/root` which itself has one child `zpool/root/archlinux`, that's where Arch Linux gets installed. Parallel to `zpool/root` it'll create `zpool/data` with a `zpool/data/home` child dataset that gets mounted at `/home`.
# How to run this?
- Boot an Arch Linux live CD ISO image
- Run:
```
export SCRIPT_URL='https://quico.space/quico-os-setup/arch-zbm/raw/branch/main/setup.sh' && curl -s "${SCRIPT_URL}" | bash
```
During execution the script will call itself when it changes into its `chroot`, that's why we `export SCRIPT_URL`. Feel free to update `"${SCRIPT_URL}"` with whatever branch or revision you want to use from [quico.space/quico-os-setup/arch-zbm](https://quico.space/quico-os-setup/arch-zbm). Typically `.../branch/main/setup.sh` as shown above is what you want.
## Options
### Compression
By default we create a zpool with ZFS property `compression=on`. If the `lz4_compress` pool feature is active this will by default enable `compression=lz4`. See `man 7 zfsprops` for example in ZFS 2.1.9 for details. See `zpool get feature@lz4_compress <pool>` to check this feature's status on your `<pool>`.
To get a zpool with uncompressed datasets export the shell variable `ARCHZBM_ZFSPROPS_NO_COMPRESSION` with any value prior to running this script. Literally any value works as long as you're not setting this to an empty string:
```
export ARCHZBM_ZFSPROPS_NO_COMPRESSION=yesplease
```
### Encryption
By default we encrypt the zpool with ZFS property `encryption=on`. In ZFS 2.1.9 this defaults to `encryption=aes-256-gcm`.
To get a zpool with unencrypted datasets export the shell variable `ARCHZBM_ZFSPROPS_NO_ENCRYPTION` with any value prior to running this script:
```
export ARCHZBM_ZFSPROPS_NO_ENCRYPTION=yup
```
# 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 ZFS zpool on top of zpool 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 boot partition
1. Configure boot method
- Either an EFI image with EFI boot order entries on a UEFI machine
- Or Syslinux with `extlinux` for a legacy BIOS computer
1. Add `pacman` hooks to keep ZFSBootMenu images (and `extlinux`) updated
- [quico.space/quico-os-setup/zbm-regen-pacman-hook](https://quico.space/quico-os-setup/zbm-regen-pacman-hook)
- [quico.space/quico-os-setup/zbm-syslinux-pacman-hook](https://quico.space/quico-os-setup/zbm-syslinux-pacman-hook)
1. Exit into Arch Linux live CD ISO image shell for you to `reboot` and frolick
# Flavor choices
We make the following opinionated flavor choices. Feel free to change them to your liking.
- Arch Linux locale is set to `en_US.UTF-8`
- Keymap is `de-latin1`
- Consult `/etc/vconsole.conf`
- Change `zfs set org.zfsbootmenu:commandline=...`
- No X.Org Server, Wayland compositors or other GUI elements get installed
- Timezone is `Etc/UTC`
- Check `timedatectl set-timezone <tzdata-zone>`
# Post-run manual steps
After installation you're going to want to at least touch these points in your new Arch Linux install:
- Package manager hook: `pacman` does not have a hook to do ZFS snapshots
- See [this GitHub gist](https://gist.github.com/Soulsuke/6a7d1f09f7fef968a2f32e0ff32a5c4c#file-arch_on_zfs-txt-L238) and [zfs-snapshotter.bash](https://github.com/Soulsuke/arch-zfs-tools/blob/master/zfs-snapshotter.bash) for inspiration
- Hostname: Installation chose a pseudo-randomly generated 8-character string with `pwgen`
- Check `hostnamectl set-hostname <hostname>`
- Unprivileged user accounts: The OS was installed with `root` and unprivileged `build` users
- Passwords
- ZFS: The password for all datasets underneath `zpool` is `password`.
- Local `root` account: The local `root` account's password is `password`.
- Arch User Repository (AUR) helper: We installed [paru](https://github.com/Morganamilo/paru) as our AUR helper, we installed from GitHub via `makepkg -si` then replaced itself with its [paru-bin](https://aur.archlinux.org/packages/paru-bin) version from AUR.
- In `/etc/systemd/network/50-wired.network` instead of a DHCP-based network config you can get a static one. The DHCP-based one for reference looks like:
```
...
[Network]
DHCP=ipv4
IPForward=yes
Domains=~.
[DHCP]
UseDNS=yes
RouteMetric=10
```
A static config does away with the `[DHCP]` section:
```
...
[Network]
Address=10.10.10.2/24
Gateway=10.10.10.1
DNS=10.10.10.1
IPForward=yes
Domains=~.
```
- In case you later want a graphical interface and specifically NetworkManager (via package `networkmanager`) consider telling it to keep its hands off of some of your network interfaces. The bullet point above adds a `systemd`-style config file that `systemd-networkd.service` will read and use. Should you ever install NetworkManager it will by default assume that it must manage all interfaces. It'll use its own DHCP client to try and get IP addresses for _managed interfaces_ in which case you'll end up with whatever addressing scheme you configured in a `.network` unit file plus NetworkManager's additional address. Create `/etc/NetworkManager/conf.d/99-unmanaged-devices.conf` for example to declare some interfaces as off-limits or _unmanaged_:
```
[keyfile]
unmanaged-devices=mac:52:54:00:74:79:56;type:ethernet
```
Check out [ArchWiki article "NetworkManager" section "Ignore specific devices"](https://wiki.archlinux.org/title/NetworkManager#Ignore_specific_devices) for more info.
# Password change
After installation you're going to want to change your ZFS encryption password.
## Steps
In a running OS:
1. Change password in `keylocation` file, e.g. `/etc/zfs/zpool.key` or whatever other `"${zpool_name}"'.key'` file you used during setup
1. Set this key as the new encryption key:
```
zfs change-key -l zpool
```
Quoting `man 8 zfs-change-key` from `zfs-utils` version 2.1.9 for the `-l` argument: "Ensures the key is loaded before attempting to change the key." When successful the command will not output data, it'll just silently change your encryption key.
1. Rebuild initramfs:
```
mkinitcpio -P
```
Here for example with `-P` (`--allpresets`) which processes all presets contained in `/etc/mkinitcpio.d`. This step puts the changed key file into your initramfs. During setup we've adjusted `/etc/mkinitcpio.conf` so that it contains `FILES=(/etc/zfs/zpool.key)` which causes the file to be added to initramfs as-is.
## Boot flow
With your password changed in two locations (key file and initramfs) The boot process works as follows.
At boot time ZFSBootMenu will scan all pools that it can import for a `bootfs` property. If it only finds one pool with that property the dataset given as `bootfs` will be selected for boot with a 10-second countdown allowing manual interaction. With `bootfs` set ZFSBootMenu will not actively search through datasets for valid kernel and initramfs combinations, it'll instead accept `bootfs` as the default boot entry without us entering the pool decryption passphrase.
Upon loading into a given dataset ZFSBootMenu will attempt to auto-load the matching decryption key. In our setup this will fail because we purposely stored the encryption key inside our `zpool/root/archlinux` dataset. ZFSBootMenu will prompt us to type in the decryption key.
Lastly ZFSBootMenu loads our OS' kernel and initramfs combination via `kexec`. For this step we don't need to enter the decryption key again. Our initramfs file contains the plain-text `/etc/zfs/zpool.key` file which allows it to seamlessly import the right dataset, load its key and mount it.
## Caveats in a password change
ZFS differentiates between user keys - also called wrapping keys - and the master key for any given encryption root. You never interact with the master key, you only pick your personal user key. Subsequently a user key change (in our use case we perceive this simply as a password change) has zero effect on data that's already encrypted. The operation is instant and merely reencrypts the already existing master key, the so-called _wrapped_ master key.
ZFS generates the master key exactly once when you enable encryption on a dataset - technically when it becomes an encryption root. Among other inputs it uses your user key to encrypt (to _wrap_) the master key. When you change your user key it just means that the master key stays exactly the same and only the encrypted (_wrapped_) key changes.
`man 8 zfs-change-key` from `zfs-utils` version 2.1.9 adds:
> If the user's key is compromised, `zfs change-key` does not necessarily protect existing or newly-written data from attack. Newly-written data will continue to be encrypted with the same master key as the existing data. The master key is compromised if an attacker obtains a user key and the corresponding wrapped master key. Currently, `zfs change-key` does not overwrite the previous wrapped master key on disk, so it is accessible via forensic analysis for an indeterminate length of time.
>
> In the event of a master key compromise, ideally the drives should be securely erased to remove all the old data (which is readable using the compromised master key), a new pool created, and the data copied back. This can be approximated in place by creating new datasets, copying the data (e.g. using `zfs send | zfs recv`), and then clearing the free space with `zpool trim --secure` if supported by your hardware, otherwise `zpool initialize`.
On one hand changing the ZFS encryption password is generally a good and useful thing to do. On the other hand changing your password does not currently overwrite previous wrapped master keys on disk. A sufficiently motivated party that gains access to a wrapped master key and the matching user key is able to decrypt the master key and use it to read all data encrypted with it.
By extension this means after a password change your data remains at risk until you've copied it to a new dataset and erased previously used space thereby erasing any previous wrapped master keys.
## Changing master key
In order to generate a new master key after you've changed your user key as mentioned in `man 8 zfs-change-key` from `zfs-utils` version 2.1.9 one example workflow goes like this:
1. Change user key
- Update `/etc/zfs/zpool.key`
- Update zpool with new key via `zfs change-key -l zpool`
- Generate new initramfs with `mkinitcpio -P`
1. Create a snapshot from current system dataset
```
# Assuming current system dataset is zpool/root/archlinux-sxu
# where '-sxu' is a random suffix to differentiate datasets
# and has no real meaning
zfs snapshot zpool/root/archlinux-sxu@rekey
```
1. Within same pool `send`/`receive` snapshot
```
zfs send \
--large-block \
--compressed \
'zpool/root/archlinux-sxu@rekey' | \
zfs receive \
-Fvu \
-o 'encryption=on' \
-o 'keyformat=passphrase' \
-o 'keylocation=file:///etc/zfs/zpool.key' \
-o 'mountpoint=/' \
-o 'canmount=noauto' \
-o 'org.zfsbootmenu:commandline=rw nowatchdog rd.vconsole.keymap=de-latin1' \
'zpool/root/archlinux-frn'
```
Explanation:
- We specifically don't `zfs send -R` (`--replicate`). While it would normally be nice to transfer all of a dataset's children at once such as all of its snapshots the `-R` argument conflicts with the `encryption` property. See [comment by Tom Caputi on GitHub openzfs/zfs issue 10507 from June 2020](https://github.com/openzfs/zfs/issues/10507#issuecomment-651162104) for details. Basically if `encryption` is set then `-R` doesn't work. We could transfer existing encryption properties with `-w`/`--raw` but we don't actually want to transfer encryption properties at all. We want them to change during transfer, see the bullet point four points down from here talking about `encryption`.
- We `zfs receive -F` destroying any target snapshots and file systems beyond the snapshot we're transferring. In this example the target `zpool/root/archlinux-frn` doesn't even exist so `-F` isn't necessary to clean anything up. It's just good practice.
- 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 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
```
1. Boot into new system dataset
1. After reboot and now that you're in the new system dataset change its `encryptionroot` by letting it inherit data from its parent:
```
zfs change-key -i -l zpool/root/archlinux-frn
```
The parent `zpool/root` is inheriting this property from `zpool` which will make sure that `zpool/root/archlinux-frn` essentially gets its key now from `zpool`. Both `zpool/root/archlinux-frn` and `zpool` use the same exact `keylocation` with identical content. This operation is instant.
## Finishing touches
### Confirm master key change
Just to confirm that the master key has changed run this command. It takes a moment to output data:
```
zfs send --raw zpool/root/archlinux-frn@rekey | zstream dump | sed -n -e '/crypt_keydata/,/end crypt/p; /END/q'
```
Repeat for source dataset `zpool/root/archlinux-sxu@rekey`. You're particularly interested in parameters `DSL_CRYPTO_MASTER_KEY_1` and the initialization vector `DSL_CRYPTO_IV`. Notice that they differ between old and new dataset confirming that your new dataset has a new master key.
### Clean-up
Clean up:
1. In newly keyed/reencrypted system dataset destroy its snapshot
```
zfs destroy zpool/root/archlinux-frn@rekey
```
1. Recursively destroy source dataset
```
zfs destroy -r zpool/root/archlinux-sxu
```
### Unmap/TRIM
Next up unmap/TRIM unallocated disk areas. If your zpool runs on an entire disk and not just on a partition, and if your disk supports TRIM you're going to want to do:
```
zpool trim --secure zpool
```
The next best alternative is to instead do:
```
zpool initialize zpool
```
View status with either one of:
```
# With TRIM status
zpool status -t zpool
# Without TRIM status
zpool status zpool
```
# ZFS setup explained
## Overview
The ZFS pool and dataset setup that makes this tick, explained in plain English.
1. Create zpool with options:
1. `-R /mnt` (aka `-o cachefile=none -o altroot=/mnt`). The pool is never cached, i.e. it's considered temporary. All pool and dataset mount paths have `/mnt` prepended. From `man zpoolprops`:
> This can be used when examining an unknown pool where the mount points cannot be trusted, or in an alternate boot environment, where the typical paths are not valid. `altroot` is not a persistent property. It is valid only while the system is up.
1. `-O canmount=off`: Note the capital `-O` which makes this a file system property, not a pool property. File system cannot be mounted, and is ignored by `zfs mount -a`. This property is not inherited.
1. `-O mountpoint=none`: What it says on the tin, the pool has no mountpoint configured.
1. `-O encryption=on`: Makes this our `encryptionroot` and passes the `encryption` setting to all child datasets. Selecting `encryption=on` when creating a dataset indicates that the default encryption suite will be selected, which is currently `aes-256-gcm`.
1. `-O keylocation=file://...`: This property is only set for encrypted datasets which are encryption roots. Controls where the user's encryption key will be loaded from by default for commands such as `zfs load-key`.
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 canmount=off`: Same as above, the root dataset can - just like the pool - not be mounted.
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 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.
1. We then `zpool set bootfs="zpool/root/archlinux" zpool`: ZFSBootMenu uses the `bootfs` property to identify suitable boot environments. If only one pool has it - as is the case here - it identifies the pool's preferred boot dataset that will be booted with a 10-second countdown allowing manual interaction in ZFSBootMenu.
1. We explicitly mount the boot environment. Since the entire pool is still subject to our initial `-R /mnt` during creation a `zfs mount zpool/root/archlinux` will mount the Arch Linux dataset not into `/` but instead into `/mnt`.
1. We also create a `data` dataset that - at least for now - we use to store only our `/home` data.
1. For `zpool/data`:
1. `-o mountpoint=/`: We use the `mountpoint` property here only for inheritance.
1. `-o canmount=off`: The `zpool/data` dataset itself cannot actually be mounted.
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-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 gets prefixed 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`.
1. We lastly mount our EFI partition into `/mnt/efi`.
1. We instruct ZFS to save its pool configuration via `zpool set cachefile=/etc/zfs/zpool.cache zpool`.
The complete ZFS structure now exists and is mounted at `/mnt` ready for any `pacstrap`, [debootstrap](https://wiki.debian.org/Debootstrap), `dnf --installroot` or other bootstrapping action.
## Adding another boot environment-independent dataset
Assume that in addition to your `/home` data which lives on `zpool/data/home` you want another dataset that is exempt from Arch Linux snapshots.
Consider an example `/opt/git` directory where a bunch of Git repos are checked out on which you work. You don't want them to be snapshotted - and rolled back - when something goes sideways: they are decoupled from everything else that goes on on your machine so you can easily and safely have a static `/opt/git` directory available in all boot environments.
Move your current `/opt/git` data out of the way for a moment:
```
mv '/opt/git'{,'.bak'}
```
Create datasets
```
zfs create -o canmount=off zpool/data/opt
zfs create zpool/data/opt/git
```
Remember that the `zpool/data` dataset already exists and that it has both `mountpoint=/` and `canmount=off` set. It is not and cannot be mounted itself, it instead conveniently anchors datasets at `/`. Since the `canmount` dataset property cannot be inherited and defaults to `canmount=on` we have to manually specify `-o canmount=off`. Our new `zpool/data/opt` should not automatically mount into `/opt`.
We then create the child dataset `zpool/data/opt/git`, it defaults to `canmount=on` thus immediately shows up at `/opt/git`.
Move data back into place and clean up temp directory
```
rsync -av --remove-source-files '/opt/git'{'.bak',}'/'
find '/opt/git.bak' -type d -empty -delete
```
An example `zpool/data` dataset may now look like so:
```
# zfs list -r -oname,mountpoint,canmount,mounted zpool/data
NAME MOUNTPOINT CANMOUNT MOUNTED
zpool/data / off no
zpool/data/home /home on yes
zpool/data/opt /opt off no
zpool/data/opt/git /opt/git on yes
```
## Nested environment-independent datasets
### Caution
If you want a dedicated dataset for a directory that lives deeper in your file system tree than just `/opt/git`, for example like `/var/lib/docker` make sure to not recursively create this structure in a single `zfs create` command.
In [Adding another boot environment-independent dataset](#adding-another-boot-environment-independent-dataset) above you can safely do:
```
zfs create -o canmount=off zpool/data/opt
```
Here `zpool/data` already exists, you're only creating one child dataset `opt` and you're setting `-o canmount=off` so that it never mounts into your `/opt` directory.
Now consider the same setup for `/var/lib/docker`. If you follow the exact same approach:
```
zfs create -o canmount=off zpool/data/var/lib
```
Docker will correctly report:
```
cannot create 'zpool/data/var/lib': parent does not exist
```
You might want to just create the parent then with `-p` argument:
```
zfs create -p -o canmount=off zpool/data/var/lib
~~
```
Note, however, that `-o canmount=off` only applies to `lib` dataset and that `zpool/data/var` has just been auto-mounted into `/var`:
```
# zfs list -r -oname,mountpoint,canmount,mounted zpool/data
NAME MOUNTPOINT CANMOUNT MOUNTED
zpool/data / off no
zpool/data/home /home on yes
zpool/data/opt /opt off no
zpool/data/opt/git /opt/git on yes
zpool/data/var /var on yes <---
zpool/data/var/lib /var/lib off no
```
### Advice
Instead create nested parents in multiple steps where you set each one to `-o canmount=off`:
```
zfs create -o canmount=off zpool/data/var
zfs create -o canmount=off zpool/data/var/lib
```
Lastly create the dataset you want mounted:
```
zfs create zpool/data/var/lib/docker
```
## Mounting zpool for maintenance
In case you want to mount your zpool on an external operating system such as an Arch Linux live CD ISO image do it like so:
```
zpool import zpool -d /dev/disk/by-partuuid -R /mnt -f -N
zfs load-key -L prompt zpool
zfs mount zpool/root/archlinux
zfs mount -a
# UEFI system ...
mount /dev/sda1 /mnt/efi
# ... or legacy BIOS system
mount /dev/sda1 /mnt/boot/syslinux
arch-chroot /mnt /bin/bash
```
When done exit `chroot` and cleanly remove your work:
```
umount /mnt/efi
zfs umount -a
zpool export zpool
```
Explanation:
- We always want to mount pools `by-partuuid` for consistency so we specifically only look for pools at `/dev/disk/by-partuuid`.
- We mount our zpool with `-R /mnt` (aka `-o cachefile=none -o altroot=/mnt`). The pool is never cached, i.e. it's considered temporary. All pool and dataset mount paths have `/mnt` prepended. From `man zpoolprops`:
> This can be used when examining an unknown pool where the mount points cannot be trusted, or in an alternate boot environment, where the typical paths are not valid. `altroot` is not a persistent property. It is valid only while the system is up.
- With `-f` and `-N` we force-mount our pool (`-f`) even if it previously wasn't cleanly exported; and we do not auto-mount any of its datasets (`-N`), not even the ones that have `canmount=on` set.
```
# zfs list -oname,mountpoint,canmount,mounted
NAME MOUNTPOINT CANMOUNT MOUNTED
zpool none off no
zpool/data /mnt off no
zpool/data/home /mnt/home on no <-- Not immediately mounted
zpool/root none off no
zpool/root/archlinux /mnt noauto no <-- Not immediately mounted
```
- We load the decryption key by temporarily overriding the `keylocation` property to `-L prompt`. The default value is `file:///etc/zfs/zpool.key` which in all likelihood doesn't exist in this environment.
- We mount our desired boot environment with `zfs mount zpool/root/archlinux`
```
# zfs list -oname,mountpoint,canmount,mounted
NAME MOUNTPOINT CANMOUNT MOUNTED
zpool none off no
zpool/data /mnt off no
zpool/data/home /mnt/home on no
zpool/root none off no
zpool/root/archlinux /mnt noauto yes <-- Only boot env now mounted
```
- We mount all child datasets with `zfs mount -a` making `/mnt/home` available as well as any others you may have created yourself.
```
# zfs list -oname,mountpoint,canmount,mounted
NAME MOUNTPOINT CANMOUNT MOUNTED
zpool none off no
zpool/data /mnt off no
zpool/data/home /mnt/home on yes <-- Now mounted
zpool/root none off no
zpool/root/archlinux /mnt noauto yes <-- Now mounted
```
- We lastly mount our EFI System Partition (ESP), in this example it's living at `/dev/sda1` so adjust this path accordingly.
```
# df -hTP
Filesystem Type Size Used Avail Use% Mounted on
... ... ... ... ... ... ...
zpool/root/archlinux zfs 8.6G 2.5G 6.2G 29% /mnt
zpool/data/home zfs 6.3G 161M 6.2G 3% /mnt/home
/dev/sda1 vfat 511M 31M 481M 6% /mnt/efi
```
- We're ready to `arch-chroot` into our boot environment.
# Development
## Conventional commits
This project uses [Conventional Commits](https://www.conventionalcommits.org/) for its commit messages.
### Commit types
Commit _types_ besides `fix` and `feat` are:
- `build`: Project structure, directory layout, build instructions for roll-out
- `refactor`: Keeping functionality while streamlining or otherwise improving function flow
- `test`: Working on test coverage
- `docs`: Documentation for project or components
### Commit scopes
The following _scopes_ are known for this project. A Conventional Commits commit message may optionally use one of the following scopes or none:
- `iso`: Changing Arch Linux live CD ISO image
- `zbm`: Adjusting ZFSBootMenu's behavior
- `zfs`: A change to how ZFS interacts with the system, either a pool or a dataset
- `os`: Getting an operating system set up to correctly work in a ZFS boot environment
- `meta`: Affects the project's repo layout, readme content, file names etc.
# Credits
Most of what's here was shamelessly copied and slightly adapted for personal use from Jonathan Kirszling at GitHub.
Thanks to:
- Jonathan Kirszling:
- [github.com/eoli3n/arch-config/tree/master/scripts/zfs/install](https://github.com/eoli3n/arch-config/tree/master/scripts/zfs/install)
- [github.com/eoli3n/archiso-zfs](https://github.com/eoli3n/archiso-zfs)
- Maurizio Oliveri:
- [github.com/Soulsuke/arch-zfs-tools](https://github.com/Soulsuke/arch-zfs-tools)
- [gist.github.com/Soulsuke/6a7d1f09f7fef968a2f32e0ff32a5c4c](https://gist.github.com/Soulsuke/6a7d1f09f7fef968a2f32e0ff32a5c4c)
- Zach Dykstra, Andrew J. Hesford and all other [ZFSBootMenu contributors](https://github.com/zbm-dev/zfsbootmenu/graphs/contributors):
- Their [ZFSBootMenu testing helper scripts](https://github.com/zbm-dev/zfsbootmenu/tree/master/testing/helpers) ([chroot-arch.sh](https://github.com/zbm-dev/zfsbootmenu/blob/master/testing/helpers/chroot-arch.sh), [install-arch.sh](https://github.com/zbm-dev/zfsbootmenu/blob/master/testing/helpers/install-arch.sh))
- [github.com/kongkrit](https://github.com/kongkrit):
- [gist.github.com/kongkrit/a0585e179e33c2adf92db4050ec5171d](https://gist.github.com/kongkrit/a0585e179e33c2adf92db4050ec5171d)
Reference in New Issue View Git Blame Copy Permalink