| 1 |
On Tue, Aug 31, 2021 at 3:44 PM Michael <confabulate@××××××××.com> wrote: |
| 2 |
> |
| 3 |
> Please beware, I have not used zfs to date, only btrfs, so the above merely |
| 4 |
> reflects my understanding rather than in depth experience of the difficulty in |
| 5 |
> managing such a setup. |
| 6 |
|
| 7 |
To save you digging through the thread, the issue with zfs is that it |
| 8 |
adds new features over time, and grub isn't necessarily compatible |
| 9 |
with all of them. You can control which features are enabled on-disk |
| 10 |
for compatibility, but grub doesn't do a great job documenting which |
| 11 |
features are/aren't supported in any particular version. So, it is a |
| 12 |
bit of a guessing game. |
| 13 |
|
| 14 |
It has been pointed out that there are various guides online, but: |
| 15 |
|
| 16 |
1. They don't all say the exact same thing. |
| 17 |
2. They aren't official upstream docs. |
| 18 |
3. They rarely specify what version of grub they're talking about. |
| 19 |
|
| 20 |
The typical solution is to either use very conservative settings for |
| 21 |
your root partition (which isn't ideal from a zfs standpoint), or have |
| 22 |
a separate /boot pool which means that you don't have to encumber the |
| 23 |
rest of the system with whatever grub's limitations might be. Then |
| 24 |
you just never update that partition and it shouldn't break. That |
| 25 |
basically is no different than just having /boot on ext4 or vfat or |
| 26 |
whatever. With this solution you also can't just freely resize /boot |
| 27 |
the way you could if it were part of the pool. |
| 28 |
|
| 29 |
-- |
| 30 |
Rich |
Archives