As among possibly other things, it addresses a patch that got
backported to kernel 6.2.8 too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As reported having set 'mountpoint=legacy' on the root dataset (for a
default install this would be 'rpool/ROOT/pve-1') for mounting through
e.g. /etc/fstab breaks booting in initramfs
The cherry-picked patch is already applied to zfs-2.1.8-staging
upstream so will be included in the next zfs point release.
reproduced the issue on a VM with ZFS on root by:
* booting into a PVE 7.3 iso (to have zfs and an inactive
rpool/ROOT/pve-1)
* `zpool import -ocachefile=none -N -f rpool
* `zfs set mountpoint=legacy rpool/ROOT/pve-1`
* `mount -t zfs rpool/ROOT/pve-1 /mnt
* `echo "rpool/ROOT/pve-1 / zfs defaults 0 0" >> /mnt/etc/fstab`
* `zpool export rpool`
* reboot - the boot breaks with zfs-initramfs 2.1.7-pve1 but works
with this patch applied
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This does:
* fix get_transp() on non-bash
* re-indent of the code from #990745
* fix terminology: it's pool
* remove -e: I originally actually fixed -e,
but it turns out literally every bit that could fail
is already either || : or wasn't by accident (like in the #990745 code)
* simplify get_transp() and explain why we do it instead of matching nvme path
* use remove -L from the data we feed to lsblk, zpool w/o -L is measurably faster
* pipe the devices into while read to match rest of code
* use read -r in main loop
* match the userprop with case/esac instead of if tree
* shellcheck-clean the script
(cherry picked from debian-upstream[0]
commit 769a09407c6b65db981804a05a81ea63d004ebeb)
[0] https://salsa.debian.org/zfsonlinux-team/zfs
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
following upstream shipping it as a symlnk to /dev/null (to mask it)
follows commit b18419d7068b7ebcaa6dfbee85263177feffa711 from
debian-upstream:
https://salsa.debian.org/zfsonlinux-team/zfs/
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
While checking the current state of 2.1.6 we noticed that there were
some changes in debian-upstream [0] resulting from a bug-report in
zfs-upstream [1].
Our packages should be unaffected (they do not ship the
init-scripts in the first place).
Since the issue was fixed by zfs-upstream already on the
zfs-2.1.7-staging branch we should include it as well as it might save
users, who somehow got debian-upstream's zfs-packages installed on PVE
some trouble.
The other 2 changes seem small and isolated enough so including them
as well.
[0] https://salsa.debian.org/zfsonlinux-team/zfs/-/commits/master
[1] https://github.com/openzfs/zfs/issues/14010
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Thanks to Miao Wang for get_transp() function
(cherry picked from debian-upstream[0]
commit 1f5433b15e4f7c823983bb90390c4b023f3d1948)
[0] https://salsa.debian.org/zfsonlinux-team/zfs
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
following debian upstream (which pulled it in from Ubuntu in
44915cf387d45a123b11a8c24d3f30a8fdbcc532)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
following commit da40a1b007d2a99bac95bd67ec6dd7b8e217c0cf from
debian-upstream.
However since some of our rust-packages seem to depend on
libcurl4-gnutls-dev (via librust-curl-sys-dev) we add a
option for the dependency - I would assume that both should work
equally well (the callers are in upstream/lib/libzfs/libzfs_crypto.c)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
the changes to zvol_open added to 2.1.2 (for coping with kernel
changes in 5.13) seem to have introduced a lock order inversion [0].
(noticed while reviewing the 2.0.6->2.0.7 changes (the patch was
applied after 2.1.2 was already tagged)
[0] https://github.com/openzfs/zfs/pull/12863
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This commit updates Thomas' patch to deal with a 2.0 kernel module
with 2.1 arc_summary/arcstat
Tested by adding a cache-device to a zpool and running both commands
to verify no KeyError exception is thrown.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
