Re: Upcoming changes to Debian Linux kernel packages
On Mon, 2023-09-25 at 04:35 +0200, Andreas Beckmann wrote: > On 25/09/2023 00.50, Bastian Blank wrote: > > Already built modules remain until someone deletes it. So you can > > also > > switch back to the still installed older kernel version and it will > > have > > the still working module available. > > This is what I expect not to work. > > Assume I have Linux 6.6 and a third-party gpu driver module installed > (so there are dkms and the Linux 6.6 headers as well) and everything > is > working fine. > Then I upgrade the system, which brings Linux 6.7 (along linux-image- > 6.6 > which is kept installed) and a new version of the gpu driver (which > adds > support for 6.7). So the old gpu module for 6.6 gets removed and a > new > one is built for 6.7 only (since there are only 6.7 headers now). > Unfortunately 6.7 breaks some exotic in-tree driver (which I > desperately > need), so I need to go back to 6.6. Oops, there is no gpu driver > module > any more. Recovery now needs manual intervention. Same concern here. We cannot pose strong assumption on the user's upgrade path. The said scenario may happen for any dkms package when the newer kernel version is not supported. > I'm not sure which class of bugs you are trying to solve with this > proposed unversioned linux-headers change. IMO the current scheme of > linux-headers-$version-$abi-$flavor matching > linux-image-$version-$abi-$flavor works well. But perhaps something > could be improved on the metapackage side. Ideally a user should > install > either meta-linux-image-without-headers-$flavor OR > meta-linux-image-with-headers-$flavor (and ideally installing dkms > should "automatically switch" to the with-headers variant, not sure > how > this could be done). The current scheme of having to install > linux-image-$flavor AND linux-headers-$flavor is a bit tricky. > I'm open to implement improvements on the dkms side. I could not understand the benefit of it neither. Apart from the dkms part, the user-customized kernel packages cannot be omitted as well. For instance, if I build a customized kernel from debian's kernel source, using `make bindeb-pkg`, I get those: linux-headers-6.5.3_6.5.3-2_amd64.deb linux-image-6.5.3_6.5.3-2_amd64.deb linux-libc-dev_6.5.3-2_amd64.deb Currently they are well integrated into the system, and IIRC dkms also works for them. If versioning is gone, how to make it compatible with user's local kernel package? There must be two copies of kernel headers in the system in this case because we cannot remove user's local customized headers on our own. Then the design still has to support multi version co-existence.
Re: Upcoming changes to Debian Linux kernel packages
On 25/09/2023 00.50, Bastian Blank wrote: Already built modules remain until someone deletes it. So you can also switch back to the still installed older kernel version and it will have the still working module available. This is what I expect not to work. Assume I have Linux 6.6 and a third-party gpu driver module installed (so there are dkms and the Linux 6.6 headers as well) and everything is working fine. Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6 which is kept installed) and a new version of the gpu driver (which adds support for 6.7). So the old gpu module for 6.6 gets removed and a new one is built for 6.7 only (since there are only 6.7 headers now). Unfortunately 6.7 breaks some exotic in-tree driver (which I desperately need), so I need to go back to 6.6. Oops, there is no gpu driver module any more. Recovery now needs manual intervention. I'm not sure which class of bugs you are trying to solve with this proposed unversioned linux-headers change. IMO the current scheme of linux-headers-$version-$abi-$flavor matching linux-image-$version-$abi-$flavor works well. But perhaps something could be improved on the metapackage side. Ideally a user should install either meta-linux-image-without-headers-$flavor OR meta-linux-image-with-headers-$flavor (and ideally installing dkms should "automatically switch" to the with-headers variant, not sure how this could be done). The current scheme of having to install linux-image-$flavor AND linux-headers-$flavor is a bit tricky. I'm open to implement improvements on the dkms side. Andreas PS: the proposed "more versioning in the linux-image packages" will solve some rare dkms issues where modules didn't get rebuilt after linux-headers-* was upgraded but $(uname -r) didn't change
Bug#1040901: Upcoming changes to Debian Linux kernel packages
Hi Ben On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote: > On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote: > > The same upstream version in testing and backports will have the same > > package name. > This is not OK, because they will be incompatible on architectures > supporting SB (and sometimes incompatible on others due to compiler > differences or required config changes). I don't know what you are talking about. Those two packages have different versions, so won't contain anything compatible. It is the same between 1.2.3-1 vs 1.2.3-2 and 1.2.3-1~bpo13+1 vs 1.2.3-1. > If someone upgrades from stable + backports to testing, and has OOT > modules: > - With DKMS, will a rebuild be triggered if the linux-image package > name doesn't change? The same as with a normal package upgrade, it will rebuilt against the new version. It just runs into the same version skew as everything else. > - With module-assistant, the new linux-image package will satisfy > dependencies of the old modules even though they are incompatible. No, the two linux-image packages have different versions, so won't satisfy the dependencies. > > Multiple uploads of the same upstream version will have > > the same package name, but those rarely happens. > Those happen fairly often for urgent security updates. Right. Maybe we need a manual or automatic override for this, we can do a lot of things. > > It will not longer be possible to reliably derive the package name from > > kernel release (see above), as both values are not really related > > anymore. > Given all the drawbacks, I don't see the benefit of decoupling package > names from release strings. > In the same way that shared library packages must be renamed for every > backward-incompatible ABI changes, I believe we should keep doing this > for linux-image packages. Noted, but I don't see a way to do that. We can't map versions cleanly into package names. We have binNMU, which can't change package names, so will already in violation of that. And we already don't do that, see that huge version ignore list. Also the ABI in shared libraries is to have two independent updateable identities. Nothing is true in case of the kernel, it will just break on every update of either side, which would be the equivalent of a = dependency. So no, shared libraries are not a good comparison. > > ## Header and tool packages will not longer contain version > > > > The headers packages will not longer include the version. It won't be > > reliably possible to derive the package name anyway from the running > > kernel. > > > > This means that only headers of one single version can be available on > > the system at one time. This might be a bit inconvinient for dkms, as > > it can't longer build modules for multiple versions. > > > > But we too often have the problem that image and headers go out of sync > > and then you can't find the correct ones anyway. > > > > Example: linux-headers-cloud-arm64 > > This is all downside with no justification given. Please explain what > the benefit is. The current way does not work. See all the bug reports about uninstallable packages and what not with dkms. To build modules against version x, you'll need to install version x of the headers, not x-1 or x+1. This currently works most of the time, but is by far stable. And if you already have to search for the specific version, it does not matter if you might have the ability to install multiple at the same time, the archive will in any case only contain one version at a time. IMHO the only way around would be to install image and headers always in one piece for those who want to build own modules against. But this will require further restructuring, as the headers for this then need to be built from linux-signed-* and arch-any to be without skew. And use proper dependencies so everything is installed with the same version always. Aka something like that: Package: linux-image-cloud-arm64 Depends: linux-image-1.2.3-cloud-arm64 (= 1.2.3-1) Package: linux-modules-thirdparty-cloud-arm64 Depends: linux-image-1.2.3-cloud-arm64 (= 1.2.3-1), linux-modules-1.2.3-cloud-arm64 (= 1.2.3-1), linux-headers-1.2.3-cloud-arm64 (= 1.2.3-1) Package: linux-image-1.2.3-cloud-arm64 Depends: linux-modules-1.2.3-cloud-arm64 (= 1.2.3-1) Package: linux-headers-1.2.3-cloud-arm64 Depends: linux-modules-1.2.3-cloud-arm64 (= 1.2.3-1) Package: linux-modules-1.2.3-cloud-arm64 However doesn't building modules currently need the vmlinux as well? Which would not be fullfiled anyway right now. > > ## Installer packages will not longer contain too much version > > > > The installer can only ever handle one version of kernel. Also it got > > an internal mechanism to detect which packages belong together > > (the Kernel-Version control entry). So we have no need to rename them > > and force a matching change in d-i itself just because a new kernel > > exists. So it wil
Bug#1052584: linux-image-6.5.0-1-amd64: NFS4 stopped working in 6.5 with SELinux error
Package: src:linux Version: 6.5.3-1 Severity: normal Dear Maintainer, After upgrading to kernel version 6.5.0-1-amd64, the NFS4 stopped working on the station. Whe trying to mount nf4 FS, the mount fails with error: mount.nfs: an incorrect mount option was specified for The kernel log contains error message: kernel: SELinux: Unable to set superblock options before the security server is initialized This puzzles me a bit as I've got SELinux disabled (don't even have SELinux userspace installed, /sys/fs/selinux/enforce says 0). Tried booting with selinux=0 boot parameter but with the same result. Rebooting wih previou (6.4.0-4-amd64) kernel version fixes the problem immediately. -- Package-specific info: ** Version: Linux version 6.5.0-1-amd64 (debian-kernel@lists.debian.org) (gcc-13 (Debian 13.2.0-4) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1 (2023-09-13) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.5.0-1-amd64 root=UUID=66909970-fb76-4ca1-ac09-21ce627d56fb ro acpi_osi=Linux apparmor=0 quiet resume=UUID=83a4e08d-09cd-40d7-815f-060f24d8ed07 ** Not tainted ** Kernel log: [ 4.333757] AVX2 version of gcm_enc/dec engaged. [ 4.333908] AES CTR mode by8 optimization enabled [ 4.335361] snd_hda_intel :34:00.1: enabling device ( -> 0002) [ 4.336166] snd_hda_intel :34:00.1: Handle vga_switcheroo audio client [ 4.336173] input: SYNA8018:00 06CB:CE67 Mouse as /devices/platform/AMDI0010:01/i2c-1/i2c-SYNA8018:00/0018:06CB:CE67.0001/input/input13 [ 4.336314] input: SYNA8018:00 06CB:CE67 Touchpad as /devices/platform/AMDI0010:01/i2c-1/i2c-SYNA8018:00/0018:06CB:CE67.0001/input/input14 [ 4.336456] hid-multitouch 0018:06CB:CE67.0001: input,hidraw0: I2C HID v1.00 Mouse [SYNA8018:00 06CB:CE67] on i2c-SYNA8018:00 [ 4.336927] snd_hda_intel :34:00.6: enabling device ( -> 0002) [ 4.339656] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked [ 4.346487] videodev: Linux video capture interface: v2.00 [ 4.349686] thinkpad_acpi: rfkill switch tpacpi_wwan_sw: radio is unblocked [ 4.356589] snd_hda_intel :34:00.1: bound :34:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu]) [ 4.366123] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one [ 4.368909] input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci:00/:00:08.1/:34:00.1/sound/card0/input16 [ 4.369050] input: HD-Audio Generic HDMI/DP,pcm=7 as /devices/pci:00/:00:08.1/:34:00.1/sound/card0/input17 [ 4.369175] input: HD-Audio Generic HDMI/DP,pcm=8 as /devices/pci:00/:00:08.1/:34:00.1/sound/card0/input18 [ 4.378763] acp_yc_mach acp_yc_mach.0: Enabling ACP DMIC support via DMI [ 4.378827] acp_yc_mach acp_yc_mach.0: Enabling ACP DMIC support via DMI [ 4.414400] thinkpad_acpi: battery 1 registered (start 0, stop 100, behaviours: 0x7) [ 4.414423] ACPI: battery: new extension: ThinkPad Battery Extension [ 4.421306] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC257: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 4.421312] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 4.421315] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 4.421318] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 4.421320] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 4.421322] snd_hda_codec_realtek hdaudioC1D0: Mic=0x19 [ 4.421660] usb 5-1: Found UVC 1.10 device Integrated Camera (174f:1812) [ 4.429655] usb 5-1: Found UVC 1.50 device Integrated Camera (174f:1812) [ 4.431756] usbcore: registered new interface driver uvcvideo [ 4.451513] ath11k_pci :01:00.0: BAR 0: assigned [mem 0x9880-0x989f 64bit] [ 4.451533] ath11k_pci :01:00.0: enabling device ( -> 0002) [ 4.451643] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input12 [ 4.452347] ath11k_pci :01:00.0: MSI vectors: 32 [ 4.452355] ath11k_pci :01:00.0: wcn6855 hw2.1 [ 4.458975] NET: Registered PF_QIPCRTR protocol family [ 4.470682] input: HDA Digital PCBeep as /devices/pci:00/:00:08.1/:34:00.6/sound/card1/input19 [ 4.470771] input: HD-Audio Generic Mic as /devices/pci:00/:00:08.1/:34:00.6/sound/card1/input20 [ 4.470850] input: HD-Audio Generic Headphone as /devices/pci:00/:00:08.1/:34:00.6/sound/card1/input21 [ 4.529613] Bluetooth: Core ver 2.22 [ 4.529643] NET: Registered PF_BLUETOOTH protocol family [ 4.529645] Bluetooth: HCI device and connection manager initialized [ 4.529650] Bluetooth: HCI socket layer initialized [ 4.529656] Bluetooth: L2CAP socket layer initialized [ 4.529667] Bluetooth: SCO socket layer initialized [ 4.541302] kvm_amd: TSC scaling supported [ 4.541305] kvm_amd: Nested Virtualization enabled [ 4.541307] kvm_amd: Nested Paging enabled [ 4.541315] kvm_am
Re: Upcoming changes to Debian Linux kernel packages
Hi Andreas On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote: > On 24/09/2023 15.01, Bastian Blank wrote: > > ## Kernel modules will be signed with an ephemeral key > > > > The modules will not longer be signed using the Secure Boot CA like the > > EFI kernel image itself. Instead a key will be created during the build > > and thrown away after. > > Do I correctly assume that change only affects the modules shipped by the > linux-image packages and not third-party modules built with dkms? Yes. Nothing calls for changes to MOK keys, which are used by dkms. > > ## Header and tool packages will not longer contain version > > > This means that only headers of one single version can be available on > > the system at one time. This might be a bit inconvinient for dkms, as > > it can't longer build modules for multiple versions. > > That sounds problematic in case of third party modules. If it is possible to > have multiple linux-image-* packages installed, but only headers for one of > them, the third-party modules will only be available for one of the kernel > versions for sure (maybe there are still old module builds available, but no > guarantee especially after the third-party module got updated). This will > make switching between different kernel versions difficult to impossible, > e.g. it may be hard to go back to a working older kernel version in case the > new one does not work properly (or the third-party module cannot be built or > does not work for the new version). Already built modules remain until someone deletes it. So you can also switch back to the still installed older kernel version and it will have the still working module available. Yes, you would not be able to build new modules for the older kernel until you also install the matching headers. > Regarding getting the correct linux-header-* packages installed for the > installed linux-image-* packages: > Maybe linux-image-* could have > Recommends: linux-headers-* | no-linux-headers > s.t. the correct linux-headers-* are installed by default (installation of > recommends is enabled by default) for all installed linux-image-* packages. > no-linux-headers would be an opt-out package that can be installed manually > if someone does not want to get linux-headers-* installed at all. It should > never be installed automatically. Nack. I actually thought about that. But third-party modules are too much a special configuration to do that and pay the 50MiB or so penalty for each system. Also this still have the version skew problem between linux and linux-signed-*, so will be unreliable. > For dkms it is hard recommend the correct linux-header-* package, right now > we have > Recommends: linux-headers-generic | linux-headers-686-pae | > linux-headers-amd64 | linux-headers > which does not really work for the non-default kernel flavor, e.g. the > -cloud or -i386 kernel. So some improvement on the kernel side would be nice > here. I thought about adding a versioned provides with the complete kernel release string as version, so something like | Provides: linux-headers (= $(uname -r)) This can then be installed via apt-get and the correct version as long as the package is available. This however can't be done via dependencies, because it is dynamic. So dkms would need to actively make sure it got the correct package, if they are still reachable at all. Bastian -- We have found all life forms in the galaxy are capable of superior development. -- Kirk, "The Gamesters of Triskelion", stardate 3211.7
Re: Upcoming changes to Debian Linux kernel packages
On 24/09/2023 15.01, Bastian Blank wrote: ## Kernel modules will be signed with an ephemeral key The modules will not longer be signed using the Secure Boot CA like the EFI kernel image itself. Instead a key will be created during the build and thrown away after. Do I correctly assume that change only affects the modules shipped by the linux-image packages and not third-party modules built with dkms? ## Header and tool packages will not longer contain version This means that only headers of one single version can be available on the system at one time. This might be a bit inconvinient for dkms, as it can't longer build modules for multiple versions. That sounds problematic in case of third party modules. If it is possible to have multiple linux-image-* packages installed, but only headers for one of them, the third-party modules will only be available for one of the kernel versions for sure (maybe there are still old module builds available, but no guarantee especially after the third-party module got updated). This will make switching between different kernel versions difficult to impossible, e.g. it may be hard to go back to a working older kernel version in case the new one does not work properly (or the third-party module cannot be built or does not work for the new version). Regarding getting the correct linux-header-* packages installed for the installed linux-image-* packages: Maybe linux-image-* could have Recommends: linux-headers-* | no-linux-headers s.t. the correct linux-headers-* are installed by default (installation of recommends is enabled by default) for all installed linux-image-* packages. no-linux-headers would be an opt-out package that can be installed manually if someone does not want to get linux-headers-* installed at all. It should never be installed automatically. For dkms it is hard recommend the correct linux-header-* package, right now we have Recommends: linux-headers-generic | linux-headers-686-pae | linux-headers-amd64 | linux-headers which does not really work for the non-default kernel flavor, e.g. the -cloud or -i386 kernel. So some improvement on the kernel side would be nice here. Andreas
Bug#1052554: Acknowledgement (linux-image-6.5.0-1-amd64: amdgpu crashes)
I don't have this bug when booting kernel 6.4.13-1 (2023-08-31). It looks like I have a problem as described here: https://unix.stackexchange.com/questions/756281/kernel-6-5-2-seems-to-have-amdgpu-crash-on-no-retry-page-fault Thank you! Debian Bug Tracking System schrieb am So., 24. Sept. 2023, 18:33: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1052554: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052554. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > As you requested using X-Debbugs-CC, your message was also forwarded to > flor...@reichl.net > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > Debian Kernel Team > > If you wish to submit further information on this problem, please > send it to 1052...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1052554: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052554 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > >
Bug#1052472: linux-image-6.5.0-1-powerpc64: Can't run program if its executable file was made immutable via chattr(1)
Control: reassign -1 src:zfs-linux
On Fri, 2023-09-22 at 16:13 +, WHR wrote:
> Package: src:linux
> Version: 6.5.3-1
> Severity: normal
> X-Debbugs-Cc: msl023...@gmail.com, msl023...@gmail.com
>
>
> Taking executable file /usr/bin/ssh to demonstrate the issue:
>
> # which ssh
> /usr/bin/ssh
> # ssh
>
> usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
> [-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
> [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
> [-i identity_file] [-J [user@]host[:port]] [-L address]
> [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p
> port]
> [-Q query_option] [-R address] [-S ctl_path] [-W host:port]
> [-w local_tun[:remote_tun]] destination [command]
> # chattr +i /usr/bin/ssh
>
> # ssh
> Segmentation fault
>
>
> By trying to load the program via ld.so(1) with truss (actually strace), it
> shows that a mmap(2) call used to load the data segument failed due to EPERM:
>
> # truss -s 128 -f /lib/powerpc64-linux-gnu/ld64.so.1 /usr/bin/ssh
> execve("/lib/powerpc64-linux-gnu/ld64.so.1",
> ["/lib/powerpc64-linux-gnu/ld64.so.1", "/usr/bin/ssh"], 0x7fffc0380530 /* 29
> vars */) = 0
> brk(NULL) = 0x1000db6
> openat(AT_FDCWD, "/usr/bin/ssh", O_RDONLY|O_CLOEXEC) = 3
> read(3,
> "\177ELF\2\2\1\0\0\0\0\0\0\0\0\0\0\3\0\25\0\0\0\1\0\0\0\0\0\22h\220\0\0\0\0\0\0\0@\0\0\0\0\0\22\4\330\0\0\0\1\0@\08\0\t\0@\0\35\0\34\0\0\0\6\0\0\0\4\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\1\370\0\0\0\0\0\0\1\370\0\0\0\0\0\0\0\10\0\0\0\3\0\0\0\4"...,
> 832) = 832
> mmap(NULL, 1259760, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
> 0) = 0x7fff9372
> mprotect(0x7fff9383, 65536, PROT_NONE) = 0
> mmap(0x7fff9384, 131072, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11) = -1 EPERM (Operation not
> permitted)
> close(3)= 0
> writev(2, [{iov_base="/usr/bin/ssh", iov_len=12}, {iov_base=": ",
> iov_len=2}, {iov_base="error while loading shared libraries", iov_len=36},
> {iov_base=": ", iov_len=2}, {iov_base="/usr/bin/ssh", iov_len=12},
> {iov_base=": ", iov_len=2}, {iov_base="failed to map segment from shared
> object", iov_len=40}, {iov_base="", iov_len=0}, {iov_base="", iov_len=0},
> {iov_base="\n", iov_len=1}], 10/usr/bin/ssh: error while loading shared
> libraries: /usr/bin/ssh: failed to map segment from shared object
> ) = 107
> exit_group(127) = ?
> +++ exited with 127 +++
>
>
> I can also reproduce this issue on Bullseye (with Linux 5.10.0-21-amd64);
> while Buster (Linux 4.19.0-23-amd64) is fine.
[...]
> ** Command line:
> root=ZFS=zr/ROOT/debiansid-be ro quiet
> cgroup_enable=cpuset,cpu,cpuacct,blkio,memory,devices,freezer,net_cls,perf_event,net_prio
> systemd.unified_cgroup_hierarchy=0
> net.ifname-policy=keep,onboard,slot,path,kernel zfs.zfs_txg_timeout=60
> zfs.zfs_arc_max=2166172771 init=/init
[...]
I can't reproduce this on an ext4 filesystem, so I think ZFS is the
problem.
ZFS has its own check that blocks a writable mmap of an immutable file,
without taking MAP_PRIVATE into account:
https://sources.debian.org/src/zfs-linux/2.1.12-2/module/os/linux/zfs/zfs_vnops_os.c/#L3908
Ben.
--
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.
signature.asc
Description: This is a digitally signed message part
Processed: Re: Bug#1052472: linux-image-6.5.0-1-powerpc64: Can't run program if its executable file was made immutable via chattr(1)
Processing control commands: > reassign -1 src:zfs-linux Bug #1052472 [src:linux] linux-image-6.5.0-1-powerpc64: Can't run program if its executable file was made immutable via chattr(1) Bug reassigned from package 'src:linux' to 'src:zfs-linux'. No longer marked as found in versions linux/6.5.3-1. Ignoring request to alter fixed versions of bug #1052472 to the same values previously set -- 1052472: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052472 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1052554: linux-image-6.5.0-1-amd64: amdgpu crashes
Package: src:linux Version: 6.5.3-1 Severity: important X-Debbugs-Cc: flor...@reichl.net Dear Maintainer, * What led up to the situation? Booting the new kernel and surfing the web using Google Chrome. After some more complex pages the screen shows unusual things and mouse and keyboard are locked. * What exactly did you do (or not do) that was effective (or ineffective)? I was trying Firefox instead. Worked for a while but then crashed again. * What was the outcome of this action? Crash. * What outcome did you expect instead? A browser that just works -- Package-specific info: ** Version: Linux version 6.5.0-1-amd64 (debian-kernel@lists.debian.org) (gcc-13 (Debian 13.2.0-4) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1 (2023-09-13) ** Command line: BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.5.0-1-amd64 root=UUID=add579a2-e1f1-4f37-b506-636e409dffad ro rootflags=subvol=@rootfs quiet ** Not tainted ** Kernel log: [ 13.019356] kvm_amd: TSC scaling supported [ 13.019363] kvm_amd: Nested Virtualization enabled [ 13.019365] kvm_amd: Nested Paging enabled [ 13.019379] kvm_amd: Virtual VMLOAD VMSAVE supported [ 13.019380] kvm_amd: Virtual GIF supported [ 13.019382] kvm_amd: LBR virtualization supported [ 13.043037] iwlwifi :03:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340 [ 13.043256] thermal thermal_zone0: failed to read out thermal zone (-61) [ 13.046305] MCE: In-kernel MCE decoding enabled. [ 13.140522] intel_rapl_common: Found RAPL domain package [ 13.140528] intel_rapl_common: Found RAPL domain core [ 13.201985] NET: Registered PF_QIPCRTR protocol family [ 13.215799] iwlwifi :03:00.0: Detected RF HR B3, rfid=0x10a100 [ 13.289402] iwlwifi :03:00.0: base HW address: a8:7e:ea:05:35:d4 [ 13.313199] iwlwifi :03:00.0 wlp3s0: renamed from wlan0 [ 13.536591] Generic FE-GE Realtek PHY r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC) [ 13.666373] r8169 :02:00.0 enp2s0f0: Link is Down [ 13.676522] r8169 :05:00.0: firmware: direct-loading firmware rtl_nic/rtl8168h-2.fw [ 13.704369] Generic FE-GE Realtek PHY r8169-0-500:00: attached PHY driver (mii_bus:phy_addr=r8169-0-500:00, irq=MAC) [ 13.721290] mc: Linux media interface: v0.10 [ 13.737142] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 13.769093] videodev: Linux video capture interface: v2.00 [ 13.903922] r8169 :05:00.0 enp5s0: Link is Down [ 13.925922] usb 2-2: Found UVC 1.10 device Integrated Camera (04f2:b6d0) [ 13.934045] usb 2-2: Found UVC 1.50 device Integrated Camera (04f2:b6d0) [ 13.935705] usbcore: registered new interface driver uvcvideo [ 13.984813] Bluetooth: Core ver 2.22 [ 13.984864] NET: Registered PF_BLUETOOTH protocol family [ 13.984866] Bluetooth: HCI device and connection manager initialized [ 13.984873] Bluetooth: HCI socket layer initialized [ 13.984877] Bluetooth: L2CAP socket layer initialized [ 13.984884] Bluetooth: SCO socket layer initialized [ 14.138984] usbcore: registered new interface driver btusb [ 14.156623] bluetooth hci0: firmware: direct-loading firmware intel/ibt-20-1-3.sfi [ 14.159892] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi [ 14.159912] Bluetooth: hci0: Boot Address: 0x24800 [ 14.159914] Bluetooth: hci0: Firmware Version: 255-255.255 [ 14.162837] usb 6-4: USB disconnect, device number 3 [ 14.163352] Bluetooth: hci0: FW download error recovery failed (-19) [ 14.164889] Bluetooth: hci0: sending frame failed (-19) [ 14.166311] Bluetooth: hci0: Reading supported features failed (-19) [ 14.167424] Bluetooth: hci0: Error reading debug features [ 14.167428] Bluetooth: hci0: HCI LE Coded PHY feature bit is set, but its usage is not supported. [ 14.168720] iwlwifi :03:00.0: Registered PHC clock: iwlwifi-PTP, with index: 0 [ 14.240820] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 14.240826] Bluetooth: BNEP filters: protocol multicast [ 14.240833] Bluetooth: BNEP socket layer initialized [ 14.346097] r8169 :02:00.0: invalid VPD tag 0x00 (size 0) at offset 0; assume missing optional EEPROM [ 14.494222] pipewire[1560]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set [ 14.604320] usb 6-4: new full-speed USB device number 4 using xhci_hcd [ 14.620335] serial :02:00.1: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update [ 14.752311] serial :02:00.2: VPD access failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update [ 14.779698] usb 6-4: New USB device found, idVendor=8087, idProduct=0029, bcdDevice= 0.01 [ 14.779707] usb 6-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 14.792712] Bluetooth: hci0: Bootloader revision 0.3 build 0 week 24 2017 [ 14.794735] Bluetooth: hci0: Device revision is 1 [ 14.794739] Bluetooth: hc
Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages
On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote: [...] > ## Kernel modules will be signed with an ephemeral key > > The modules will not longer be signed using the Secure Boot CA like the > EFI kernel image itself. Instead a key will be created during the build > and thrown away after. > > Yes, this will make the build unreproducible, but no better solution > currently exists. There are some plans, but no-one is working on them. > If a suitable replacement shows up, we can always switch to that > solution. Builds for the architectures involved are already unreproducible due to inconsistent generation of BTF in both the kernel and modules. Additionally, my "plan" would also get rid of signing modules with the Secure Boot CA, so I'm not going to object to this. [...] > ## Image packages contains more version info > > By renaming the kernel packages we try to make several kernels > installable at the same time. In contrast to rpm, where you can have > the same package installed multiple times in different versions, dpkg > only supports a single one at the same time. So the co-installable > versions needs to have different package names. > > The packages will include the full upstream version. There exists the > exception of devel builds and uploads to experimental, wich will contain > even less of the version, to avoid new names in that cases. > > Example: linux-image-6.5.3-cloud-arm64 > > There are some drawbacks. > > The same upstream version in testing and backports will have the same > package name. This is not OK, because they will be incompatible on architectures supporting SB (and sometimes incompatible on others due to compiler differences or required config changes). If someone upgrades from stable + backports to testing, and has OOT modules: - With DKMS, will a rebuild be triggered if the linux-image package name doesn't change? - With module-assistant, the new linux-image package will satisfy dependencies of the old modules even though they are incompatible. > Multiple uploads of the same upstream version will have > the same package name, but those rarely happens. Those happen fairly often for urgent security updates. > Those packages will > not be compatible and a reboot is necessary to be able to load modules > again. > > It will not longer be possible to reliably derive the package name from > kernel release (see above), as both values are not really related > anymore. Given all the drawbacks, I don't see the benefit of decoupling package names from release strings. In the same way that shared library packages must be renamed for every backward-incompatible ABI changes, I believe we should keep doing this for linux-image packages. > ## Header and tool packages will not longer contain version > > The headers packages will not longer include the version. It won't be > reliably possible to derive the package name anyway from the running > kernel. > > This means that only headers of one single version can be available on > the system at one time. This might be a bit inconvinient for dkms, as > it can't longer build modules for multiple versions. > > But we too often have the problem that image and headers go out of sync > and then you can't find the correct ones anyway. > > Example: linux-headers-cloud-arm64 This is all downside with no justification given. Please explain what the benefit is. > ## Installer packages will not longer contain too much version > > The installer can only ever handle one version of kernel. Also it got > an internal mechanism to detect which packages belong together > (the Kernel-Version control entry). So we have no need to rename them > and force a matching change in d-i itself just because a new kernel > exists. So it will not longer contain the full version in the package > names if not needed. [...] In the installer, netboot images break every time the kernel ABI is bumped. I think there's a specific check and error message for this, but I'm not exactly sure. It should be verified that this detection will work the way you expect, so that the error message doesn't change and create a support burden for the installer team. Currently kernel-wedge generates the udeb package names and would need to add an option to leave out the version part of the names. I'm happy to work on that once we have an agreement for what to do. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Bug#1050256: [pkg-apparmor] Bug#1050256: autopkgtest fails on debci
On Tue, 2023-09-19 at 07:17 +0200, Salvatore Bonaccorso wrote: > On Sun, Sep 17, 2023 at 12:01:37PM +0530, intrigeri wrote: > > In the last month or so, a number of people from various Debian teams > > and other distributions have been tracking down a regression that > > affects systems upgraded to Bookworm: services that use certain > > systemd facilities such as PrivateNetwork=yes fail to start in LXC/LXD > > containers. Among other things, this breaks the autopkgtests of many > > packages, such as systemd, on ci.debian.net (#1050256). This was > > tracked down to a kernel regression, for which a fix landed in Linux > > 6.2: > > > > 1cf26c3d2c4c apparmor: fix apparmor mediating locking non-fs unix sockets > > > > Work is ongoing to backport the fix to linux-stable/linux-6.1.y. > > I'm Cc'ing John and Mathias who have been working on this. > > > > FYI, ideally this would be fixed in the upcoming Bookworm > > point-release (12.2, early October). > > Thanks for the details. Has this already been sent it to the stable > maintainers? I do not see it yet on the stable list. I believe that John has been working on the fix for the 6.1 branch, although I don't know what the status is. I don't have the necessary familiarity with apparmor internals to attempt to backport the fix myself, but I'll be very happy to test once it's available. Mathias signature.asc Description: This is a digitally signed message part
Bug#1040901: Upcoming changes to Debian Linux kernel packages
Hi folks Debian currently does Secure Boot signing using a shim chained to the Microsoft key. This use requires that we follow certain rules. And one of the recent changes to those rules state that our method of signing kernel modules also with the same key will not be allowed anymore. Some information are in #1040901. We could just do the minimal change, sign the modules a different way and let users walk into authenticated failures and other scary error messages. Or we could change the existing ABI setting on every upload, creating a new set of binary packages. But maybe we can enhance the user experience a bit, by reducing the chance of scarry errors, but with the chance of simple errors like "you need to reboot". So let's do some more changes and hopefully don't break the user experience too much. The planned changes are discussed in more detail. ## Kernel modules will be signed with an ephemeral key The modules will not longer be signed using the Secure Boot CA like the EFI kernel image itself. Instead a key will be created during the build and thrown away after. Yes, this will make the build unreproducible, but no better solution currently exists. There are some plans, but no-one is working on them. If a suitable replacement shows up, we can always switch to that solution. ## Kernel release value includes complete Debian version The kernel release is what "uname -r" shows, and how modules are organized in /lib/modules. This value will include the complete version of the binary package, so even binNMU will somehow work. This will make sure the value changes with every upload and modules will not be compatible already from that check. Example: 6.5.3-2+b2-cloud-arm64 ## Image packages contains more version info By renaming the kernel packages we try to make several kernels installable at the same time. In contrast to rpm, where you can have the same package installed multiple times in different versions, dpkg only supports a single one at the same time. So the co-installable versions needs to have different package names. The packages will include the full upstream version. There exists the exception of devel builds and uploads to experimental, wich will contain even less of the version, to avoid new names in that cases. Example: linux-image-6.5.3-cloud-arm64 There are some drawbacks. The same upstream version in testing and backports will have the same package name. Multiple uploads of the same upstream version will have the same package name, but those rarely happens. Those packages will not be compatible and a reboot is necessary to be able to load modules again. It will not longer be possible to reliably derive the package name from kernel release (see above), as both values are not really related anymore. ## Header and tool packages will not longer contain version The headers packages will not longer include the version. It won't be reliably possible to derive the package name anyway from the running kernel. This means that only headers of one single version can be available on the system at one time. This might be a bit inconvinient for dkms, as it can't longer build modules for multiple versions. But we too often have the problem that image and headers go out of sync and then you can't find the correct ones anyway. Example: linux-headers-cloud-arm64 ## Installer packages will not longer contain too much version The installer can only ever handle one version of kernel. Also it got an internal mechanism to detect which packages belong together (the Kernel-Version control entry). So we have no need to rename them and force a matching change in d-i itself just because a new kernel exists. So it will not longer contain the full version in the package names if not needed. ## Further work The changes outlined here try to avoid changes to the initramfs protocol, aka /etc/kernel/. There are larger change is cooking somehow, see https://lists.debian.org/msgid-search/y2gbkyerb10ky...@shell.thinkmo.de Regards, Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0
Bug#1025845: linux: please enable CONFIG_KFENCE
On Sat, 10 Dec 2022 14:14:39 +0100 =?UTF-8?Q?Christian_G=C3=B6ttsche?= < cgzo...@googlemail.com> wrote: > Source: linux > Version: 6.0.12-1 > Tags: security > > Please enable support for Kernel Electric-Fence (KFENCE), a memory > safety error detector, see > https://docs.kernel.org/dev-tools/kfence.html. > > Whether to actually enable it by default (do not set > CONFIG_KFENCE_SAMPLE_INTERVAL) or disable it (set > CONFIG_KFENCE_SAMPLE_INTERVAL to 0) might be up for discussion (e.g. > enable in sid, disable before stable release?). > >
Processed: Re: fixed 1042503 6.5.0-1
Processing commands for cont...@bugs.debian.org: > fixed 1042503 6.5.3-1 Bug #1042503 [src:linux] linux-image-6.4.0-1-amd64: grafic performance regression with kernel 6.4 Marked as fixed in versions linux/6.5.3-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1042503: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042503 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: fixed 1042503 6.5.0-1
Processing commands for cont...@bugs.debian.org: > fixed 1042503 6.5.0-1 Bug #1042503 [src:linux] linux-image-6.4.0-1-amd64: grafic performance regression with kernel 6.4 The source 'linux' and version '6.5.0-1' do not appear to match any binary packages Marked as fixed in versions linux/6.5.0-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1042503: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042503 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
