Comment 4 for bug 1838278

Marking the zfs-linux task as won't fix after looking more deeply about cause/consequences of forcing -f on every boot:
- zfs 0.8, as told previously, tag with which system the pool was associated with and refuse to import previously unexported pool, as they can still be attached to any systems (possibly running).
- there is a kernel option zfs.force=on (or _, '') which can be set to on/yes/1 to force the import in the initramfs.

This is seen upstream as a way to force broken systems, where they have been imported but not exported before reboot.

Note that this broken case only impacts the 2 following scenarios:
- you install a new system (so system id != final id) and then reboot to your new installed system. This is the curtin (and ubiquity) cases. I think it's fine to require them to properly export the pools before rebooting (which will cause a sync).
- you have 2 systems installed in parallel on the same pool, and on shutdown, while switching between the 2 systems, the export wasn't working on shutdown. This has to be seen how frequent this is and having zfs marked as experimental for this cycle sounds like a good fit to get those data.

Marking the zfs task as won't fix for now.