Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On the other hand, though - creating this dependency *will* break workflows and cause many unexpected side-effects, as it broke mine last month: I have linux-headers-cloud-amd64 installed; when this package hit BPO, it brought in linux-image-cloud-amd64, which grub then tracked as the most recent kernel and booted into, causing (ironically) many drivers to be missing and the system failed to boot correctly as a result (it is not a cloud server, but it does build modules *for* cloud servers). It also brought my /boot to 98% full, fortunately this did not cause problems by itself, but obviously came close to doing so. It has been consistently asserted that installing superfluous image files is harmless; I want to point out that this is anything but true, even aside from the more philosophical issues around having "source" packages depend on "binary" ones, and the precise meaning of "significant functionality" in the Debian policy. Colm On Tue, 2 Apr 2024 at 17:57, Colm Buckley wrote: > Please explain. I am really sorry to be dragging this discussion out, but > I honestly think there is some information I'm missing. Please tell me what > I am missing here? ** PLEASE ** read it before replying; I am honestly not > trying to undermine you, just point out a serious problem with the apparent > logic. > > Your proposal is to have linux-headers-X depend on linux-image-X. > > But: > > * User installs linux-image-X and linux-headers-X > * User builds modules for this image using DKMS or whatever > * User then does "apt install linux-image-Y" - this is the exact scenario > you hope to guard against? > ... nothing brings in linux-headers-Y; the user is *still* left without > their new modules. > > Your proposal will only work if the user remembers to upgrade -headers... > which will fix the problem even without the dependency! > > I fully understand that there is a desire for users to keep linux-image-* > and linux-headers-* in synch; my proposal is that a *further* package be > created - linux-complete-VERSION - which depends on both of them. Users who > have that package installed would always have the right thing happen. To > encourage adoption, it could be in "Suggests" from each, and maybe even in > DKMS? > > Colm > > > On Tue, 2 Apr 2024 at 17:51, Bastian Blank wrote: > >> On Tue, Apr 02, 2024 at 05:38:01PM +0100, Colm Buckley wrote: >> > ... but the proposed dependency wouldn't address that, right? >> >> Actually it does. It ties all packages together with = dependencies. >> For an upgrade, all packages need to be unpacked first and only then the >> maintainer scripts can run. >> >> There are cases where this can be broken, but working most of the time >> is better then working never. >> >> Bastian >> >> -- >> Prepare for tomorrow -- get ready. >> -- Edith Keeler, "The City On the Edge of Forever", >>stardate unknown >> > > > -- > Colm Buckley | c...@tuatha.org > > -- Colm Buckley | c...@tuatha.org
Bug#1064976: Having headers depend on image - bad idea I think
I wrote: [...] From the maintainer's most recent comments, I believe that the > problem is something like: > > * user has installed linux-headers and linux-image for kernel version X > * user has built additional modules using DKMS which are installed into > the running system > * user upgrades linux-headers to version Y, new modules get rebuilt > * user does not upgrade linux-image from X to Y, confusion results > > Having linux-image-Y be a dependency of linux-headers-Y does indeed > address this problem, but [...] > The most recent comment ( https://lists.debian.org/debian-kernel/2024/04/msg00020.html) from the maintainer indicates that he has a slightly different problem in mind: * user has installed linux-headers and linux-image for version X * user has built additional modules using DKMS, installed into the running system * user upgrades the *kernel image* to version Y but forgets to upgrade the headers * as a result, new kernel is missing important modules, confusion reigns This is a real problem - however I think it is *not* one which the change in dependency addresses; even if -headers-Y depends on -image-Y, step 3 above will proceed without any conflicts (because the reverse dependency is not true). I think the only realistic way to address this (assuming we don't want to make -image depend on -headers) would be to have a linux-complete (not sold on the name) package series which depends on corresponding versions of both image and headers packages. Users who regularly build new modules should be encouraged to install this package and have it pull in suitable versions of both headers and image. Is this correct, Bastian? I'm sorry for taking so long to understand what problem was being addressed here. Colm -- Colm Buckley | c...@tuatha.org
Bug#1064976: Having headers depend on image - bad idea I think
Control: reopen 1064976 My apologies for the ping-pong; I do want to keep this open until the discussion has completed. I will set out my thoughts below. I'm afraid this is fairly long. A brief history of this issue: in December 2023, the control file for linux-headers-* was altered to include a dependency on linux-image-* ( https://salsa.debian.org/kernel-team/linux/-/merge_requests/903). As far as I can tell, no bugreport was linked as a problem being addressed with this change; the maintainer's comment was "A lot of problems arise if users use headers of a different version then the associated image. The easiest solution is to make them depend." Note that this dependency did not exist in any previous version of linux-headers as far as I can determine; the problems seem to be largely theoretical. This change worked its way through the release pipeline and eventually arrived in bookworm-backports around the end of February 2024, with the promotion of the package linux-headers-6.6.13+bpo-amd64 (and others) to backports. I immediately noticed the impact on my build server, and submitted a bug report ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976) requesting that it be reverted. The maintainer defended the change, indicating that it was necessary for people using dkms; when pressed on exactly what failed, he mentioned the BTF warnings [1] but as far as I can tell, no specific user problem was presented. Several attempts by myself and Luca Boccassi to determine what problem was being addressed were not answered. The bug was closed as WONTFIX a few days ago, but still there has been no real explanation as to why the change was introduced in the first place. I would like to go on the record here as saying (especially with the xz-utils exploit still in everyone's memory), that we should be *extremely careful* with changing things like dependency trees without very well-documented reasons, *especially* for something as critical as the kernel packages. I ordinarily try to be very respectful of maintainers' latitude and discretion in packaging decisions, but here I am trying to ensure that a serious problem is addressed in BPO before it gets promoted to stable. The change is significant enough that I feel it deserves more discussion and attention than it has so far received. Having re-read the thread a few times today, I feel that the BTF warnings (which were originally presented as the main reason for this change) are a red herring and not relevant. The new packaging of vmlinux.h does address the issue of BPF builds for pretty much all users (it's true that build pipelines will have to be adjusted, but the new system is a significant improvement on the old). The discussion about BPF kernel modules does not seem to be based on any real user activity, and to be honest it seems somewhat self-contradictory - why would a kernel module need BPF in the first place? Let's consider the possible reasons for having the header package depend on the image package: >From Debian's policy documentation; "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." So what functionality is provided by linux-headers-*? I would posit initially that their main function is unspecified apart from "having the header files for the specific kernel exist under /usr/src", which clearly does not require the image package. However, a major use case for the header files is to build kernel modules, whether using DKMS or some other mechanism. But this use case *also* does not require the image package; in fact this is the main reason the header files were packaged as they are. Hundreds of thousands (at least) of Debian users have been happily building kernel modules using linux-headers packages without the corresponding image files for decades, and there are no recent kernel changes which break this ability. The recent introduction of vmlinux.h additionally addresses an edge case (building BPF programs) which formerly *did* require a built image for its symbol table. So the important piece of functionality also does not require the kernel image package. Now, given the maintainer's comments on the original PR and in this bug, I suspect I understand the real reason for the change: in order to *run* modules built using DKMS etc., obviously the corresponding kernel image file needs to be present. From the maintainer's most recent comments, I believe that the problem is something like: * user has installed linux-headers and linux-image for kernel version X * user has built additional modules using DKMS which are installed into the running system * user upgrades linux-headers to version Y, new modules get rebuilt * user does not upgrade linux-image from X to Y, confusion results Having linux-image-Y be a dependency of linux-headers-Y does indeed address this problem, but I feel that it is fairly substantial overkill. There are several
Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-*
Package: linux-headers-amd64 Version: 6.6.13-1~bpo12+1 Followup-For: Bug #1064976 X-Debbugs-Cc: c...@tuatha.org Can I suggest in the interim that Depends: be replaced with Recommends: or Suggests: given that most installations won't actually need the image package? Colm
Bug#1064976:
Hey folks - I see that linux-headers-* has been promoted to 6.6 in the BPO channel, but this dependency is still in place. Is it really the case that we want to drag in the image binaries and other machinery as a dependency for a source package like linux-headers. I feel that the BPF use case should really be addressed using vmlinux.h (the "skipping BTF generation" message should be ignored as all of this information *should* be included in vmlinux.h). Any further thoughts? Colm
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
As per the discussion in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005 - once vmlinux.h is included with linux-headers, the warning about cmd_btf_ko etc. should be harmless, as that file should already be available (ie: there's no need to generate it again as part of kernel build). Am I missing something else? I confess I have only a very small amount of experience with BPF code; I played with building a few modules, but I don't use it regularly. Colm
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank wrote: > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > With the new vmlinux.h shipped in the headers package, the BTF case > > should be covered. > > The relevant code in Linux is: > > | quiet_cmd_btf_ko = BTF [M] $@ > | cmd_btf_ko = \ > | if [ ! -f vmlinux ]; then \ > | printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \ > | else \ > | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \ > | $(RESOLVE_BTFIDS) -b vmlinux $@; \ > | fi; > > Which change is needed here to use vmlinux.h instead? My understanding is that you don't need this command at all; the included vmlinux.h already contains the necessary type definitions for libbpf, for the kernel source version in question - ie: instead of needing to run pahole or bpftool to extract these definitions from a specific vmlinux image, this file is distributed with them already included. Colm
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
> The build wants the image available (it does not really fail without, but
lacks stuff) and we need some dependency to keep image and headers in sync
for people using dkms.
To be honest, "it does not really fail without, but lacks stuff" seems like
the use case that "Recommends:" (or even "Suggests:") was designed for,
rather than "Depends:", don't you agree?
I'm not sure, of course, what problem is being addressed here; it's
possible that there's a more elegant solution available. Is there a
previous bug describing the problem?
My concern is that I have a specific build server which builds kernels and
modules for other machines in a farm. It needs to have the header files for
specific target kernel versions installed, but it is not sensible to have
the corresponding image packages installed (in many cases, those images
wouldn't even run on this build server).
Colm
On Thu 29 Feb 2024, 11:03 Colm Buckley, wrote:
> Why was this never the case before? And can you be more precise about what
> "stuff" is missing? Is there a previous bug report I can reference?
>
> DKMS should handle its own dependencies, I'd have thought - I see a clear
> use case for installing header files without the corresponding images.
>
> Colm
>
>
> On Thu 29 Feb 2024, 10:31 Bastian Blank, wrote:
>
>> Control: tags -1 wontfix
>>
>> On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote:
>> > The linux-headers packages for kernel version 6.6 seem to depend on the
>> corresponding
>> > linux-image packages, but I believe that this should not be the case
>> (and was not the
>> > case in previous versions).
>>
>> It should. The build wants the image available (it does not really fail
>> without, but lacks stuff) and we need some dependency to keep image and
>> headers in sync for people using dkms.
>>
>> Bastian
>>
>> --
>> Vulcans never bluff.
>> -- Spock, "The Doomsday Machine", stardate 4202.1
>>
>
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Why was this never the case before? And can you be more precise about what "stuff" is missing? Is there a previous bug report I can reference? DKMS should handle its own dependencies, I'd have thought - I see a clear use case for installing header files without the corresponding images. Colm On Thu 29 Feb 2024, 10:31 Bastian Blank, wrote: > Control: tags -1 wontfix > > On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: > > The linux-headers packages for kernel version 6.6 seem to depend on the > corresponding > > linux-image packages, but I believe that this should not be the case > (and was not the > > case in previous versions). > > It should. The build wants the image available (it does not really fail > without, but lacks stuff) and we need some dependency to keep image and > headers in sync for people using dkms. > > Bastian > > -- > Vulcans never bluff. > -- Spock, "The Doomsday Machine", stardate 4202.1 >
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Some previous versions, for contrast: % apt-cache depends linux-headers-6.5.0-0.deb12.4-amd64 linux-headers-6.5.0-0.deb12.4-amd64 Depends: linux-headers-6.5.0-0.deb12.4-common Depends: linux-kbuild-6.5.0-0.deb12.4 Depends: linux-compiler-gcc-12-x86 % apt-cache depends linux-headers-6.1.0-18-amd64 linux-headers-6.1.0-18-amd64 Depends: linux-headers-6.1.0-18-common Depends: linux-kbuild-6.1 Depends: linux-compiler-gcc-12-x86
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Package: linux-headers-6.6.13+bpo-amd64 Severity: normal X-Debbugs-Cc: c...@tuatha.org Dear Maintainer, The linux-headers packages for kernel version 6.6 seem to depend on the corresponding linux-image packages, but I believe that this should not be the case (and was not the case in previous versions). It should be possible to install the header files for a particular kernel version (eg: to allow for modules to be built for that version, which is my use case) without requiring the kernel image to be installed. I think the headers packages should depend on a suitable version of linux-kbuild and any necessary glibc headers or other build artifacts, but not on linux-image-* Many thanks, Colm -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable-security'), (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-headers-6.6.13+bpo-amd64 depends on: ii gcc-1212.2.0-14 pn linux-headers-6.6.13+bpo-common pn linux-image-6.6.13+bpo-amd64 | linux-image-6.6.13+bpo-amd64-unsi gned pn linux-kbuild-6.6.13+bpo linux-headers-6.6.13+bpo-amd64 recommends no packages. linux-headers-6.6.13+bpo-amd64 suggests no packages.
Bug#1038155: [Pkg-zfsonlinux-devel] Bug#1038155: Bug#1038155: zfs-linux: Provide a package based on OpenZFS master branch (a.k.a. 2.1.99)
I *really* don't think we should be pushing RC versions of ZFS (or any other project) to the mainline Debian distributions. Using a kernel from "unstable" has always been risky, and in this case one of the risks is that ZFS will not work. Maintainer bandwidth is a limited resource, and I would vastly prefer that time be spent on ensuring the stability and reliability of the "stable" release, with the second priority being a reasonable set of updates being available in "backports". Zhou and the gang do a great job in keeping things up to date; I wouldn't view it as their responsibility to deal with breakages in unstable, unless there's some other compelling reason. My personal preference, assuming maintainer time is available, would be to continue to offer 2.1.X in stable, and 2.2.X in backports when 2.2.0 is released (as opposed to being RC). Colm On Tue, 8 Aug 2023 at 12:09, Peter Samuelson wrote: > > [M. Zhou] > > I'd personally not prefer to upload zfs-X.Y.99 anytime in the future. > > Since debian is volunteer-based, we don't seem to have more bandwidth > > than Ubuntu for dealing with regressions and serious bugs in a > > snapshot version. > > That's fair - but now that Linux 6.4 is in unstable, zfs-dkms is no > longer supported and will not build. For that reason, could you update > to 2.2.0-rc3? > > Peter > > ___ > Pkg-zfsonlinux-devel mailing list > pkg-zfsonlinux-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel > -- Colm Buckley | c...@tuatha.org
Bug#989046: libcurl3-gnutls: Please consider packaging 7.76.1
Package: libcurl3-gnutls Version: 7.74.0-1.2~bpo10+1 Severity: important Dear Maintainer, This bug - https://github.com/curl/curl/issues/6825 - is possibly the underlying cause of #831756 and #987187. Given the importance of the git workflow in particular, I'd like to request that you consider packaging 7.76.1 (which fixes this issue) for buster-bpo. The stable version does not seem to suffer from this problem. Thanks, Colm -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcurl3-gnutls depends on: ii libbrotli11.0.7-2+deb10u1 ii libc6 2.28-10 ii libcom-err2 1.46.2-1~bpo10+2 ii libgnutls30 3.6.7-4+deb10u6 ii libgssapi-krb5-2 1.17-3+deb10u1 ii libidn2-0 2.0.5-1+deb10u1 ii libk5crypto3 1.17-3+deb10u1 ii libkrb5-3 1.17-3+deb10u1 ii libldap-2.4-2 2.4.57+dfsg-2~bpo10+1 ii libnettle63.4.1-1 ii libnghttp2-14 1.36.0-2+deb10u1 ii libpsl5 0.20.2-2 ii librtmp1 2.4+20151223.gitfa8646d.1-2 ii libssh2-1 1.8.0-2.1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages libcurl3-gnutls recommends: ii ca-certificates 20200601~deb10u2 libcurl3-gnutls suggests no packages. -- no debconf information
Bug#983409: raspi-firmware: /etc/kernel/postinst.d/z50-raspi-firmware fails to ignore old-dkms initrds
Package: raspi-firmware
Version: 1.20200601-3~bpo10+1
Severity: normal
Tags: patch
Dear Maintainer,
The /etc/kernel/postinst.d/z50-raspi-firmware script which copies the kernel
and initrd to /boot/firmware, fails to ignore any old initrds which were renamed
by DKMS (usually of the form initrd.img-version-arch.old-dkms). These usually
compare
as "newer" than the correct initrd, so lead to incorrect config.txt contents and
possible boot failure.
I'd suggest modifying this script as below; summarized as:
# move this line to earlier in the script
arch=$(dpkg --print-architecture)
latest_kernel=$(ls -1 /boot/vmlinuz-*$arch | sort -V -r | head -1)
[...]
latest_initrd=$(ls -1 /boot/initrd.img-*$arch | sort -V -r | head -1)
- ie: looking specifically for kernels and initrds which end in the current
architecture name.
Not sure if this needs to go upstream. I suspect that the kernel and initrd
detection in this script could use a real reworking, see also bug #966503.
Thanks,
Colm
-- System Information:
Debian Release: 10.8
APT prefers stable-updates
APT policy: (900, 'stable-updates'), (900, 'stable')
Architecture: arm64 (aarch64)
Kernel: Linux 5.9.0-0.bpo.5-arm64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CRAP, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages raspi-firmware depends on:
ii dosfstools 4.1-2
ii dpkg1.19.7
raspi-firmware recommends no packages.
raspi-firmware suggests no packages.
-- Configuration Files:
/etc/kernel/postinst.d/z50-raspi-firmware changed:
set -e
exec &2
eval set -- "$DEB_MAINT_PARAMS"
case "$1" in
configure|remove)
;;
*)
exit 0
;;
esac
if ischroot ; then
true # chroot detected - skip mount point check
elif test -e /usr/bin/systemd-detect-virt && systemd-detect-virt -q ; then
true # virtualization detected - skip mount point check
elif ! mountpoint -q /boot/firmware; then
echo "raspi-firmware: missing /boot/firmware, did you forget to mount it?" >&2
exit 1
fi
mkdir -p /boot/firmware
arch=$(dpkg --print-architecture)
latest_kernel=$(ls -1 /boot/vmlinuz-*$arch | sort -V -r | head -1)
if [ -z "$latest_kernel" ]; then
echo "raspi-firmware: no kernel found in /boot/vmlinuz-*$arch, cannot
populate /boot/firmware"
exit 0
fi
latest_initrd=$(ls -1 /boot/initrd.img-*$arch | sort -V -r | head -1)
if [ -z "$latest_initrd" ]; then
echo "raspi-firmware: no initrd found in /boot/initrd.img-*$arch, cannot
populate /boot/firmware"
exit 0
fi
CMA=64M
ROOTPART=$(findmnt -n --output=source /) || true
if [ -z "$ROOTPART" ]; then ROOTPART=/dev/mmcblk0p2;fi
KERNEL="auto"
INITRAMFS="auto"
CONSOLES="auto"
if [ -r /etc/default/raspi-firmware ]; then
. /etc/default/raspi-firmware
fi
if [ "arm64" = "$arch" ]; then
dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}/broadcom"
else
# there is no vendor subdirectory for armhf
dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}"
fi
if [ "$KERNEL" = "auto" ]; then
for dtb in ${dtb_path}/bcm*.dtb; do
[ -e "${dtb}" ] && cp "${dtb}" /boot/firmware/
done
latest_kernel_basename=$(basename "$latest_kernel")
latest_initrd_basename=$(basename "$latest_initrd")
KERNEL=${latest_kernel_basename}
cp "$latest_kernel" /boot/firmware/
cp "$latest_initrd" /boot/firmware/
if [ "$CONSOLES" = "auto" ]; then
serial="ttyS1,115200"
fi
fi
: >/boot/firmware/config.txt
if [ "$arch" = "arm64" ]; then
cat >/boot/firmware/config.txt <>/boot/firmware/config.txt <>/boot/firmware/config.txt <>/boot/firmware/config.txt
Bug#982505: [Pkg-zfsonlinux-devel] Bug#982505: Bug#982505: zfsutils-linux: trim cronjob triggers "cannot trim" e-mails on spinning rust
I did have a quick look in the zpool trim code and it's a bit difficult to achieve what is being suggested; that error is generated deep in libzfs not in the mainline of the zpool command, so capturing it or declaring it not-an-error with a flag would not be super clean. It's possible, but it might not be quick. Short-term fix; parse the output of 'zpool status -t' to figure out if any devices support trim and only trim when there's at least one which does; something like: zpool status -tLP "$pool" | fgrep /dev/ | fgrep -qv 'trim unsupported' && zpool trim "$pool" ... but there might be corner cases which this doesn't catch. Colm On Thu, 11 Feb 2021 at 17:45, Christoph Biedl < debian.a...@manchmal.in-ulm.de> wrote: > Petter Reinholdtsen wrote... > > > Any idea how to figure out if trimming is possible/useful? > > Haven't checked, but in the meantime I figured a sane solution was > something like Colm suggested: Have upstream modifiy the zpool command > so - at least when providing an option like "--cron-mode" - it is silent > as long as there is no error, and it considers that particular situation > not an error. Then you could also remove the "|| true" again which has > potential of hiding errors where it should not. > > Christoph > ___ > Pkg-zfsonlinux-devel mailing list > pkg-zfsonlinux-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel -- Colm Buckley | c...@tuatha.org
Bug#982505: [Pkg-zfsonlinux-devel] Bug#982505: Bug#982505: zfsutils-linux: trim cronjob triggers "cannot trim" e-mails on spinning rust
To be honest, I'd rather this was addressed upstream with a suitable modification of the "zpool trim" command; either by ignoring this case by default (I believe this was the behavior in ZoL <2.0) or by adding a "--quiet" flag or similar. 'zpool status -t pool' does report whether TRIM is supported for each vdev, but the effort of parsing that in the cron script seems excessive. Grepping out that specific error message would probably be okay as an interim workaround. Colm On Thu, 11 Feb 2021 at 10:03, Petter Reinholdtsen wrote: > [Christoph Biedl] > > Please find a solution for this - preferably by checking beforehand > > whether trimming is possible. Or if all else fails, by muting stderr > > from the "zpool trim" command. Although that might hide serious errors > > as well. > > Good point. This can fill up the disk on a server where no-one check > the email. > > Any idea how to figure out if trimming is possible/useful? > > -- > Happy hacking > Petter Reinholdtsen > > ___ > Pkg-zfsonlinux-devel mailing list > pkg-zfsonlinux-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel -- Colm Buckley | c...@tuatha.org
Bug#969599: systemd: Valid IPv6 addresses and routes discarded erroneously under certain conditions.
Package: systemd Version: 246.4-1~bpo10+1 Followup-For: Bug #969599 Hey folks - I had a productive conversation with one of the upstream authors at https://github.com/systemd/systemd/issues/16719; we think we have found the root cause of this issue. A new version of the upstream PR is being merged and (we hope) will be backported to 246-stable. Hopefully Debian can then integrate it. If it is causing significant issues in the meantime, the commits badd492, 99a2878, 501b09d and 5055072 referenced at https://github.com/systemd/systemd/pull/16725 patch cleanly against the current debian-bpo source and result in a corrected package. Thanks for your help! Colm
Bug#969599: Info received (Bug#969599: systemd: Valid IPv6 addresses and routes discarded erroneously under certain conditions.)
The PR referenced earlier does ameliorate the issue; however I don't think it's a complete fix, as there are worrying messages in the debug log, and there is still nonzero packet loss. I will follow up with upstream. I would encourage Debian users to remain with systemd 245, and not to migrate this version to stable, until this issue is resolved. Colm
Bug#969599: systemd: Valid IPv6 addresses and routes discarded erroneously under certain conditions.
That PR patches cleanly against the Debian source; so I'm building a local package version now to test. Will follow up here and with upstream. Colm On Sat, 5 Sep 2020 at 20:48, Michael Biebl wrote: > Am 05.09.20 um 21:31 schrieb Colm Buckley: > > Package: systemd > > Version: 246.4-1~bpo10+1 > > Severity: important > > Tags: ipv6 > > > > Dear Maintainer, > > > > > > > > > > The current BPO release of systemd includes a serious regression; valid > SLAAC v6 addresses and routes > > > > are discarded under certain circumstances. I believe this to be an > instance of > > > > https://github.com/systemd/systemd/issues/16719 which is possibly fixed > by https://github.com/systemd/systemd/pull/16725 > > > > > > > > > The user-visible symptom is that the systems stop responding on their > SLAAC-configured v6 addresses until the link > > > > is next reconfigured; some time later they drop these addresses again. > > > > > > > > > > An extract from the debug log from systemd-networkd follows: note in > particular the "Removing address" and "Forgetting address" > > > > lines in the log. > > > > > > > > > > I think that pull/16725 should be cherry-picked into Debian as soon as > possible. > > > > Thanks for the bug report. > Could you test the pull request and verify that this fixes your issue > (and ideally also report back to the upstream bug report). > Once the PR is merged upstream, we can consider cherry-picking it. > > Michael > > -- Colm Buckley | c...@tuatha.org
Bug#969599: systemd: Valid IPv6 addresses and routes discarded erroneously under certain conditions.
Package: systemd Version: 246.4-1~bpo10+1 Severity: important Tags: ipv6 Dear Maintainer, The current BPO release of systemd includes a serious regression; valid SLAAC v6 addresses and routes are discarded under certain circumstances. I believe this to be an instance of https://github.com/systemd/systemd/issues/16719 which is possibly fixed by https://github.com/systemd/systemd/pull/16725 The user-visible symptom is that the systems stop responding on their SLAAC-configured v6 addresses until the link is next reconfigured; some time later they drop these addresses again. An extract from the debug log from systemd-networkd follows: note in particular the "Removing address" and "Forgetting address" lines in the log. I think that pull/16725 should be cherry-picked into Debian as soon as possible. Thanks, Colm Sep 05 20:23:13 lugh systemd-networkd[1148]: NDISC: Received Router Advertisement: flags none preference medium lifetime 0 sec Sep 05 20:23:13 lugh systemd-networkd[1148]: NDISC: Invoking callback for 'router' event. Sep 05 20:23:13 lugh systemd-networkd[1148]: int0: Configuring route: dst: fd79:b3fc:4a5b:1::/64, src: n/a, gw:
Bug#940646: [Pkg-utopia-maintainers] Bug#940646: Bug#940646: firewalld: Please consider shipping 0.7.1+ in buster-backports.
I see 0.8.1 in buster-bpo now. Thank you!
Bug#940646: [Pkg-utopia-maintainers] Bug#940646: Bug#940646: firewalld: Please consider shipping 0.7.1+ in buster-backports.
Oh, and to be clear, the process is rarely any more complex than "apt-get source firewalld/testing" and "dpkg-buildpackage". firewalld's dependencies are small and slow-changing, at the moment stable-bpo contains all necessary versions for firewalld/testing. Colm On Wed, Nov 20, 2019 at 8:05 PM Colm Buckley wrote: > I configure it using the command line; I have found some of the new > features and bugfixes in 0.7 to be useful for my setup, so I've been > building a samizdat 0.7.2 package myself, which "seems to work". However, I > only install firewalld_xxx.deb, not firewall-applet_xxx nor > firewall-config_xxx > > Colm > > > On Wed, Nov 20, 2019 at 8:00 PM Michael Biebl wrote: > >> Am 20.11.19 um 20:57 schrieb Colm Buckley: >> > Hum. I can validate the operations of firewalld itself, but I don't use >> > either the applet or the config package. >> >> How exactly do you intend to use the bpo package then? >> >> >> -- >> Why is it that all of the instruments seeking intelligent life in the >> universe are pointed away from Earth? >> >> > > -- > Colm Buckley / c...@tuatha.org / +353 87 2469146 > -- Colm Buckley / c...@tuatha.org / +353 87 2469146
Bug#940646: [Pkg-utopia-maintainers] Bug#940646: Bug#940646: firewalld: Please consider shipping 0.7.1+ in buster-backports.
I configure it using the command line; I have found some of the new features and bugfixes in 0.7 to be useful for my setup, so I've been building a samizdat 0.7.2 package myself, which "seems to work". However, I only install firewalld_xxx.deb, not firewall-applet_xxx nor firewall-config_xxx Colm On Wed, Nov 20, 2019 at 8:00 PM Michael Biebl wrote: > Am 20.11.19 um 20:57 schrieb Colm Buckley: > > Hum. I can validate the operations of firewalld itself, but I don't use > > either the applet or the config package. > > How exactly do you intend to use the bpo package then? > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > > -- Colm Buckley / c...@tuatha.org / +353 87 2469146
Bug#940646: [Pkg-utopia-maintainers] Bug#940646: Bug#940646: firewalld: Please consider shipping 0.7.1+ in buster-backports.
Hum. I can validate the operations of firewalld itself, but I don't use either the applet or the config package. Colm On Wed, Nov 20, 2019 at 6:55 PM Michael Biebl wrote: > Am 20.11.19 um 19:45 schrieb Colm Buckley: > > I feel that the answer is both yes and no. The *packaging* is trivial in > > my experience - the dependencies of firewalld are fairly > > small/manageable, and 0.7.2 *seems* to work fine with everything in > > stable-bpo. However, I have no experience with running Debian test > > suites and ensuring that all the details are taken care of. > > I have added autopkgtest support which does some very basic testing. > What I probably won't do is "real-world" testing, say installing the bpo > package in GNOME, check the UI, basic functionality etc. > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > > -- Colm Buckley / c...@tuatha.org / +353 87 2469146
Bug#940646: [Pkg-utopia-maintainers] Bug#940646: firewalld: Please consider shipping 0.7.1+ in buster-backports.
I feel that the answer is both yes and no. The *packaging* is trivial in my experience - the dependencies of firewalld are fairly small/manageable, and 0.7.2 *seems* to work fine with everything in stable-bpo. However, I have no experience with running Debian test suites and ensuring that all the details are taken care of. Colm On Wed, Nov 20, 2019 at 6:36 PM Michael Biebl wrote: > Am 20.11.19 um 19:24 schrieb Colm Buckley: > > @biebl - looks as though stable-bpo's nftables package tracks upstream > > pretty closely; if https://github.com/firewalld/firewalld/issues/540 is > > resolved, would you consider looking at packaging 0.8.0 for backports? > > I'm not really sure if I can commit to that. I would need help with > packaging and testing. > > Would you be willing to help here? > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > > -- Colm Buckley / c...@tuatha.org / +353 87 2469146
Bug#940646: firewalld: Please consider shipping 0.7.1+ in buster-backports.
@biebl - looks as though stable-bpo's nftables package tracks upstream pretty closely; if https://github.com/firewalld/firewalld/issues/540 is resolved, would you consider looking at packaging 0.8.0 for backports?
Bug#695885: Fixed in upstream
Gerhard tells me that this is fixed in the latest upstream version - 1.7.3.3. Can this be packaged for Debian shortly? I can look into an NMU if necessary. Colm -- Colm Buckley / c...@tuatha.org / +353 87 2469146
Bug#940646: firewalld: Please consider shipping 0.7.1+ in buster-backports.
Package: firewalld Version: 0.7.1-1 Severity: wishlist Dear Maintainer, firewalld 0.7 introduces sufficient new capabilities that it would be great to see it more widely available in the stable distribution. I would like to suggest that it be added to buster-backports. It does not appear to have any version conflicts with the dependencies shipped in buster; hopefully there is no significant work involved here. Let me know what you think. Thanks.
Bug#939200: linux-image-5.2.0-2-amd64: M.2 I210 Ethernet adapter (igb) suddenly very high latency with kernel 5.2
Package: src:linux Version: 5.2.9-2 Severity: normal Dear Maintainer, This system is an Intel NUC with an onboard Intel I219-LM Ethernet adapter (e1000e) and an additional dual Intel I210 Ethernet adapter (igb) connected via the onboard M.2 interface (M.2 Dual Ethernet supplied by G2 Digital; I suspect but cannot confirm that this is an Innodisk EGPL-G201 card.) The only out-of-tree kernel modules are from the ZFSonLinux subsystem. As configured on this system, the e1000e interface is eno1, and the two igb interfaces are dmz0 (renamed from enp3s0) and enp4s0. Under kernel 4.19.0-5, the latency experienced from the igb interfaces to the local LAN was what one would expect - generally in the 0.1 to 0.5ms range. Under kernel 5.2.0-2, the latency on these interfaces has jumped to the 60-600ms range (variable, but consistently very high). The I219 (e1000e) interface's latency seems unaffected. Flood-pinging this system from a third system seems to reduce the average latency by about half. The only change was installing the 5.2.0-2 kernel and rebooting. The former latency is recoverable by rebooting into 4.19.0. Can I supply any additional system information? -- Package-specific info: ** Version: Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21) ** Command line: BOOT_IMAGE=/rootfs@/boot/vmlinuz-5.2.0-2-amd64 root=ZFS=bootdisk/rootfs ro ** Tainted: POE (12289) * Proprietary module has been loaded. * Out-of-tree module has been loaded. * Unsigned module has been loaded. ** Kernel log: [3.665372] usb 1-5: SerialNumber: G114J52310 [3.671046] hidraw: raw HID events driver (C) Jiri Kosina [3.797133] usb 1-7: new low-speed USB device number 4 using xhci_hcd [3.956891] usb 1-7: New USB device found, idVendor=258a, idProduct=0001, bcdDevice= 1.00 [3.958061] usb 1-7: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [3.959226] usb 1-7: Product: USB KEYBOARD [3.960390] usb 1-7: Manufacturer: SINO WEALTH [4.774833] ZFS: Loaded module v0.8.1-4, ZFS pool version 5000, ZFS filesystem version 5 [5.568481] usbcore: registered new interface driver usbhid [5.571097] usbhid: USB HID core driver [5.593534] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist. [5.743963] systemd[1]: Inserted module 'autofs4' [5.831962] systemd[1]: systemd 242 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid) [5.853427] systemd[1]: Detected architecture x86-64. [5.860395] systemd[1]: Set hostname to . [5.862534] systemd[1]: Failed to bump fs.file-max, ignoring: Invalid argument [6.103727] systemd-crontab-generator[485]: ignoring /etc/cron.d/certbot because native timer is present [6.187978] systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references a path below legacy directory /var/run/, updating /var/run/nut/upsmon.pid \xe2\x86\x92 /run/nut/upsmon.pid; please update the unit file accordingly. [6.208892] systemd[1]: /lib/systemd/system/dbus.socket:4: ListenStream= references a path below legacy directory /var/run/, updating /var/run/dbus/system_bus_socket \xe2\x86\x92 /run/dbus/system_bus_socket; please update the unit file accordingly. [6.211950] systemd[1]: Listening on udev Control Socket. [6.213843] systemd[1]: Listening on Journal Audit Socket. [6.216240] systemd[1]: Created slice User and Session Slice. [6.218313] systemd[1]: Listening on Network Service Netlink Socket. [6.241553] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) [6.376795] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0 [6.380006] ACPI: Sleep Button [SLPB] [6.381971] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1 [6.381979] ACPI: Power Button [PWRB] [6.382022] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [6.382030] ACPI: Power Button [PWRF] [6.403896] systemd-journald[509]: Received request to flush runtime journal from PID 1 [6.423680] EFI Variables Facility v0.08 2004-May-17 [6.428676] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1A, rev-id 16) [6.466288] input: PC Speaker as /devices/platform/pcspkr/input/input3 [6.469151] input: SINO WEALTH USB KEYBOARD as /devices/pci:00/:00:14.0/usb1/1-7/1-7:1.0/0003:258A:0001.0001/input/input4 [6.469924] sd 0:0:0:0: Attached scsi generic sg0 type 0 [6.472942] RAPL PMU: API unit is 2^-32 Joules, 5 fixed counters, 655360 ms ovfl timer [6.474316] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules [6.475715] RAPL PMU: hw unit of domain package 2^-14 Joules [6.477044] RAPL PMU: hw unit of domain dram 2^-14 Joules [6.478423] RAPL PMU: hw unit of domain pp1-gpu 2^-14
Bug#914526: linux-image-4.18.0-0.bpo.1-amd64: Invalidating filesystems can corrupt dentry table leading to busy loop in kernel.
Package: src:linux Version: 4.18.6-1~bpo9+1 Severity: important Tags: upstream patch Please see https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/commit/?h=for-linus - invalidating filesystems can cause dentry table corruption leading to busy loop in kernel. Easily triggered from userspace (observed triggers using NFS, XFS and ZFS). Patch supplied upstream; please consider cherrypicking this to BPO kernel. Thanks. -- Package-specific info: ** Version: Linux version 4.18.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.18.6-1~bpo9+1 (2018-09-13) ** Command line: BOOT_IMAGE=/boot@/boot/vmlinuz-4.18.0-0.bpo.1-amd64 root=ZFS=rpool/boot ro ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: product_name: product_version: chassis_vendor: chassis_version: bios_vendor: Intel Corporation bios_version: MYBDWi30.86A.0038.2016.0913.1446 board_vendor: Intel Corporation board_name: NUC5i3MYBE board_version: H47781-206 ** Loaded modules: xt_nat cfg80211 xt_tcpmss ipt_MASQUERADE xt_limit xt_recent ip6table_nat nf_nat_ipv6 ip6t_REJECT nf_reject_ipv6 ip6table_mangle ip6table_raw nf_conntrack_ipv6 nf_defrag_ipv6 nf_log_ipv6 ip6table_filter ip6_tables xt_comment iptable_nat nf_nat_ipv4 ipt_REJECT nf_reject_ipv4 xt_addrtype bridge xt_mark iptable_mangle xt_TCPMSS xt_tcpudp xt_CT iptable_raw xt_multiport nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack xt_NFLOG xt_LOG nf_log_ipv4 nf_log_common nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_nat nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp nf_conntrack libcrc32c crc32c_generic iptable_filter nfnetlink_queue nfnetlink_log nfnetlink bluetooth drbg ansi_cprng ecdh_generic rfkill crc16 pppoe pppox ppp_generic slhc binfmt_misc nls_ascii nls_cp437 vfat fat intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt iTCO_vendor_support evdev kvm i915 irqbypass crct10dif_pclmul crc32_pclmul pl2303 drm_kms_helper usbserial ghash_clmulni_intel sg drm intel_cstate mei_me mei intel_uncore lpc_ich pcspkr efi_pstore intel_rapl_perf efivars video button acpi_pad pcc_cpufreq bonding 8021q garp mrp stp llc efivarfs ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) sd_mod crc32c_intel ahci libahci libata igb i2c_algo_bit scsi_mod dca aesni_intel xhci_pci ehci_pci xhci_hcd ehci_hcd aes_x86_64 crypto_simd i2c_i801 cryptd glue_helper usbcore e1000e usb_common fan thermal ** PCI devices: not available ** USB devices: Bus 001 Device 002: ID 8087:8001 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 002: ID 2109:0813 VIA Labs, Inc. Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 002 Device 004: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303] Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 002 Device 002: ID 2109:2813 VIA Labs, Inc. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (700, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.18.0-0.bpo.1-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.130 ii kmod23-2 ii linux-base 4.5 Versions of packages linux-image-4.18.0-0.bpo.1-amd64 recommends: ii apparmor 2.11.0-3+deb9u2 ii firmware-linux-free 3.4 ii irqbalance 1.1.0-2.3 Versions of packages linux-image-4.18.0-0.bpo.1-amd64 suggests: pn debian-kernel-handbook ii grub-efi-amd64 2.02~beta3-5+deb9u1 pn linux-doc-4.18 Versions of packages linux-image-4.18.0-0.bpo.1-amd64 is related to: ii firmware-amd-graphics 20180825+dfsg-1~bpo9+1 pn firmware-atheros pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv pn firmware-iwlwifi pn firmware-libertas ii firmware-linux-nonfree20180825+dfsg-1~bpo9+1 ii firmware-misc-nonfree
Bug#910607:
Per upstream; this seems to be a kernel bug which is fixed in 4.18.20. Unclear whether the fix (1e9c75fb9c47a75a9aec0cd17db5f6dc36b58e00) can be cherrypicked back to current stable / bpo kernels; investigating.
Bug#887743:
This is fixed by https://github.com/att/ast/pull/63/ - should be ok to pull from upstream. Colm -- Colm Buckley / c...@tuatha.org / +353 87 2469146
Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: #826994: Bug#826994: Missing init-script(s)?
... which is exactly what the patch does. On Fri 19 Oct 2018, 18:45 Petter Reinholdtsen > > [Richard Laager] > > The sysvinit scripts are already in the upstream tree and the released > > tarballs. You can see them in the package's .orig.tar.gz in the > > etc/init.d directory. The patch simply calls dh_installinit in > > debian/rules as appropriate. > > Right, then I had misunderstood, at least. If the script is already > upstream, it is Debians responsibility to add code to install it at the > correct location. > > -- > Vennlig hilsen > Petter Reinholdtsen > > ___ > Pkg-zfsonlinux-devel mailing list > pkg-zfsonlinux-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel
Bug#910607: zfs-linux: 'zfs receive' can apparently corrupt system mount table.
Source: zfs-linux Version: v0.7.11-1 Severity: important Tags: upstream Descendent filesystems which have out-of-tree mount points are not correctly recovered on 'zfs send | zfs receive', leading to apparent corruption of the mount table. With kernel 4.18, processes accessing problematic parts of the filesystem can become wedged. See full report in upstream at https://github.com/zfsonlinux/zfs/issues/7970 -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (700, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#897568: Stretch with backports kernel is also affected
In an ideal world, this need not be a problem; we typically see ZoL releases supporting new kernels well before those kernels hit Debian backports. Unfortunately, however, there is a chicken-and-egg problem; the Debian package maintainers need to be confident that the zfs-linux packages will work with both new and existing kernels (on all supported architectures) before a release can be made, and the BPO kernel maintainers occasionally include forward patches from other kernel trees. It's not impossible to make this work, but it is labor-intensive and has an unpredictable schedule. Colm
Bug#893578: [zfs-linux] Please package 0.7.8
I don't wish to be rude - but there has been an unusually long period with no developer activity regarding this package; and the developers' mailing list seems to have been removed or reconfigured. Is everything in order? Are more maintainers needed? Colm
Bug#880647: Suggest symlinks to binaries from /usr/bin
Package: zfsutils-linux
Version: 0.7.3-1
As 'zfs allow' now allows certain functions to be executed by any user, I
suggest a symbolic link from /usr/bin/zfs to /usr/sbin/{zfs, zpool} be
included.
Bug#822431: Set PYTHONHASHSEED=0 when calling systemd-crontab-generator
Given that the Python bug discussion is inclining against changing the Python runtime behavior, a workaround would be to arrange for the environment variable PYTHONHASHSEED to be set to the value "0" when calling systemd-crontab-generator. This could be done dumbly by a shell script which in turn calls the current crontab generator, but it strikes me that there might be a more elegant way. Any takers? Colm -- Colm Buckley / c...@tuatha.org / +353 87 2469146
