Closed ghost closed 1 year ago
legacy is too strict, but why not, at least temporarily. We may add a note about grub bug in future, if upstream won't fix it in a year.
If we genuinely think that one or more of the current feature list in /usr/share/zfs/compatibility.d/grub2
is not, actually compatible with GRUB2, then we should be making upstream PRs to fix that. The whole point of that file is to identify which features are usable with GRUB2; it is vastly preferable to fix this file than to suggest that GRUB2 only works with compatibility=legacy
bpools.
Which features are causing the problem?
If people are following this guide, bpool needs very few zpool features in order to remain useful, we should definitely prune compatibility.d/grub2
to only contain features we are highly confident to work.
Well, as a student of mathematics, only a proof would make me confident about anything. Since we do not have that, I will have to contend with legacy.
To be clear, there is no guarantee (proof) that legacy will work with GRUB either.
Colm @.***> writes:
If people are following this guide, bpool needs very few zpool features in order to remain useful, we should definitely prune compatibility.d/grub2 to only contain features we are highly confident to work.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
As mentioned here, compat=legacy seems to fix the problem where, once a snapshot of the root level dataset of the boot pool is taken, boot pool will become irreversibly unreadable by GRUB.
Also added a note against using less well-tested features in general.