Generate zfs-list.cache using zed can be made to work
As of this writing, manually invoking
zeddoes not work for me. How to generate the cache can be found in
/etc/zfs/zed.d/history_event-zfs-list-cacher.sh, basically the cache is a list of dataset properties in a specific order in
I dug into this a bit and found that zed actually calls
history_event-zfs-list-cacher.sh, but this exits without doing anything due to a call to
zed_exit_if_ignoring_this_event, a function from
zed-functions.sh. Looking at this function, it seems to be targeted at the syslog hook, to ignore certain history_events. I don't think calling this function is correct here, and indeed removing it solves the problem and the zfs-list.cache is correctly updated when e.g. changing a mountpoint= property.
This still leaves the problem of mounting the boot-dataset even though it has
canmount=noauto. Though the only way to fix this is probably to modify the script and/or add a specific
org.openzfs.systemd:mount_even_if_canmount_noauto or sth. in that spirit. What do you think?
- Hi! Thanks for the feedback! I've updated information regarding list cacher in the article with the info you provided.
- As for mounting
/bootdataset: yes, I think it is a sensible approach to add a custom property to persuade
canmount=noauto. However before they implement this, the only way to go seems to be just replacing
on, as described in the article. M0p (talk) 01:10, 28 December 2020 (UTC)
A simpler solution for mounting boot dataset: just use legacy mountpoint and mount it with /etc/fstab! It's more reliable and, the boot environment tool I ported from FreeBSD, AUR supports this. M0p (talk) 06:33, 8 January 2021 (UTC)