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>
following commit ec311430e2fd66492498a1559f56ef25e1192266 ZFS
upstream due to
> Added functions (2):
> - boolean_t zpool_is_draid_spare(const char *);
> - zpool_compat_status_t zpool_load_compat(const char *,
> boolean_t *, char *, char *);
However since libzfs increased both the current as well as the age,
as there where only addition but no changes of previously existing
ABI, the soname of the library remained at libzfs4.so - following
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html I left
the package name at libzfs4linux
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
[ Thomas: added a bit more context ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
suggesting the new -dbgsym packages without having a strict dependency
on a specific version of the library packages, like the old no longer
built zfs-dbg package had.
this commit can be reverted after the package has been uploaded once, or
kept for one release cycle if we might do the -dbgsym migration in
oldstable as well to avoid the oldstable zfs-dbg package version
overtaking the transitional one here.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
zfs-zed is the only classical daemon, which benefits from a restart,
so restart only zfs-zed.
Noticed during the transition from ZFS 0.8.x to 2.0.0 zvol_wait, which
is called by zfs-volume-wait.service was changed to also output the
redacted_snap property of the datasets. This property does not exist
if the kernelmodule is still 0.8.x, causing an error to be printed to
the journal.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
* Pull in the changes to the automatic scrub cronjob from
debian-upstream [0] commit
f6d45405df0a2ed2748975667e8ea50714034d13
* Add a script and cronjob for regular trimming of pools
* Change the logic to scrub/trim pools based on a per pool('s root
dataset property)
pulled the changes in as one commit instead of cherry-picking, since
the planned and reverted debconf questions would have caused
unneccessary churn.
commits identified by running:
`git log --full-diff -- debian/tree/zfsutils-linux/usr/lib/zfs-linux`
in a worktree from [0].
[0] https://salsa.debian.org/zfsonlinux-team/zfs/
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Closes BTS#983401.
- Overwrite dangling symlinks on install
- Does not clobber symlinks on removal
Signed-off-by: Antonio Russo <aerusso@aerusso.net>
(cherry picked from commit b024d59f5976ea75ac9a0b48612b7032d24513ee)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
automatically generated -dbgsym packages has become the default
(see dh_strip(1) and [0]).
While we have no direct need to migrate, it helps in avoiding
debhelper bug 939164 (see [1]), when migrating to debhelper-compat 12.
(alternative option would be to depend on debhelper from backports, or
to skip dh_dwz).
The change is well described in dh_strip(1).
[0] https://wiki.debian.org/AutomaticDebugPackages
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939164
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
this commit follows: 93661343d884a5339631afd7b683e232d20b7baf and
0b52b09c6083bd590e46cb9884d06bae1b712a2a from debian-upstream [0].
the `make checkabi` invocation takes < .4s on my workstation - so it
seems worth the change.
[0] https://salsa.debian.org/zfsonlinux-team/zfs
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
during the tracking of zfs-2.0.x integration in debian upstream I did
not notice that the library packages got renamed yet another time (see
[0]) to match the soname version.
This patch renames our library packagenames to match debian upstream
and includes Breaks,Depends on the intermediate versions we shipped
with the zfs-2.0.3 release.
Noticed while checking an issue (with `aptitude` vs. `apt`) reported
on pve-user.
Tested on a VM running our latest packages and on one still running
zfs 0.8.5
[0] 42ba750f8c
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
the patch fixes a potential panic on systems running ZFS > 2.0.0 and
is already queued for inclusion in 2.0.3 - see [0] for a related
github issue.
[0] https://github.com/openzfs/zfs/issues/11474
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
by taking the current version from debian-upstream.
The only addition is an attribution for Proxmox for the files in
debian/*
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
ZFS includes (since 2.0.0) a pam-module, which takes the login
credentials of an user to unlock their home-dataset.
Enabling it in its current state can cause some side-effects like
prompting for a password when running `su` as root (see [0]).
Our update to ZFS 2.0.0 shipped the pam config in zfsutils-linux,
whereas debian-upstream split it out into its own optional package
This commit adopts this change.
based on debian-upstream [1] commit
cad2f3d24aa44cfdce1e2eae8b6ba027efaba2d6
The issue becomes apparent by installing the current zfsutils-linux
package and running `pam-auth-update --package` (e.g. by installing
an upgraded libpam-runtime package).
[0] https://github.com/openzfs/zfs/issues/11222
[1] https://salsa.debian.org/zfsonlinux-team/zfs/
Reported-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Originally-by: Antonio Russo <aerusso@aerusso.net>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
It's included as link in /usr/bin there, so the grep matched it
twice, the actual file plus the link, resulting in a build failure.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
upstream commit 2d2ce04b9931927ffd045f9ebba3d39d4d31f7db changed the location
for installing pkgconfig files to the architecture specific one in /lib
instead of /usr/share - this patch reflects the change in
'debian/libzfslinux-dev.install'.
It follows the change from 9a04c500f17d8df20a017137211d0984cace98ff in
debian's repository [0].
[0] https://salsa.debian.org/zfsonlinux-team/zfs.git
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This patch addresses the problems some users experience when some zpools are
created/imported with cachefile (which then causes other pools not to get
imported during boot) - when our tooling creates a pool we explictly
instantiate the service with the pool's name, ensuring that it will get
imported by scanning.
Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
adapted from debian-upstream [0] commit
53276c973c5e69f75b43371a6c94adc5d9dcfec0
(the systemd sequence is enabled by default since debhelper v10 - see
debhelper(7))
[0] https://salsa.debian.org/zfsonlinux-team/zfs.git
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
/etc/default/zfs and /etc/zfs/zfs-functions are now installed by the
makefiles. Continue to install them directly as before, but do not
--fail-missing because of them.
adapted from debian-upstream [0] commit
9a594875114fe186aebba2776b14817ab7f272ae
[0] https://salsa.debian.org/zfsonlinux-team/zfs.git
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
the last series of cherry-picks from salsa.d.o includes one patch for the
zfs-source, but the patch file does not contain ident-information.
This prevents it from being applied by import-patchqueue.
Fixed by adding ident based on the original patches commit message and
importing and exporting the patchqueue.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Of the zedlet scripts shipped by upstream, a subset are enabled by
default, by creating symlinks in /etc/zfs/zed.d. These symlinks are
shipped in the zfs-zed package. dpkg, however, does not support
conffile handling of symlinks, and therefore any changes (removals) to
the symlinks are not preserved on package upgrade.
To address this policy violation, we:
1. During package build, create a list of enabled-by-default zedlets,
instead of creating symlinks.
2. On package removal, identify all enabled-by-default zedlets whose
symlinks do not exist (i.e., were removed by the user). This is done
by creating "whiteout" links to /dev/null in their place).
3. On package installation, create links to enabled-by-default zedlets
UNLESS there is already a file there (i.e., abort if there is a
whiteout link).
4. We also clean up broken symlinks to removed zedlets at package
postinst.
(cherry picked and adapted from 5cee380324d74e640d5dd7a360faba3994c8007f [0])
[0] https://salsa.debian.org/zfsonlinux-team/zfs.git
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
If a pool is already scrubbing, zpool scrub will return an error. This
breaks the cron scrub script. It outputs that error and then does not
scrub any further pools.
This change checks to see if the pool is scrubbing before attempting to
start a scrub. This addresses long-running scrubs. Note that a
"long-running" scrub here is not necessarily a month long. If the
system is shut off or the pool is exported, the scrub will resume later.
(cherry picked from 41e457da7bfc837a52f3389cb6961bc6737b874d [0])
[0] https://salsa.debian.org/zfsonlinux-team/zfs.git
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This reduces the required time for the configure step drastically,
from previous:
# time ./configure --with-config=kernel
-> 124.14s user 34.06s system 103% cpu 2:32.90 total
to now:
# time ./configure --with-config=kernel
-> 75.07s user 15.01s system 394% cpu 22.821 total
(152 seconds vs 22 seconds)
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
That's why it was guarded with the "HAVE_KERNEL_FPU_INITIALIZED"
defined in the first place..
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
