3399a30ee0
This had always worked in my testing, but a user on hardware reported
this to happen 100%, and I reproduced it once with cold VM host caches.
dracut-zfs-generator runs as a systemd generator, i.e. at Some
Relatively Early Time; if root= is a fixed dataset, it tries to
"solve [necessities] statically at generation time".
If by that point zfs-import.target hasn't popped (because the import is
taking a non-negligible amount of time for whatever reason), it'll see
no children for the root datase, and as such generate no mounts.
This has never had any right to work. No-one caught this earlier because
it's just that much more convenient to have root=zfs:AUTO, which orders
itself properly.
To fix this, always run zfs-nonroot-necessities.service;
this additionally simplifies the implementation by:
* making BOOTFS from zfs-env-bootfs.service be the real, canonical,
root dataset name, not just "whatever the first bootfs is",
and only set it if we're ZFS-booting
* zfs-{rollback,snapshot}-bootfs.service can use this instead of
re-implementing it
* having zfs-env-bootfs.service also set BOOTFSFLAGS
* this means the sysroot.mount drop-in can be fixed text
* zfs-nonroot-necessities.service can also be constant and always
enabled, because it's conditioned on BOOTFS being set
There is no longer any code generated at run-time
(the sysroot.mount drop-in is an unavoidable gratuitous cp).
The flow of BOOTFS{,FLAGS} from zfs-env-bootfs.service to sysroot.mount
is not noted explicitly in dracut.zfs(7), because (a) at some point it's
just visual noise and (b) it's already ordered via d-p-m.s from z-i.t.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Closes #14690
|
||
|---|---|---|
| .. | ||
| 02zfsexpandknowledge | ||
| 90zfs | ||
| .gitignore | ||
| Makefile.am | ||
| README.md | ||
Basic setup
- Install
zfs-dracut - Set
mountpoint=/for your root dataset (for compatibility,legacyalso works, but is not recommended for new installations):zfs set mountpoint=/ pool/dataset - Either (a) set
bootfs=on the pool to the dataset:zpool set bootfs=pool/dataset pool - Or (b) append
root=zfs:pool/datasetto your kernel cmdline. - Re-generate your initrd and update it in your boot bundle
Encrypted datasets have keys loaded automatically or prompted for.
If the root dataset contains children with mountpoint=s of /etc, /bin, /lib*, or /usr, they're mounted too.
For complete documentation, see dracut.zfs(7).
cmdline
-
root=Root dataset is… (empty) the first bootfs=afterzpool import -aNzfs:AUTO,zfs:,zfs(as above, but overriding other autoselection methods) ZFS=pool/datasetpool/datasetzfs:pool/dataset(as above) All
+es are replaced with spaces (i.e. to boot fromroot pool/data set, passroot=zfs:root+pool/data+set).The dataset can be at any depth, including being the pool's root dataset (i.e.
root=zfs:pool).rootfstype=zfsis equivalent toroot=zfs:AUTO,rootfstype=zfs root=pool/datasetis equivalent toroot=zfs:pool/dataset. -
spl_hostid: passed tozgenhostid -f, useful to override the/etc/hostidfile baked into the initrd. -
bootfs.snapshot,bootfs.snapshot=snapshot-name: enableszfs-snapshot-bootfs.service, which creates a snapshot$root_dataset@$(uname -r)(or, in the second form,$root_dataset@snapshot-name) after pool import but before the rootfs is mounted. Failure to create the snapshot is noted, but booting continues. -
bootfs.rollback,bootfs.rollback=snapshot-name: enableszfs-rollback-bootfs.service, which-Rfrolls back to$root_dataset@$(uname -r)(or, in the second form,$root_dataset@snapshot-name) after pool import but before the rootfs is mounted. Failure to roll back will fall down to the rescue shell. This has obvious potential for data loss: make sure your persistent data is not below the rootfs and you don't care about any intermediate snapshots. -
If both
bootfs.snapshotandbootfs.rollbackare set,bootfs.rollbackis ordered afterbootfs.snapshot. -
zfs_force,zfs.force,zfsforce: add-fto allzpool importinvocations. May be useful. Use with caution.