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>
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>
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>
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>
