This is not an issue when initially creating the partition because
device mapper will just map on top of the filesystem, but it breaks
incremental updates because the check for `TYPE=` will fail, and the
subsequent attempt to run `mkswap` also fails:
mkswap: cannot open /dev/disk/by-partlabel/disk-nix-store-swap: Device or resource busy
Instead, just don't do anything, NixOS will take care of it.
Running `zfs set mountpoint=/mnt/my-ds tank/my-ds`, ZFS may try to
unmount the dataset even if the mountpoint didn't change.
To avoid the confusing error message, this command is now only run when
the mountpoint actually changes.
This allows for the disko scripts to be ran in more foreign environments
where we can't assume the basic utilities coreutils provides are
available or aren't 1-for-1 compatible (e.g. busybox utilities).
I.e. instead of effectively ignoring `discardPolicy` when combined with
`randomEncryption`, or adding a second option requiring the user to
repeat themselves (DRY violation), just enable both when requested via
`discardPolicy`.
Without this `discardPolicy` is a NOP when `randomEncryption` is
enabled.
The option `disko.devices.lvm_vg.<name>.lvs.<name>.priority` depends on
a different option that's unset by default breaking the manual build
like this:
… while evaluating the attribute 'optionalValue.value'
at /nix/store/lwyjz70qh12nq6cb7fixl85vryzxqm3c-source/lib/modules.nix:856:5:
855|
856| optionalValue =
| ^
857| if isDefined then { value = mergedValue; }
… while evaluating a branch condition
at /nix/store/lwyjz70qh12nq6cb7fixl85vryzxqm3c-source/lib/modules.nix:857:7:
856| optionalValue =
857| if isDefined then { value = mergedValue; }
| ^
858| else {};
(stack trace truncated; use '--show-trace' to show the full trace)
error: The option `disko.devices.lvm_vg.<name>.lvs.<name>.size' is used but not defined.
This is especially noticeable when using `documentation.nixos.includeAllModules` locally.
Fixed the issue itself by adding a `defaultText` and added the
`disko-doc` job to the `checks` output so that CI hopefully catches this
from now on.
On 4Kn disks, 2048-sector alignment is equivalent to 8 MiB which is
excessive. Moreover, there is no point in specifying _any_ alignment
at all because sgdisk defaults to 1 MiB already.
Fixes#497.
Also refactor `zpool` type to use `zfs_fs` to construct the root dataset
for the zpool, which means we no longer need to duplicate the dataset
create and mount logic inside the `zpool` type.
If the zpool's root dataset is not the rootfs and gets mounted on
creation, the actual rootfs will get mounted later and shadow the
current mountpoint.
Running `zfs unmount` is the easiest way to unmount the zpool's root
dataset on creation without messing up the value of the `mountpoint`
setting.
