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.
** Changed in: zfs-linux (Ubuntu)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1838278
Title:
zfs-initramfs wont mount rpool
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1838278/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
