With ZFS 2.2. they're actually only installed if ZFS is being build
for FreeBSD, so not remvoing them here leads to a missing file error.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
vmexit's can cause the AMX registers to "misbehave" which can break
ZFS, even though ZFS doesn't use AMX at all.
This causes crashes and processes hanging forever in uninterruptible
sleep (the infamous D state) on Intel Xeon 4th gen HW, possible other
HW too, but we only got reports on Sapphire Rapids models.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Tested-by: Aaron Lauterer <a.lauterer@proxmox.com>
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>
