disko-install could probably bail out more violently if zpool creation fails

[hawkw]

When running a disko-install command that attempts to create a ZFS pool and datasets, the installation simply keeps going if a dataset could not be created. For example, if I attempt to create an encrypted dataset with a passphrase, and mistype the passphrase when asked to re-enter it, disko install just keeps going, and eventually fails later while trying to set up /etc:

# ... snipped most of the install

+ zpool create -f rpool -R /mnt/disko-install-root -O acltype=posixacl -O atime=off -O compression=zstd -O mountpoint=none -O xattr=sa raidz2 /dev/disk/by-partlabel/disk-nvme01-zfs /dev/disk/by-partlabel/disk-nvme02-zfs /dev/disk/by-partlabel/disk-nvme03-zfs /dev/disk/by-partlabel/disk-nvme04-zfs
++ zfs get -H mounted rpool
++ cut -f3
+ [[ no == yes ]]
+ mountOptions=('defaults')
+ declare -a mountOptions
+ mountpoint=
+ name=__root
+ options=(['acltype']='posixacl' ['atime']='off' ['compression']='zstd' ['mountpoint']='none' ['xattr']='sa')
+ declare -A options
+ type=zfs_fs
+ zfs get type rpool
+ zfs set -u acltype=posixacl atime=off compression=zstd mountpoint=none xattr=sa rpool
+ mountOptions=('defaults')
+ declare -a mountOptions
+ mountpoint=
+ name=crypt
+ options=(['encryption']='aes-256-gcm' ['keyformat']='passphrase' ['keylocation']='prompt' ['mountpoint']='none')
+ declare -A options
+ type=zfs_fs
+ zfs get type rpool/crypt
+ zfs create -up rpool/crypt -o encryption=aes-256-gcm -o keyformat=passphrase -o keylocation=prompt -o mountpoint=none
Enter new passphrase:
Re-enter new passphrase:
cannot create 'rpool/crypt': Provided keys do not match.
+ rm -rf /tmp/tmp.a9b2ICfi9p
installing the boot loader...
setting up /etc...
efiSysMountPoint = '/boot' is not a mounted partition. Is the path configured correctly?
Traceback (most recent call last):
  File "/nix/store/q4w4kvd4zqnpxkd8fmnshv2vagay5bmd-systemd-boot/bin/systemd-boot", line 436, in <module>
    main()
    ~~~~^^
  File "/nix/store/q4w4kvd4zqnpxkd8fmnshv2vagay5bmd-systemd-boot/bin/systemd-boot", line 416, in main
    run([CHECK_MOUNTPOINTS])
    ~~~^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/q4w4kvd4zqnpxkd8fmnshv2vagay5bmd-systemd-boot/bin/systemd-boot", line 58, in run
    return subprocess.run(cmd, check=True, text=True, stdout=stdout)
           ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/nix/store/9yh9ak97gn659bk4d3n411fx6c0ng7s2-python3-3.13.5/lib/python3.13/subprocess.py", line 577, in run
    raise CalledProcessError(retcode, process.args,
                             output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['/nix/store/7j7civmcknwsf5pzqvxq1433haxypzpx-check-mountpoints']' returned non-zero exit status 1.
Failed to install bootloader
disko-install failed
rmdir: failed to remove '/mnt/disko-install-root': Directory not empty

Note that creating the rpool/crypt dataset failed, but the installation just keeps going.

This isn't the greatest user experience, since it's not obvious why the installation failed: the user is inclined to take the "/boot is not a mounted partition" error as being the reason the install failed, since it was printed immediately before the installer bailed out, without looking higher up in the logs to notice that the dataset was not created successfully. And, if the installed configuration does not have root on ZFS, it seems plausible that the installer could appear to succeed while failing to create some ZFS pools/datasets.

It seems to me that it might be better if the disko-install script exited with an error immediately if creating a ZFS dataset or pool failed.