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>
