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