on first boot /etc/zfs/zfs-list.cache/rboot /etc/zfs/zfs-list.cache/bpool are empty.
during boot, eventually they get populated by zfs-zed.service, with material information, as used by zfs-mount-generator upon fist boot & any daemon-reload.
this causes daemon-reload to go bananzas, as zfs-mount-generator produces units for the first time and generates many essential mount units. After that if cache is populated, generators on boot & daemon-reload produces the same units and everything and everyone is happy.
.... until one boots a snapshot. I bet booting snapshot, result in an in-cohesive.
I wonder if installer could generated correct and expected zfs-list.cache in target system.
Or I wonder if our zfs-mount-generator(8) in ubuntu is out of date (because of zsys support).
Or if there has been some systemd regression.
I wonder if we can make zfs-mount-generator do nothing, after the boot has started.
on first boot /etc/zfs/ zfs-list. cache/rboot /etc/zfs/ zfs-list. cache/bpool are empty.
during boot, eventually they get populated by zfs-zed.service, with material information, as used by zfs-mount-generator upon fist boot & any daemon-reload.
this causes daemon-reload to go bananzas, as zfs-mount-generator produces units for the first time and generates many essential mount units. After that if cache is populated, generators on boot & daemon-reload produces the same units and everything and everyone is happy.
.... until one boots a snapshot. I bet booting snapshot, result in an in-cohesive.
I wonder if installer could generated correct and expected zfs-list.cache in target system.
Or I wonder if our zfs-mount- generator( 8) in ubuntu is out of date (because of zsys support).
Or if there has been some systemd regression.
I wonder if we can make zfs-mount-generator do nothing, after the boot has started.