Bug#1071430: dkms modules compile twice when installing new linux-image and linux-headers packages
Control: tags -1 wontfix On Sun, May 19, 2024 at 03:09:03PM +1000, Craig Sanders wrote: > When installing a new kernel (images & headers) packages, dkms modules for > that kernel version are compiled twice - once for the linux image package, and > again (almost immediately afterwards) for the linux headers package. I don't think we can do anything about this right now. But less so in the linux package. Tagging wontfix for now, as this requires some serious restructuring. The same problem also applies to initramfs building. Bastian -- Women are more easily and more deeply terrified ... generating more sheer horror than the male of the species. -- Spock, "Wolf in the Fold", stardate 3615.4
Bug#1071467: linux-image-6.6.13+bpo-amd64: installation botched, tiny and corrupt deb file
Control: tags -1 moreinfo Control: severity -1 normal On Sun, May 19, 2024 at 08:58:57PM +0200, Manny wrote: > To install linux-image-6.6.13+bpo-amd64, this command was executed: > > $ apt -t bookworm-backports install linux-image-amd64 > > I have a transcript of the session but it’s probably not worth > posting. It’s in the binary format produced by the “script” > command. The deb file is only 1,480 bytes, which is obviously a > non-starter. The final output was this: > > Download is performed unsandboxed as root as file > '/root/linux-image-amd64_6.6.13-1~bpo12+1_amd64.deb' couldn't be accessed by > user '_apt'. - pkgAcquire::Run (13: Permission denied) What do you want to say? This message is from apt and is pretty clearly a missconfiguration, why does it try to find a package from the Debian archive in your home? The size of this deb should be correct, this is a meta-package, aka it only depends on other packages. I don't see any problem description here. Bastian -- The joys of love made her human and the agonies of love destroyed her. -- Spock, "Requiem for Methuselah", stardate 5842.8
Bug#1071420: linux-image-6.8.9-1-amd64: cannot mount btrfs root partition
Control: tags -1 moreinfo Control: severity -1 important On Sat, May 18, 2024 at 10:25:14PM +0200, Matteo Settenvini wrote: > booting kernel 6.8.9-1 with dracut, systemd, and btrfs as the root device > fails > to mount the root partition. I just tried the kernel from sid and it seems > indeed \ > affected. The 6.7 kernel from trixie is instead booting fine even after > regenerating all initrds. Please provide proper error messages. Also dracut is not the default option, so please check with initramfs-tools as well. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20
Hi On Tue, Apr 23, 2024 at 09:20:08AM +0200, Bastian Blank wrote: > On Tue, Apr 23, 2024 at 09:06:47AM +0200, Bastian Blank wrote: > > On Tue, Apr 23, 2024 at 08:12:28AM +0200, bouv...@buxtehude.debian.org > > wrote: > > > FWIW, and following Jacob Rhoads' remark, we are also running CrowdStrike > > > Falcon Sensor on all our machines, virtuals servers and laptops alike. > > > That would explain why I don't have the same problem at home. > > Okay, so closing this bug report. Please don't come back with machines > > in this state. > While you are at it, please extract the kernel module from Crowdstrike > and ask them for the obviously GPL marked module. Can I please get a response? Bastian -- Sometimes a feeling is all we humans have to go on. -- Kirk, "A Taste of Armageddon", stardate 3193.9
Bug#1071381: linux-image-6.1.0-15-amd64: (regression) spontaneous freezing on Thinkpad
Control: tags -1 moreinfo
On Sat, May 18, 2024 at 10:49:34AM +0200, Manny wrote:
> ** Tainted: OE (12288)
> * externally-built ("out-of-tree") module was loaded
> * unsigned module was loaded
>
> ** Loaded modules:
> tp_smapi(OE)
> thinkpad_ec(OE)
You run with modules that modify low level system characteristics. Do
the freezes also happen without?
Bastian
--
Is truth not truth for all?
-- Natira, "For the World is Hollow and I have Touched
the Sky", stardate 5476.4.
Re: ocfs2_dlmfs missing from the cloud kernel
On Fri, May 17, 2024 at 12:44:32PM +0200, Bastian Blank wrote: > On Fri, May 17, 2024 at 12:31:51PM +0200, Thomas Goirand wrote: > > how do I change this? > You install the non-cloud kernel. The cloud kernel is limited in scope. And the decision was that not everything you can do on platforms is in scope. So you can open a bug report, but for now I would say it is not in this scope. Cloud platforms tend to provide such things and you don't define them on your own. Bastian -- It would seem that evil retreats when forcibly confronted. -- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5
Re: ocfs2_dlmfs missing from the cloud kernel
On Fri, May 17, 2024 at 12:31:51PM +0200, Thomas Goirand wrote: > how do I change this? You install the non-cloud kernel. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Re: Try to bootstrap regular short team-meeting for discussion of open issues, merge requests, tasks
On Thu, May 16, 2024 at 08:56:09AM +0200, Salvatore Bonaccorso wrote: > With regular, but shorts meetings this could help to stay on track for > those. We could try it as experiment for 2 or 3 times, and then > evaluate if it is helpful. > Thoughs? Better communication is needed, yes. So this sounds like a good idea. We can try if this will help and if we can manage that. Bastian -- But Captain -- the engines can't take this much longer!
Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20
On Tue, Apr 23, 2024 at 09:06:47AM +0200, Bastian Blank wrote: > On Tue, Apr 23, 2024 at 08:12:28AM +0200, bouv...@buxtehude.debian.org wrote: > > FWIW, and following Jacob Rhoads' remark, we are also running CrowdStrike > > Falcon Sensor on all our machines, virtuals servers and laptops alike. > > That would explain why I don't have the same problem at home. > Okay, so closing this bug report. Please don't come back with machines > in this state. While you are at it, please extract the kernel module from Crowdstrike and ask them for the obviously GPL marked module. Bastian -- Only a fool fights in a burning house. -- Kank the Klingon, "Day of the Dove", stardate unknown
Bug#1069642: linux-image-6.1.0-20-amd64: kernel panic after 2024-04-20
Control: reassign -1 src:linux Control: severity -1 normal Control: tags -1 moreinfo On Mon, Apr 22, 2024 at 09:12:59AM +0200, bouv...@buxtehude.debian.org wrote: > Something seems wrong in 6.1.0-20, but it is not immediately wrong: it waits > until some sort of trigger. After that, rebooting over and over is of no use. > I > cannot make any sense of it. Can you? I see: "Tainted: E", this means you are running unsigned kernel modules. However I don't see any sign of it in the list of kernel modules. Also the "O" taint, meaning out-of-tree build, did _not_ trigger. So, whatever this module is, it is pretty broken on it's own. Please identify the process messing with the kernel, remove it and come back. You can find it by searching for "unsigned" in the kernel log. To disallow such modules, enable secure boot or add "lockdown=integrity" to the kernel command line. Bastian -- Women are more easily and more deeply terrified ... generating more sheer horror than the male of the species. -- Spock, "Wolf in the Fold", stardate 3615.4
Re: Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
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
Bug#1064976: Having headers depend on image - bad idea I think
Hi On Tue, Apr 02, 2024 at 03:26:32PM +, Colm Buckley wrote: > 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. No, there is no "correct" solution. Anything correct would need not only moving the dependencies, but also the maintainer scripts, into one package. This is not going to be done without major restructuring. So as long as there is no concept and support for that it will remain a somewhat working solution. Regards, Bastian -- Change is the essential process of all existence. -- Spock, "Let That Be Your Last Battlefield", stardate 5730.2
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote: > Let's look at this the other way around: if there was no dependency, in > what scenario would things break and how? - linux-headers-bla and linux-image-bla are installed - linux-image-bla is uipgraded - no modules will be built, because the matching headers are missing Bastian -- If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, Apr 01, 2024 at 09:25:40PM +, Luca Boccassi wrote: > Why do dkms modules need the image installed to be built? At the very > least they didn't use to, the headers were enough last time I had to > deal with that stuff for the nvidia drivers dkms is used to build modules for the kernel that is just being installed. To do that it needs also the headers in matching versions. As the image can't depend on the headers, some other way was needed. Bastian -- Spock: We suffered 23 casualties in that attack, Captain.
Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package)
On Mon, Apr 01, 2024 at 08:39:06PM +, Debian Bug Tracking System wrote: > No. We need to make sure someone installing linux-image-bla and > linux-headers-bla have the same version, so the modules are compatible. Revisiting this bug, I might have been not explicit enough. This dependency is needed, so headers and kernel will be available in the same version and dkms is able to build modules for the just installed kernel. dkms will check that and break installation if this precondition is not provided. And no better solution is known to make sure we can build those modules. It however have nothing to do with vmlinux.h, which is not for kernel modules. Bastian -- We have phasers, I vote we blast 'em! -- Bailey, "The Corbomite Maneuver", stardate 1514.2
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Control: tags -1 wontfix On Thu, Feb 29, 2024 at 01:38:12PM +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. As said, this dependency is to make sure kernel modules are properly built. vmlinux.h is not for kernel modules. Bastian -- Mind your own business, Spock. I'm sick of your halfbreed interference.
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Control: reassign -1 tech-ctte Control: severity -1 normal Hi I don't see any way to solve this issue right now. Please decide this matter according to 6.1 nr 2 Debian Constitution. Background: linux-libc-dev provides the Linux API for consumption by all userspace stuff. This package was arch-any for as long as I remember and provided only the headers for this single architecture. Since a short while this package is now arch-all and provides headers for all known Debian architectures in one swoop. This change was done when the Ubuntu maintainers asked if we wanted to follow. This now means that new architectures will need to get added to linux-libc-dev first and it is not longer required to push hand crafted packages somewhere in the ports archive. However the package now contains everything that is also contained in the uncoordinated linux-libc-dev-*-cross packages. The only difference is the physical location of the files (/usr/include instead of the policy violating /usr/*/include). This API proofed to be compatible with all tested packages available in the archive. Because of this (from my side unnecessary) code duplication, I opened the plan to replace linux-libc-dev-*-cross, see #1059786. Two months later the following bug report comes in: On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't > do that completely > > Provides: linux-libc-dev-amd64-cross (= 6.7.7-1), ... > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > Please stop providing the cross-packages, you don't even need a breaks, > because the current cross packages continue to work. > > Once that is done, I'll reduce the cross packages to some symlinks. Even after several e-mails, the OP was unable or unwilling to show where the problem actually lies. Please decide who is going to provide linux-libc-dev and all the associated cross stuff and how it should look like. Regards, Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Wed, Mar 20, 2024 at 09:59:31PM +0100, Matthias Klose wrote: > Independent of any technical issues, this is a hijacking of a package name. > Please revert that change. Okay. Please prepare to take over linux-libc-dev alltogether then, there can be only one copy. Bastian -- Insufficient facts always invite danger. -- Spock, "Space Seed", stardate 3141.9
Bug#1059786: cross-toolchain-base: Migrating linux-libc-dev
Control: unmerge 1059786 Control: reassign 1059786 cross-toolchain-base Hi I'm going forward with the provided plan and will add Breaks with Linux 6.8. Regards, Bastian -- Insults are effective only where emotion is present. -- Spock, "Who Mourns for Adonais?" stardate 3468.1
Bug#1065819: linux-source-6.6 cannot be rebuild according to debian documentation
Control: severity -1 important On Sun, Mar 10, 2024 at 11:47:17AM +0100, Eric Valette wrote: > And then it correctly builds the kernel and modules .ko file, then sign the > ko and xz compress it to get foo.ko.xz. Here are extracts > > But then it tries to sign again the modules using the .ko file that does not > exist: > > ls -l debian/linux-image/lib/modules/6.6.15/kernel/arch/x86/events/*.ko* > -rw-rw-r-- 1 valette valette 103484 9 mars 19:39 > debian/linux-image/lib/modules/6.6.15/kernel/arch/x86/events/rapl.ko.xz > > And fails with: > > SIGN debian/linux-image/lib/modules/6.6.15/kernel/arch/x86/events/rapl.ko > At main.c:298: > - SSL error:8002:system library::No such file or directory: > ../crypto/bio/bss_file.c:67 > - SSL error:1080:BIO routines::no such file: ../crypto/bio/bss_file.c:75 > sign-file: > debian/linux-image/lib/modules/6.6.15/kernel/arch/x86/events/rapl.ko > make[6]: *** [scripts/Makefile.modinst:137 : > debian/linux-image/lib/modules/6.6.15/kernel/arch/x86/events/rapl.ko] Erreur 1 > make[5]: *** [Makefile:1846 : modules_install] Erreur 2 > make[4]: *** [Makefile:2061 : run-command] Erreur 2 > make[3]: *** [debian/rules:17 : binary-arch] Erreur 2 > dpkg-buildpackage: erreur: le sous-processus make -f debian/rules binary a > retourné lâ\x80\x99état de sortie 2 > make[2]: *** [scripts/Makefile.package:146 : bindeb-pkg] Erreur 2 > make[1]: *** [/usr/src/linux-source-6.6/Makefile:1563 : bindeb-pkg] Erreur 2 > make: *** [Makefile:246 : __sub-make] Erreur 2 Yes, the kernel included Debian package support can't handle compressed modules in various ways. Just disable them for now. Bastian -- It is necessary to have purpose. -- Alice #1, "I, Mudd", stardate 4513.3
Bug#1065585: linux-headers-6.7.7-amd64: Depends: linux-compiler-gcc-13-x86 -> linux-image-6.7.7-amd64, gcc-13 => uninstallable on x32
Control: severity -1 minor > Because this is an x32 host. x32 is multi-arch kernel only architecture. Debian still don't have proper support for multi-arch for compilers. Just use amd64. Bastian -- Bones: "The man's DEAD, Jim!"
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Helmut On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote: > The problem arises in the reverse sense. If a file does not exist in > one, it is searched in the second and erroneously may be found. That may > make tests pass that should not pass and typically causes a link failure > later. But you want /usr/include to be found. Otherwise you would not be able to use most of the libraries for cross compiling. > . While I do not have a concrete example at hand, I have seen this > pattern repeatedly and generally favour moving stuff out of /usr/include > to avoid this kind of confusion that causes difficult to debug problems. > This also motivates #798955 (in addition to the problem with file > conflicts). In this case here, this would just find kernel headers for a different version. Those are essentially a headers only library, nothing is available for linking. And all the headers provided in /usr/include are the same for all architectures. So moving stuff out of /usr/include might be a good idea if the -dev package is itself arch dependent. > The one case I really do remember quite well is sanitizers. These should > not be enabled in the earlier toolchain stages and failing to disable > them tends to cause linker failures. I don't think it matches the > concrete situation exactly though. You also make a good case in your > followup reporting that gcc-13-cross actually builds. Yep. My problem is: I tested stuff, not everything of course, and did not see any breakage. Also I checked the values I know could influence that and they say it is fine. So at some point I have to assume it is not broken, as exhaustive search is simply not possible. The only statement in this bug report is now: it is located in a different location, so it is broken. No single piece of evidence is shown, like broken builds or some other ways to see the brokeness. Regards, Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Mon, Mar 04, 2024 at 11:04:23PM +0100, Bastian Blank wrote: > At least to show where it breaks. And I actually tried it and can not show the expected breakage from missing /usr/include in the search path. gcc-13-cross builds fine with only linux-libc-dev/6.7.7-1. | -rw-r--r-- 1 bastian bastian 38157 Mar 5 06:40 ../gcc-13-cross_14_amd64.changes Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Mon, Mar 04, 2024 at 01:49:24PM +0100, Helmut Grohne wrote: > The packaged gcc cross toolchain uses a sysroot during its own build > still. As it is implemented now, it searches /usr//include, but > not /usr/include/. So quite fundamentally, the Provides that > we two agreed do break the build of cross toolchains right now. Okay, so this problem is about the build of the toolchain, _not_ for everything that comes after. > Arguably, a cross toolchain build should probably search > /usr/include/. I went back and forth a bit with Matthias > about whether we could add this and did not fully understand his > reasons, but there is one technical reason we want to avoid it for now. > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > and these packages can have differing versions. When that happens and we > search both /usr//include and /usr/include/, we'd > mix two glibc versions with usually bad results (been there). But this is a search path. If a file exists in one, the second one is not found. So nothing can happen even from version skew. > The other aspect here is that it is not sufficient to add > /usr/include/ to the search path as you also need > /usr/include to get a complete linux kernel headers experience. We > definitely do not want to add /usr/include, because that is known to > misguide configure tests performed for the target architecture. We are talking about the toolchain itself. What configure tests could that be? Or is that premature optimization of the gcc build? > So at least for now, I am convinced that we will need > /usr//include to be provided by the package providing > linux-libc-dev-arch-cross. You just said that the search path used during the build of the toolchain and the one for everything else are unrelated. So you are free to create $BUILD/tmp-include with symlinks for asm, asm-generic, linux. The toolchain as installed already finds all headers. So I still don't see why we need this in the final system. > That still leaves the question of which package would have to build that > new linux-libc-dev-cross. The two obvious answers are linux and > cross-toolchain-base. Do you have a preference here? No, the gcc build itself, because it is the only part that needs it from what you said here. > I hope this all makes more sense now. At least to show where it breaks. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Control: tags -1 moreinfo On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't > do that completely > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. So you claim that /usr/DEB_HOST_GNU_TYPE/include is critical part of the API for this package name? If you think so, please provide evidence. This path is in violation of the Debian policy, so can't be provided by linux-libc-dev. Bastian -- You canna change the laws of physics, Captain; I've got to have thirty minutes!
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, Mar 04, 2024 at 11:28:12AM +, Luca Boccassi wrote: > > But we where talking about kernel modules. > There are kernel modules using BPF stuff? Never seen one, do you have > an example? No idea, but they get linked BTF information, so you could use them. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote: > On 04.03.24 11:29, Bastian Blank wrote: > > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > > > Please be a bit more precise, there are no symlinks in this directory. > > | # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h > > | linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h > > | # find /usr/alpha-linux-gnu/include/ -type l > > | # > yes, that is the problem. the cross gcc expects these headers in > /usr/alpha-linux-gnu/include, not in the header location for the host. Please show your problem with a log, my crystal ball is broken. arm-linux-gnueabihf-cpp-13 tells me: | #include <...> search starts here: | /usr/lib/gcc-cross/arm-linux-gnueabihf/13/include | /usr/lib/gcc-cross/arm-linux-gnueabihf/13/../../../../arm-linux-gnueabihf/include | /usr/include/arm-linux-gnueabihf | /usr/include | End of search list. So clearly /usr/include/arm-linux-gnueabihf is used. Regards, Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3
Re: What to do with d-i on armel?
[ Remove -arm and -release } Hi On Sun, Mar 03, 2024 at 09:01:06PM +0100, Cyril Brulebois wrote: > Maybe have it marked Not-For-Us on armel, also requesting the binary to > be dropped there? And maybe poke the ftp team to have installer-armel/ > cleaned up? (The “disabling daily builds” part being trivial.) i would remove the d-i package itself (don't we already set the supported architectures?) Cleanup installer-armel. Remove armel specific udeb sources (I doubt we hve any). I would not try to remove udebs itself but just continue to build them. Bastian -- No one wants war. -- Kirk, "Errand of Mercy", stardate 3201.7
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote: > Yes precisely, the bpf program source can just include vmlinux.h and it > should build and run as expected. But we where talking about kernel modules. Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Control: reassign -1 cross-toolchain-base Control: forcemerge 1059786 -1 On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't > do that completely This is #1059786. This lacks a response from you. So I'm merging those. Bastian -- There are always alternatives. -- Spock, "The Galileo Seven", stardate 2822.3
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
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? Bastian -- Bones: "The man's DEAD, Jim!"
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, Feb 29, 2024 at 11:03:11AM +, 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? It complains loudly about BTF. > DKMS should handle its own dependencies, I'd have thought - I see a clear > use case for installing header files without the corresponding images. Sure, but installing the image does not break much. But not installing the headers breaks much. Maybe you can provide a proposal how that would work? Bastian -- Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, "Day of the Dove", stardate unknown
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
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#1064838: New package names break APT safety features, ability to co-install different ABIs
On Mon, Feb 26, 2024 at 02:20:41PM +0100, Julian Andres Klode wrote: > After we had discussed the new proposal a couple months ago and were > left with severe open questions and concerns it seems that these have > been ignored and the packages uploaded anyway, breaking APT's algorithm > that ensures the currently booted kernel is not offered for removal, as > well as possibly others. The change for that is not even in. Where do you see it? | $ dpkg -l linux-image-$(uname -r) | Desired=Unknown/Install/Remove/Purge/Hold | | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend | |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) | ||/ NameVersion Architecture Description | +++-===---=== | ii linux-image-6.7-cloud-amd64 6.7.4-1~exp1 amd64Linux 6.7 for x86-64 cloud (signed) Also #1060109 is still unanswered. > In addition, this means that the ABI changes within the same package > names, causing different ABIs to no longer be co-installable, which can > have drastic effect on thef function of systems: I asked you several times now: please show a problem. And I also told you this does not work within the confines of Debian. And neither did the kernel team provide this guarantee in the past. So I only see a way forward by preserving modules outside of the normal package lifecycle. Something that is ephemeral and so cleaned up automatically on shutdown. Bastian -- Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
Bug#1064838: New package names break APT safety features, ability to co-install different ABIs
Control: reassign -1 tech-ctte Control: severity -1 normal On Mon, Feb 26, 2024 at 02:20:41PM +0100, Julian Andres Klode wrote: > In addition, this means that the ABI changes within the same package > names, causing different ABIs to no longer be co-installable, which can > have drastic effect on thef function of systems: This is documented. Unstable and experimental don't need hand holding. > - modules will fail to load until you reboot Yes. That's why I wanted to rename the ABI of the kernel away from the package name. > - modules needed to reboot will fail to load until you reboot (if any) Please provide an example. Sorry. Bastian -- The man on tops walks a lonely street; the "chain" of command is often a noose.
Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory
Control: reassign -1 kmod On Mon, Feb 12, 2024 at 10:37:46PM +0100, Marco d'Itri wrote: > On Feb 12, Salvatore Bonaccorso wrote: > > --with-module-directory=/usr/lib/modules > I can revert it if it causes too much trouble, but maybe this is just > the right time to switch the kernel packages to /usr/lib/modules/ as well? We can't change this on our own. The usage of $BASE/lib/modules is baked in pretty deep into the kernel build. | MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE) and | depmod -b "$INSTALL_MOD_PATH" depmod need to learn to work with MODLIB to even be able to change this value. The main linux build does not break, because we skip depmod during build. But any other, including manual linux builds, will break. Bastian -- Only a fool fights in a burning house. -- Kank the Klingon, "Day of the Dove", stardate unknown
Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory
On Mon, Feb 12, 2024 at 10:26:07PM +0100, Salvatore Bonaccorso wrote: > On Mon, Feb 12, 2024 at 10:16:21PM +0100, Bastian Blank wrote: > > On Mon, Feb 12, 2024 at 10:09:41PM +0100, Salvatore Bonaccorso wrote: > > > kernel-wedge copy-modules 6.6.15 amd64 6.6.15-amd64 > > > depmod: ERROR: could not open directory > > > /<>/debian/linux-image-6.6.15-amd64/usr/lib/modules/6.6.15-amd64: > > > No such file or directory > > I would say depmod changed the API from /lib/modules to > > /usr/lib/modules. Re-assign? > A right, the last upload of kmod changed to use: > --with-module-directory=/usr/lib/modules The problem is, this now ties linux, kernel-wedge and kmod together. And with backports and the implicit nature of dh_movetousr, this is not a good idea right now. So we need to - make /usr usage explicit (in linux-signed-* it is still completely disabled, because of this implicit usage) - teach kernel-wedge to not assume Bastian -- A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, "The Menagerie", stardate 3012.4
Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory
On Mon, Feb 12, 2024 at 10:09:41PM +0100, Salvatore Bonaccorso wrote: > kernel-wedge copy-modules 6.6.15 amd64 6.6.15-amd64 > depmod: ERROR: could not open directory > /<>/debian/linux-image-6.6.15-amd64/usr/lib/modules/6.6.15-amd64: > No such file or directory I would say depmod changed the API from /lib/modules to /usr/lib/modules. Re-assign? Bastian -- Every living thing wants to survive. -- Spock, "The Ultimate Computer", stardate 4731.3
Re: Proposal: Switch to linear git history
Hi Ben On Mon, Jan 29, 2024 at 03:37:37PM +0100, Ben Hutchings wrote: > On Sun, 2024-01-28 at 21:37 +0100, Bastian Blank wrote: > > I have one small last minute modification: don't use main, but release. > > Overall I did not see any voices against the concept itself. Nor did I > > see any counter proposals to the layout. > I oppose this change and I propose to switch to DEP-14 branches > instead. Okay. Please provide a real description. DEP-14 does not specify workflow, only layout. And git does not like non fast-forward branches at all, so how do you intend to fix that? As this comes only after five weeks, please don't do that again. Bastian -- It would be illogical to kill without reason. -- Spock, "Journey to Babel", stardate 3842.4
Bug#1061712: initramfs-tools: initramfs hooks do not seem to work on kernels above linux 6.5 (e.g. 6.6 or 6.7)
Hi Safir On Sun, Jan 28, 2024 at 11:21:05PM +, Safir Secerovic wrote: > I have a custom hook that omits a kernel module being built into an initrd > image. So it is a bug in your hook itself? > Until kernels 6.6 and above, the hook does not seem to take effect. > The module is not omitted from initrd image... So it matches modules in filename alone. And since 6.6 the modules are compressed and named "module.ko.xz". Bastian -- It is a human characteristic to love little animals, especially if they're attractive in some way. -- McCoy, "The Trouble with Tribbles", stardate 4525.6
Re: Proposal: Switch to linear git history
Hi I have one small last minute modification: don't use main, but release. Overall I did not see any voices against the concept itself. Nor did I see any counter proposals to the layout. This means: - The current sid branch will end with 6.6 and be cleaned up later - No more merges will be done up the chain - I will branch to debian/release/6.7 after !1011 is in - I will annonce 6.7 upload to unstable pretty soon On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > master: uploaded to experimental -> debian/release/6.6: uploaded to unstable and stable releases >-> debian/backport/6.6.1-1: uploaded to backports >-> debian/security/6.6.1+1: extra security releases Bastian -- Even historians fail to learn from history -- they repeat the same mistakes. -- John Gill, "Patterns of Force", stardate 2534.7
Bug#1061445: linux-image-6.7-cloud-amd64: Built CONFIG_VIRTIO_BLK into kernel
Control: tags -1 wontfix On Wed, Jan 24, 2024 at 06:13:05PM +0100, Paul Menzel wrote: > Trying to quickly start a VM, it’d be great to not use an initrd image, and > also use the Virtio features, for example with the command below: Please use virtiofs in this case. > qemu-system-x86_64 -M q35 -m 32G -enable-kvm -cpu host -smp cpus=32 > -device virtio-rng-pci -net nic,model=virtio-net-pci -net > user,hostfwd=tcp::5-:22 -drive > if=virtio,file=/scratch/local2/debian-linux-build.img -vga none -nographic But you don't specify a kernel, so it boots fine using the initramfs within. So this already boots quite fine. I don't see what exactly you mean will be easier. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
linux_6.7.1-1~exp1_source.changes REJECTED
Broken upload === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
Re: What to do with d-i on armel?
On Fri, Jan 19, 2024 at 05:33:23PM +0100, Arnd Bergmann wrote: > Right, though changing the kernel package to support this > sounds easier than changing the installer to use a > foreign architecture kernel package. Well. It is a "dpkg --add-architecture" in the right spot of base-installer/debian/bootstrap-base.postinst. Bastian -- Yes, it is written. Good shall always destroy evil. -- Sirah the Yang, "The Omega Glory", stardate unknown
Re: Proposal: Switch to linear git history
On Wed, Jan 17, 2024 at 08:06:18PM +0100, Bastian Blank wrote: > On Wed, Jan 17, 2024 at 07:18:27PM +0100, Ben Hutchings wrote: > > > On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > > > > The repository for the Linux kernel in Debian currently makes heavy use > > > > of merges, which will always conflict due to changelog changes. This > > > > constitutes high cognitive busy load, for pretty small gains. > > > > I agree that this is a waste of time and resources for feature > > branches. We ought to avoid that by automating changelog updates for > > changes to the Debian packaging (gbp dch or somethign similar). > Feature branches are not affected here. Okay, I was not clear enough. But I was only talking about release branches right now. For feature branches we use merge requests, where GitLab can do what you tell it to. But merges there are fine. > > If we're going to change branch naming then we should be moving towards > > DEP-14, but this seems to diverge further. > I don't find any branches with version in DEP-14. So this is not even > applicable here. Well, DEP-14 defines debian/. Then suite is main/6.6 and so it fits perfectly. Bastian -- Superior ability breeds superior ambition. -- Spock, "Space Seed", stardate 3141.9
Re: Proposal: Switch to linear git history
On Wed, Jan 17, 2024 at 07:18:27PM +0100, Ben Hutchings wrote: > > On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > > > The repository for the Linux kernel in Debian currently makes heavy use > > > of merges, which will always conflict due to changelog changes. This > > > constitutes high cognitive busy load, for pretty small gains. > > I agree that this is a waste of time and resources for feature > branches. We ought to avoid that by automating changelog updates for > changes to the Debian packaging (gbp dch or somethign similar). Feature branches are not affected here. > But I've never found these conflicts to be a big problem when merging > between different branches. I always do. Which part needs to come from where? debian/changelog from both, debian/config from both, but don't try to get debian/patches from both sides. > > > Stop merging back changes, but create version distinct branches. > > > Something like that: > > > > > > master: uploaded to experimental > > > -> debian/main/6.6: uploaded to unstable and stable releases > > >-> debian/backport/6.6.1-1: uploaded to backports > > >-> debian/security/6.6.1+1: extra security releases > > > > > > ## Disadvantages > > > > > > - All changes need to go via master, which they should do anyway. > > > - In case of patch backports: > > > - A bug will be closed multiple times. > > > - The exact version a change reached unstable is not longer visible. > > > - No automatic way for patches required in the backports suites (I have > > > a larger config overhaul, where we could add something for that.) > > If we're going to change branch naming then we should be moving towards > DEP-14, but this seems to diverge further. I don't find any branches with version in DEP-14. So this is not even applicable here. > Do you see any advantages to this beyond avoiding conflicts? It removed useless work. Bastian -- The idea of male and female are universal constants. -- Kirk, "Metamorphosis", stardate 3219.8
Re: Proposal: Switch to linear git history
Hi On Sun, Jan 14, 2024 at 09:07:07PM +0100, Salvatore Bonaccorso wrote: > How would in the new scheme typical workflow look like? Maybe this > could help better understand the proposed changes. As you know in my > focus is mainly working on the stable branches, be it to rebase to > more recent stable upstream version, then targetting in either point > releases or security uploads, but as well picking single needing fixes > (for instance targetted security fixes). Adding patches to all: - Via merge request to master - Can be cherry picked to other release branches down the chain unstable, stable, security as necessary Adding patches only required for release: - Via merge request to debian/release/6.6 - Can be cherry picked further down the same way Adding new upstream releases for unstable, stable: - Import new upstream release into debian/release/6.6 Adding new upstream releases for security or even go back from current state of release branch (this is an emergency procedure): - Create debian/security/6.6.9 from the nearest tag - Import new upstream release Targeted fixes for security: - Create debian/security/6.6.9 from debian/6.6.9-1 tag - Choose new version (6.6.9+1-1) - Add patches. We can also try the GitLab feature for private merge requests then Uploads to backports: - Create debian/backport/6.6.9-1+deb13u1 from debian/6.6.9-1+deb13u1 tag - Choose new version (6.6.9-1+deb13u1~bpo12+1) - (For now: change things like compiler) - Release from there In the end creating branches on releases needs the operator to find a suitable ancestor, which might be a tag. These branches are then thrown away when they served their purpose. > It would help how the current work on e.g. the bookworm or > bookworm-security branches would work with the scheme. From importing > newer 6.1.y version (and rebasing rt patches) to cherry-pick single > fixes as needed. How then merge viceversa the security and stable > branches for instance. No merges between release branches are ever performed. Only merge requests can be merged into those and then cherry picked further down. You create a new branch from a suitable state. > (work on the branch for unstable is similar, though we have there no > disitinction about the target upload). Uploads to testing directly are pretty rare and reserved for security updates. So you would use the same procedure are stable security fixes: branch to debian/security/6.6.9 and go from there. I hope that makes it more clear. Regards, Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown
Re: Ability to further support 32bit architectures
On Sat, Jan 13, 2024 at 04:31:35PM +, Dimitri John Ledkov wrote: > On Fri, 12 Jan 2024, 22:36 Bastian Blank, wrote: > > On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote: > > > Disabling debug symbols, enabling debug symbol zstd compression, using > > > split debug symbols (disabled BTF usage) should help here. > > Disabling debug symbols does not help. > This now smells a lot more like an actual bug in either kernel source code, > or compiler, or both. Rather than natural growth and actually needing that > much memory. Probably worth escalating. What actually helps is -ftrack-macro-expansion=1. https://salsa.debian.org/kernel-team/linux/-/merge_requests/998 Bastian -- The joys of love made her human and the agonies of love destroyed her. -- Spock, "Requiem for Methuselah", stardate 5842.8
gcc displaying bullshit allocation numbers? (was: Re: Ability to further support 32bit architectures)
Hi On Thu, Jan 11, 2024 at 10:25:39AM +0100, Bastian Blank wrote: > Linux 6.7 fails to build on at least i386 and armhf. Even it now > manages to make the compiler fail to allocate memory: > | cc1: out of memory allocating 135266296 bytes after a total of 235675648 > bytes I just tried to find out what this numbers actually mean. The first on is the allocation amount, so correct. The printf spec is however wrong, as the variable is a size_t (%zu) and not unsigned long (%lu). The second one is the return value of "sbrk(0) - $saved sbrk value". https://github.com/gcc-mirror/gcc/blob/master/libiberty/xmalloc.c#L125-L132 The glibc malloc(3), which seems to be used in the background, uses both brk(2) and malloc(2), so you can't really see how much you have ever allocated using this technique. Am I right in this? Bastian -- "Life and death are seldom logical." "But attaining a desired goal always is." -- McCoy and Spock, "The Galileo Seven", stardate 2821.7
Re: Proposal: Switch to linear git history
Moin Sadly I did not get any response. Bastian On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > Hi folks > > The repository for the Linux kernel in Debian currently makes heavy use > of merges, which will always conflict due to changelog changes. This > constitutes high cognitive busy load, for pretty small gains. > > After already removing the manually modified abiname, we can drop more > manual work with that. As the now requires operarions will not longer > produce conflicts, we can easily create tools if we want. > > What did I miss? > > ## Current state > > The linux repo uses a kind of classic Debian like branch setup: > - master: for development work, uploaded to experimental > - sid: uploaded to sid > - bookworm > - bookworm-backports > - bookworm-security > > Between different branches a lot of merges happen. Between master and > sid in both directions, so changes can be done in both places and > changelogs show a linear history. Between sid and *-backports. > > Those merges are done by hand. In many cases conflict with each other > due to mainly changelog changes, which needs to cleaned up by hand. > > ## Proposal > > Stop merging back changes, but create version distinct branches. > Something like that: > > master: uploaded to experimental > -> debian/main/6.6: uploaded to unstable and stable releases >-> debian/backport/6.6.1-1: uploaded to backports >-> debian/security/6.6.1+1: extra security releases > > ## Disadvantages > > - All changes need to go via master, which they should do anyway. > - In case of patch backports: > - A bug will be closed multiple times. > - The exact version a change reached unstable is not longer visible. > - No automatic way for patches required in the backports suites (I have > a larger config overhaul, where we could add something for that.) > > -- > The heart is not a logical organ. > -- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4 > -- Men will always be men -- no matter where they are. -- Harry Mudd, "Mudd's Women", stardate 1329.8
Re: Ability to further support 32bit architectures
On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote: > Disabling debug symbols, enabling debug symbol zstd compression, using > split debug symbols (disabled BTF usage) should help here. Disabling debug symbols does not help. Bastian > Sent from Ubuntu Pro > https://ubuntu.com/pro Just curious why you send ads? -- Immortality consists largely of boredom. -- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
Re: Ability to further support 32bit architectures
On Thu, Jan 11, 2024 at 10:50:31AM +0100, John Paul Adrian Glaubitz wrote: > > As it is now, we will not be able to provide a kernel for maybe all > > 32bit architectures for Trixie. > I don't think that this would be a reasonable decision. We're preparing to > switch > 32-bit architectures over to time64_t. Disabling 32-bit kernel builds would > make > this whole work moot. This is completely unrelated. Userland != kernel. And people already talked about only supporting userland for those architectures. > FWIW, both m68k and powerpc are not affected by this bug, the powerpc build > fails > because of a packaging problem. Actually powerpc fails for exactly the same reason: | cc1: out of memory allocating 135266296 bytes after a total of 244908032 bytes | make[9]: *** [/<>/scripts/Makefile.build:248: drivers/media/pci/solo6x10/solo6x10-p2m.o] Error 1 https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.7-1%7Eexp1=1704796355=0 Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Re: Ability to further support 32bit architectures
Hi On Thu, Jan 11, 2024 at 09:48:34AM +, Dimitri John Ledkov wrote: > Disabling debug symbols, enabling debug symbol zstd compression, using > split debug symbols (disabled BTF usage) should help here. Okay, maybe more workarounds exist. But none of them look really promising. > Separately, I wish we had cross-builders available, and cross-build > i386/armhf kernels from amd64/arm64 and thus having access to 64-bit > compiler. Real cross-builders would use some fast amd64/arm64/ppc64el (and for amd64 also reasonably cheap) machines to build all other architectures. Bastian -- You're dead, Jim. -- McCoy, "Amok Time", stardate 3372.7
Ability to further support 32bit architectures
Hi Linux 6.7 fails to build on at least i386 and armhf. Even it now manages to make the compiler fail to allocate memory: | cc1: out of memory allocating 135266296 bytes after a total of 235675648 bytes Right now both fail on the same driver, so a short team workaround would be to disable it. But we need a long term fix, and quickly. As it is now, we will not be able to provide a kernel for maybe all 32bit architectures for Trixie. Bastian -- No one can guarantee the actions of another. -- Spock, "Day of the Dove", stardate unknown
Future for armel? (was: Re: What to do with d-i on armel?)
[dropped some recipients, this mail is not about d-i and the problem at hand] Hi On Wed, Jan 10, 2024 at 08:34:27AM +0100, Arnd Bergmann wrote: > The most important ARMv5 platform is now probably at91, as > Microchip still releases new sam9 chips[1] and is going to > keep supporting it for a while. If I interpret arch/arm/mach-at91/Kconfig correctly, then at91 is a family with v4, v5 and v7 devices. The v7 ones should work with armhf, so here we are only concerned about the v4 and v5 ones. For none of them does Debian provide a kernel. > Since armel userland should work fine with any armhf or > arm64 kernel, it might still be useful to repackage > one or both of those for the armel archive and use this > to have an installation method for armel on modern > hardware. But why? What is provided by an armel userland that armhf can't? > [Side note: I would also like to see an arm64 > kernel image added to armhf, it's probably more useful > than the armmp-lpae kernel in terms of enabling users.] Not gonna happen. "dpkg --add-architecture arm64" is the way to go. > At the moment, it is possible to enable support for > arm1176 (as in bcm2835) in a normal armhf kernel and > have that boot on armv6k, armv7 and armv8 hardware. Our armhf is armv7. Does armv6k fullfil the requirements as well? The armv8 hardware can just use our arm64 kernel. > I actually want to change that in the kernel though: > Now that we dropped SMP support in armv6, as it now > makes more sense to have armv6k grouped with armv5 > and instead have a generic kernel for armel that > works on bcm2835, versatilepb, at91, kirkwood and > all the others that one might use. Send patches? Bastian -- Virtue is a relative term. -- Spock, "Friday's Child", stardate 3499.1
Bug#1060280: linux-image-4.19.0-25-cloud-amd64: PCI ATS quirk patch needed for IDPF
Control: tags -1 moreinfo On Mon, Jan 08, 2024 at 05:48:46PM +, Andrew Jorgensen wrote: > The patch was released in Linux 6.7: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.7=a18615b1cfc04f00548c60eb9a77e0ce56e848fd > It's been backported to 5.15 in the LTS kernels, but customers may need > it in older kernels for Debian. It has been backported to 6.1, so Debian Bookworm will get it. Debian Bullseye will get a backport of the whole kernel. Further backports need at least f18b1137d38c091cc8c16365219f0a1d4a30b3d1. Please also do them via stable@ Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
What to do with d-i on armel?
Hi With Linux 6.6 we dropped the Marvell specific kernel image, as it was not known to work on any of the available devices. We still have another armel kernel left, the one of the Raspberry Pi 0 and 1, which uses an ARMv6 CPU. This also removed all the udebs from armel, which makes many d-i components not longer have fullfiled dependencies and the release stuff of course acting up. Do we have any armel subarch that can be installed via d-i? Bastian -- Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Re: Uploading linux (6.6.10-1)
On Sun, Jan 07, 2024 at 02:03:32PM +0100, Salvatore Bonaccorso wrote: > I would like to upload linux version 6.6.10-1 later today to unstable. I would like to have 6.6.9 in testing first, but we can also ignore that. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Bug#1059939: linux-image-6.1.0-17-rt-amd64: dkms will not build zfs module for rt-amd64
Control: reassign -1 dkms dkms fails the kernel installation. On Wed, Jan 03, 2024 at 10:54:12PM +0100, T. J. Pinkert wrote: > Error! The /var/lib/dkms/zfs/2.1.11/6.1.0-17-rt-amd64/x86_64/dkms.conf for > module zfs includes a BUILD_EXCLUSIVE directive which does not match this > kernel/arch/config. > This indicates that it should not be built. > Error! One or more modules failed to install during autoinstall. > Refer to previous errors for more information. > dkms: autoinstall for kernel: 6.1.0-17-rt-amd64 failed! > run-parts: /etc/kernel/postinst.d/dkms exited with return code 11 > dpkg: error processing package linux-image-6.1.0-17-rt-amd64 (--configure): > installed linux-image-6.1.0-17-rt-amd64 package post-installation script > subprocess returned error exit status 1 > dpkg: dependency problems prevent configuration of linux-image-rt-amd64: > linux-image-rt-amd64 depends on linux-image-6.1.0-17-rt-amd64 (= 6.1.69-1); > however: > Package linux-image-6.1.0-17-rt-amd64 is not configured yet.
Bug#1059765: linux: isolation-machine autopkgtest fails for multiple reasons
On Mon, Jan 01, 2024 at 10:33:10PM +0100, Bastian Blank wrote: > Turns out this requires more work. Currently it is not possible to > build some tests. I'll remove the current selftest stuff. This needs much more work, too much work for now. The runner does not support recursive test selection. Many tests fail instead of skipping itself on missing requirements. Bastian -- Immortality consists largely of boredom. -- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
Bug#1059765: linux: isolation-machine autopkgtest fails for multiple reasons
On Sun, Dec 31, 2023 at 06:33:29PM +0100, Bastian Blank wrote: > On Sun, Dec 31, 2023 at 04:47:28PM +0100, Paul Gevers wrote: > > Recently I added some isolation-machine support to ci.debian.net and one of > > the first packages I tried to run the test for is src:linux. > Do you have a handy script available to try this by hand? I was just > looking at this test (to unravel the loop logic and replace it with one > test per kernel), but I'm not sure if this ever worked before. Turns out this requires more work. Currently it is not possible to build some tests. Plan: - get vmlinux.h working - build a linux-selftests package - from there run tests Do we have serial of the machines? Otherwise running those tests is not adviced anyway, as we will have no way to see if something breaks. Bastian -- Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, "The City on the Edge of Forever", stardate unknown
Bug#1053825: marked as done (Screensaver with only blank does not work after suspend)
> This system is not supported. Closing the bug report. Please don't > open new ones until your system is in a supported state. You where already told the same in #1027697. Please don't come back. Regards, Bastian -- Spock: We suffered 23 casualties in that attack, Captain.
Bug#1053825: Screensaver with only blank does not work after suspend
Control: severity -1 normal Hi Klaus On Thu, Oct 12, 2023 at 06:57:20AM +0100, Klaus Ethgen wrote: > -- System Information: > Debian Release: trixie/sid > merged-usr: no I just realized that this system is in an unsupported state. Bookworm and later is not longer supported without merged-/usr, see https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#a-merged-usr-is-now-required Please reinstall from scratch and report back if it is still broken. Maybe please also describe how you got into this state, where /lib is not a symlink to /usr/lib. Bastian
Bug#1059765: linux: isolation-machine autopkgtest fails for multiple reasons
On Sun, Dec 31, 2023 at 04:47:28PM +0100, Paul Gevers wrote: > Recently I added some isolation-machine support to ci.debian.net and one of > the first packages I tried to run the test for is src:linux. Do you have a handy script available to try this by hand? I was just looking at this test (to unravel the loop logic and replace it with one test per kernel), but I'm not sure if this ever worked before. Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1
Bug#1059431: linux: FTBFS on mips64el: make[3]: *** [/<>/Makefile:246: __sub-make] Error 2
On Mon, Dec 25, 2023 at 11:38:17AM +0100, Sebastian Ramacher wrote: > (sorry, I wasn't able to find an error, so this is the end of the build > log.) The error is: | Relocations overflow available space! | Please adjust CONFIG_RELOCATION_TABLE_SIZE to at least 0x001d3000 | make[6]: *** [/<>/arch/mips/Makefile.postlink:28: vmlinux] Error 1 | make[6]: *** Deleting file 'vmlinux' | make[5]: *** [/<>/scripts/Makefile.vmlinux:37: vmlinux] Error 2 | make[4]: *** [/<>/Makefile:1176: vmlinux] Error 2 | make[4]: *** Waiting for unfinished jobs Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, "Friday's Child", stardate 3497.2
Re: consolidate linux-libc-dev headers
On Sun, Dec 24, 2023 at 04:10:52PM +0100, Bastian Blank wrote: > On Sat, Dec 23, 2023 at 05:15:18PM +0100, Helmut Grohne wrote: > > I guess that the list of architectures will always be incomplete for > > some, so we probably still need a process for building a modified > > linux-libc-dev package only. This probably requires some build profiles. > > Is pkg.linux.nokernel pkg.linux.notools pkg.linux.quick a sensible set > > of profiles for this? Is there an easily patchable way to add an > > architecture? > > Let's see. I have some changes pending that make config changes easier. > > Also we might be able to add a linux-libc-dev-arch that builds a > standalone version again and is only built with a special build profile, > but it still needs the package to know more information then dpkg does > provide. > > Or you inject a new reboostrap-specific package that just adds a > symlink /usr/lib/$DEB_HOST_MULTIARCH/asm pointing to the appropriate > /usr/lib/linux/uapi/$ARCH if linux-libc-dev does not include this. I think we can also just ship all Linux architectures. We currently do ship 13 (becoming 14) of the 21 currently supported ones. Then only the multiarch aliases are missing. Or, most likely bad idea, we teach the compiler or the libc to look into /usr/lib/linux/uapi. Bastian -- What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, "Metamorphosis", stardate 3219.8
Re: consolidate linux-libc-dev headers
Hi Helmut On Sat, Dec 23, 2023 at 05:15:18PM +0100, Helmut Grohne wrote: > I guess that the list of architectures will always be incomplete for > some, so we probably still need a process for building a modified > linux-libc-dev package only. This probably requires some build profiles. > Is pkg.linux.nokernel pkg.linux.notools pkg.linux.quick a sensible set > of profiles for this? Is there an easily patchable way to add an > architecture? Let's see. I have some changes pending that make config changes easier. Also we might be able to add a linux-libc-dev-arch that builds a standalone version again and is only built with a special build profile, but it still needs the package to know more information then dpkg does provide. Or you inject a new reboostrap-specific package that just adds a symlink /usr/lib/$DEB_HOST_MULTIARCH/asm pointing to the appropriate /usr/lib/linux/uapi/$ARCH if linux-libc-dev does not include this. > For c-t-b, I guess that we can simply cut out linux-libc-dev and remove > all the -cross packages. I hope there is no devil in the detail. I would start with adding Provides and later Breaks for them to linux-libc-dev. The compilers have proper search paths. (And they violate the policy, so the devils are with those already.) Bastian -- Deflector shields just came on, Captain.
Re: Immediate fallouts from the big linux changes, and actions
On Sun, Dec 24, 2023 at 08:38:57AM +0100, Cyril Brulebois wrote: > - kernel-image-* packages are now shipping /boot/vmlinuz-* (or > /boot/vmlinux-* depending on the arch), instead of just /boot/vmlinuz > (respectively /boot/vmlinux). This was even dependent on architecture. A lot of secondary architectures already had various suffixes. > - Modules are compressed now, so the drm workaround needed an updated to > cope with the extra .xz suffix: > > https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea This now hardcodes .xz. And I'm not really sure what this does and why this can't be fixed in the kernel packages. > - Finally, the armel build fails because it can't find its kernel. The > marvell flavour seems to have been dropped entirely (at least that's > how I read the linux changelog for 6.6.3-1~exp1: > > https://tracker.debian.org/news/1482751/accepted-linux-663-1exp1-source-into-experimental/ Yes, the kermel was broken and the checks for this disabled since quite some time. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4
Proposal: Switch to linear git history
Hi folks The repository for the Linux kernel in Debian currently makes heavy use of merges, which will always conflict due to changelog changes. This constitutes high cognitive busy load, for pretty small gains. After already removing the manually modified abiname, we can drop more manual work with that. As the now requires operarions will not longer produce conflicts, we can easily create tools if we want. What did I miss? ## Current state The linux repo uses a kind of classic Debian like branch setup: - master: for development work, uploaded to experimental - sid: uploaded to sid - bookworm - bookworm-backports - bookworm-security Between different branches a lot of merges happen. Between master and sid in both directions, so changes can be done in both places and changelogs show a linear history. Between sid and *-backports. Those merges are done by hand. In many cases conflict with each other due to mainly changelog changes, which needs to cleaned up by hand. ## Proposal Stop merging back changes, but create version distinct branches. Something like that: master: uploaded to experimental -> debian/main/6.6: uploaded to unstable and stable releases -> debian/backport/6.6.1-1: uploaded to backports -> debian/security/6.6.1+1: extra security releases ## Disadvantages - All changes need to go via master, which they should do anyway. - In case of patch backports: - A bug will be closed multiple times. - The exact version a change reached unstable is not longer visible. - No automatic way for patches required in the backports suites (I have a larger config overhaul, where we could add something for that.) -- The heart is not a logical organ. -- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
Re: How to revoke Debian kernels for secure boot
On Thu, Dec 14, 2023 at 09:31:11PM +0100, Bastian Blank wrote: > On Thu, Dec 14, 2023 at 03:09:51PM +, Steve McIntyre wrote: > > It's a difficult thing to do, especially in light of significant > > pushback from upstream developers. Okay, I finally managed to read most of that thread. And it boils down to procedural problems, leading to no viable patch. Like the submitter not wanting to take replies seriously or even sending the patch to the correct maintainer in the first place. To specify a SBAT policy for upstream Linux, where people told the submitter several times that Linux is not interested in a secure boot policy, but such a policy needs to be defined by the signers, aka us. So we are free to specify "linux.debian" and attach our own policy to it. Or "linux-debian", so we can use "linux-debian.*" for internal things. Or so. Just curious: how to MOK and SBAT interact? Regards, Bastian -- If I can have honesty, it's easier to overlook mistakes. -- Kirk, "Space Seed", stardate 3141.9
Re: How to revoke Debian kernels for secure boot
On Thu, Dec 14, 2023 at 03:09:51PM +, Steve McIntyre wrote: > On Wed, Dec 13, 2023 at 10:18:40PM +, Dimitri John Ledkov wrote: > >There is no sbat for kernels yet (and/or nobody has yet started to use sbat > >for > >kernels). > It's a difficult thing to do, especially in light of significant > pushback from upstream developers. Well, if I read that correctly, that way mainly about policy. We have to define our own policy then, and then we can decide our own. The only problem would be that we have to carry the patch. Bastian -- Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant." -- Kirk, "The Ultimate Computer", stardate 4731.3
How to revoke Debian kernels for secure boot
Hi I don't think we currently have a documented way to revoke old kernels for secure boot. Are there known plans by other distributions? Or should we just force the inclusion of SBAT and use it as intended? Regards, Bastian -- ... The prejudices people feel about each other disappear when they get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5
[arm64] secure boot breach via VFIO_NOIOMMU
Hi Over six years ago, support for VFIO without IOMMU was enabled for arm64. This is a breach of the integrity lockdown requirement of secure boot. VFIO is a framework for handle devices in userspace. To make this safe, an IOMMU is required by default. Without it, user space can write everywhere in memory. The code is still not conditional on lockdown, even if a patch was proposed. I intend to disable this option for all supported kernels. Regards, Bastian -- Spock: The odds of surviving another attack are 13562190123 to 1, Captain.
Re: No longer sign i386 kernels
On Wed, Dec 06, 2023 at 09:09:01PM +, Steve McIntyre wrote: > We should publicise this for users and be consistent for all the EFI > signed binaries - there's no point in signing i386 grub and fwupd or > having a signed shim if we don't have a signed kernel. > Agreed? Signing of i386 kernels is gone. https://salsa.debian.org/kernel-team/linux/-/merge_requests/944 Bastian -- Suffocating together ... would create heroic camaraderie. -- Khan Noonian Singh, "Space Seed", stardate 3142.8
No longer sign i386 kernels
Hi I would like do stop signing i386 kernels. - IA32 UEFI is basically non existent outside of the Apple world and maybe some embedded stuff. - i386 lacks many of the microarchitectural fixes that creeped in during the last years. So those kernels are unsuitable for real world usage of processors released in the last ten years. Install base of a IA32 EFI capable boot chain, as possible to see by popcon (via grub-efi-ia32-signed): 178 Install base of a X64 EFI capable boot chain (via grub-efi-amd64-signed): 71743 Bastian -- Military secrets are the most fleeting of all. -- Spock, "The Enterprise Incident", stardate 5027.4
Re: Bug#1057441: linux-image-6.6-amd64: Crypt does not longer work
On Tue, Dec 05, 2023 at 05:16:31PM +0100, Salvatore Bonaccorso wrote: > And in fact this is the solution proposed in #1036049. And we need to fix that in stable as well. Not sure if we can safely use Conflicts to make sure we have a suitable version. At least without the current apt prefering to remove cryptsetup instead and really make people's systems unbootable. Bastian -- Hailing frequencies open, Captain.
Re: consolidate linux-libc-dev headers
On Thu, Nov 16, 2023 at 10:27:26PM +0100, Bastian Blank wrote: > However it does not matter, > because the include list already is correct: > > | #include <...> search starts here: > | /usr/lib/gcc-cross/s390x-linux-gnu/13/include > | /usr/lib/gcc-cross/s390x-linux-gnu/13/../../../../s390x-linux-gnu/include > | /usr/include/s390x-linux-gnu > | /usr/include > | End of search list. I can confirm that this works: | % cat test.c | #include | % dpkg --print-architecture | arm64 | % s390x-linux-gnu-gcc -E test.c | grep errno.h | # 1 "/usr/lib/linux/uapi/s390/asm/errno.h" 1 3 4 | # 1 "/usr/include/asm-generic/errno.h" 1 3 4 | # 6 "/usr/include/asm-generic/errno.h" 2 3 4 | # 2 "/usr/lib/linux/uapi/s390/asm/errno.h" 2 3 4 Bastian -- Beam me up, Scotty! It ate my phaser!
Re: consolidate linux-libc-dev headers
On Thu, Nov 16, 2023 at 08:07:47PM +, Dimitri John Ledkov wrote: > On Thu, 16 Nov 2023 at 19:30, Bastian Blank wrote: > > On Thu, Nov 16, 2023 at 06:28:13PM +, Dimitri John Ledkov wrote: > > > I have implemented example packaging of that as a standalone source > > > package > > > https://ppa.launchpadcontent.net/xnox/nonvirt/ubuntu/pool/main/l/linux-uapi/ > > > > I actually just implemented something similar, but as part of the Debian > > linux packaging. It looks a bit different, sure. > Will check it out, thanks! And yes, indeed there are dozens of ways to > implement this idea. https://salsa.debian.org/kernel-team/linux/-/merge_requests/909 > It's ok if you don't want to integrate `linux-libc-dev-cross` into > src:linux I can upload that into debian as a standalone > src:linux-libc-dev-cross under the toolchain-base maintainers hat that > will build-depend on linux-source and build it for all possible > triplets under the sun. And i think we override the lintian warnings > there. Because it will be easier to have that once, rather than in all > three cross-toolchain-base packages. And it can be updated, without > rebuilding the cross-toolchains themselves. Because it is wasteful to > acutally do cross toolchains bootstraps just to bump a stable point > release of linux headers that like changes nothing. > > Or just integrate it into src:linux build too, given all of those > cross headers are established packages since 2015. (and yes using GNU > tripplet as a top level dir) I will add breaks to all those packages, so the cross packages must adopt a standard schema for the headers. However it does not matter, because the include list already is correct: | #include <...> search starts here: | /usr/lib/gcc-cross/s390x-linux-gnu/13/include | /usr/lib/gcc-cross/s390x-linux-gnu/13/../../../../s390x-linux-gnu/include | /usr/include/s390x-linux-gnu | /usr/include | End of search list. Bastian -- A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, "The Menagerie", stardate 3012.4
Re: consolidate linux-libc-dev headers
Hi Dimitri On Thu, Nov 16, 2023 at 06:28:13PM +, Dimitri John Ledkov wrote: > I have implemented example packaging of that as a standalone source package > https://ppa.launchpadcontent.net/xnox/nonvirt/ubuntu/pool/main/l/linux-uapi/ I actually just implemented something similar, but as part of the Debian linux packaging. It looks a bit different, sure. > Is this something that the debian kernel team could consider supporting / > building as either standalone source package, or out of src:linux directly? My first thought was actually to make bootstrapping of new architectures easier. > The obvious things missing from the packaging is to create all the > breaks/replaces/provides, and update cross-toolchain-base packages to > match. Also probably using symlinks rather than hard links, with > linux-libc-dev-cross likely depending on the native one. What do you want to do with linux-libc-dev-cross? /usr/$triplet is no allowed location in Debian anyway. > Separately for Ubuntu, due to the number of kernel built, I would likely > want to upload source package that produces linux-libc-dev as a separate > source package such that linux-libc-dev is actually only updated when > needed, rather than on every kernel upload. As there is no need to rev > linux-libc-dev as often as kernel uploads are done. The question here is: does it provide an advantage to have it as separate source? Less updates IMHO do not count, as they don't come with a penalty attached. But I see the downside of fixing the user space API to a different version then the kernel you actually ship in the end. Regards, Bastian -- Knowledge, sir, should be free to all! -- Harry Mudd, "I, Mudd", stardate 4513.3
Bug#1040901: Upcoming changes to Debian Linux kernel packages
On Fri, Oct 27, 2023 at 01:04:00PM +0300, Adrian Bunk wrote: > > Sadly in Debian there is no way to make that happen. Think for example > > about bin-nmu. > Could you give a complete list of problems? There are at least those problems: - Bin-nmu can't change binary package names. - There is no way to embed a Debian version into a Debian package name without loss. (Okay, I think we would only need ~, all the othe characters are allowed) Bastian -- Change is the essential process of all existence. -- Spock, "Let That Be Your Last Battlefield", stardate 5730.2
Bug#1040901: Upcoming changes to Debian Linux kernel packages
On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote: > > > ## Image packages contains more version info > > > > > > Example: linux-image-6.5.3-cloud-arm64 > > > > > 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. > > This package name seems to be missing the Debian release, which is > mandatory to ensure that you can install 6.5.3-2 and 6.5.3-1 in > parallel, which again is mandatory. That's not something we can > compromise on; it's absolutely vital that Sadly in Debian there is no way to make that happen. Think for example about bin-nmu. In the end we can approximate it in testing (usually not multiple releases are migrated, but bin-nmu might show up), stable (where usualy new upstream releases go in) and security (by uploading as 6.6.1, 6.6.1+1, 6.6.1+2, yes this is a hack, but it reduces the complexity of the whole system). Right now I simply don't see a way to not have multiple releases within the same package, which override each other. > - you can revert to the kernel you last booted succesfully, i.e. 6.5.3-1 > if 6.5.3-2 is broken (think toolchain broke or something on buildds) You can revert to 6.5.2, which is a separate package. Or 6.4. > - the currently booted kernel is not impacted. This means it must be > able to load additional modules. Some platforms even require > additional modules to be loaded to reboot, I've seen this on > laptops. Could you provide an example? Then we have to find another way to make sure modules survive unrelated to what dpkg does. Even right now there is no guarante you can load modules from a different version at all. > Needless to say I do not believe that uname -s is necessarily a > single word. Please provide an example. [ Snipped the rest for now, will come back later ] Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, "Dagger of the Mind", stardate 2715.1
Re: Upcoming changes to Debian Linux kernel packages
On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote: > I think that's what you mean by the first-level error. > If not, I'm still confused. > In the second level error case you are talking about is: No, the first level is always: but the new kernel does not work. The second is: I need to upgrade external modules. > I think what you are saying is that > > 1) the current system is fragile: sometimes you want a kernel headers > that is not available and sometimes you have version skew between the > kernel headers and kernel even though you have both installed. > > 2) In your system, fewer things are possible, but the combination that > is possible is more likely to work. Yes. > And I think people's response is that > they care enough about some of the things you are breaking that they are > willing to accept the fragility. For now it looks like a better solution is to just create more meta packages and accept that they become uninstallable from time to time. In the future we might want to split off the modules into it's own package anyway. That will then allow - a different image package containing prebuilt UKI, - a different modules package to replace the special cloud flavours. Regards, Bastian -- Without facts, the decision cannot be made logically. You must rely on your human intuition. -- Spock, "Assignment: Earth", stardate unknown
Bug#1040901: Upcoming changes to Debian Linux kernel packages
On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote: > Or would it be easier to re-use normal dependency resolving, like: > Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.) > This would allow full flexibility and re-uses existing code to check > such definitions. Okay, noone complained, so it looks like this should work. Regards, Bastian -- Too much of anything, even love, isn't necessarily a good thing. -- Kirk, "The Trouble with Tribbles", stardate 4525.6
Bug#1040901: Upcoming changes to Debian Linux kernel packages
[ Removing some lists ] On Sat, Oct 07, 2023 at 04:53:33PM +0200, Bastian Blank wrote: > > ## Image packages contains more version info > > > > Example: linux-image-6.5.3-cloud-arm64 > > > 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. > What should work: We define a new control field. It contains both the > kernel name and a version prefix. Or would it be easier to re-use normal dependency resolving, like: Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.) This would allow full flexibility and re-uses existing code to check such definitions. Regards, Bastian -- Women professionals do tend to over-compensate. -- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before", stardate 1312.9.
Bug#1040901: Upcoming changes to Debian Linux kernel packages
Moin On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote: > ## Kernel modules will be signed with an ephemeral key This is now https://salsa.debian.org/kernel-team/linux/-/merge_requests/607. > ## Image packages contains more version info > > Example: linux-image-6.5.3-cloud-arm64 > 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. I missed that apt does something similar (maintainers cced). It wants to see if a particular package matches the current kernel to make the autoremove prevention work. That lookup is quite a hard problem. What should work: We define a new control field. It contains both the kernel name and a version prefix. Example: - Linux 6.6 (would match 6.6-1, 6.6.1-1) - Linux 6.6.3 (would match 6.6.3-1, but not 6.6.3+2-1) - Linux 6.6.3+2 The algorithm would be something like this: - Check $(uname -s) against the first word. Otherwise completely ignore. - Check if $(uname -r) matches the version prefix in this field. Mark as keep if it matches. - Aggregate packages by version prefix. - Sort as version, keep newest two(?). This means: - Images and headers are always kept with the same versions. - Different images (-arm64, -rt-arm64) are always kept together. Counter proposal: Use see the kernel release as debian version and match on the upstream version. But then we need to re-define what we put into the kernel release field. In 6.6.1-1-cloud-arm64, the upstream version is 6.6.1-1-cloud, not 6.6.1 as we would need. We could of course change that to: 6.6.1-1~cloud+arm64. That should always sort correctly in regard of the package version. > ## Header and tool packages will not longer contain version This is obsolete with the counter proposal of a meta package that always pulls in image and headers of the same version. Regards, Bastian -- Without followers, evil cannot spread. -- Spock, "And The Children Shall Lead", stardate 5029.5
Bug#1040901: Upcoming changes to Debian Linux kernel packages
Hi On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote: > > 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. We could encode that in the upstream version. Aka to have co-installable packages for security updates we do: - 6.6.1-1 - 6.6.1+1-1 - 6.6.1+2-1 This allows for easy semantic, aka we only care for package names about the upstream part of the version, which then needs to follow a certain syntax. Regards, Bastian -- A Vulcan can no sooner be disloyal than he can exist without breathing. -- Kirk, "The Menagerie", stardate 3012.4
Re: Upcoming changes to Debian Linux kernel packages
On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote: > On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote: > > How will the user get the headers matching this previously-used kernel > > that are required until we provide a kernel with the regression fixed? The same as now: nowhere, because those packages have been removed from the archive already. And sadly you did not answer the question why a second degree error must not be worse then a worked around first degree error? > I know there is a lot of history behind the linux-headers package in > debian. However since 5.2 there is a kernel config option, which > allows you to build the kernel headers as a module (built-in or > external).. > https://cateee.net/lkddb/web-lkddb/IKHEADERS.html > As long as this was enabled (ignore bugs/regressions), users can go > back and forth on kernel versions as they wish. If it would be so easy. This would include all the generated things of the build. But it still needs all the static headers, all the support binaries and scripts (shipped as linux-kbuild-*), which also change with every version. Regards, Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Re: Upcoming changes to Debian Linux kernel packages
Hi Andreas On Tue, Oct 03, 2023 at 11:58:29PM +0200, Andreas Beckmann wrote: > That should solve the problem where several source packages need to be > updated together. The problem does not come from multiple source packages that need to be updated together. Instead it comes from the way Debian does signing of secure boot components. After the linux packages got built and accepted, an automatic process takes the output and produces a new source package that is uploaded, built and accepted. So the signed stuff will always come later (between hours or days in normal cases, but esp for backports even more then a week later). Regards, Bastian -- Insults are effective only where emotion is present. -- Spock, "Who Mourns for Adonais?" stardate 3468.1
Re: Upcoming changes to Debian Linux kernel packages
Hi Sam On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote: > I still think it would help if you would work more on articulating what > problem you are trying to solve with the linux-headers versioning > change. I have read multiple versions of this proposal, and your > follow-ups, and I still do not understand what is prompting the > linux-headers change. The core problem is that people assume they can get headers matching the currently running kernel, without upgrading first, see also the parallel thread. Or freak out because meta packages remain uninstallable in backports for days. With this plan you can only get the correct ones by using something I think like: | apt satisfy 'linux-headers (= $(uname -r))' There is somewhere again a maybe possible plan to get meta packages in place that actually support the case of always providing the headers to the installed (not running!) kernel. Then we need to use the same versioning anyway again. In the end I don't really care, but we need then a way to fix the version skew between the different source package for the kernel. Aka either redo larger parts of the linux package (which can never fix it completely), plus gcc or we change how backports works. > My intuition mirrors others in the conversation that it is problematic > to support multiple kernel versions without also supporting multiple > header versions. Usually you try to guard against one error. Noone claimed that we can't work with one error. All the other conversations already have to argue with two errors at the same time. When should we stop then? Regards, Bastian -- Deflector shields just came on, Captain.
Re: Upcoming changes to Debian Linux kernel packages
On Mon, Sep 25, 2023 at 04:35:08AM +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. > 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). Ah, here lays the missconception. No, the 6.6 ones are not removed. Why should they be? The system knows it can't rebuild them. If the current implementation would remove them, it is a problem there, not in the concept. Bastian -- Superior ability breeds superior ambition. -- Spock, "Space Seed", stardate 3141.9
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 mechan
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
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#1052006: linux-image-6.5.0-1-amd64 breaks X on amd GPU
Control: tag -1 moreinfo Hi Klaus On Fri, Sep 15, 2023 at 10:18:55PM +0100, Klaus Ethgen wrote: > Booting with the new kernel makes the display (1920x1200) heavily > flckering, diplaying two times the same one above the other and only > displaying about 1/4 of the screen smashed together on the left border > of the screen. Does it work with native resolution? Does it work with Wayland? > Note that the broken setup has 3 lines of 3840x2400, althogh I use > 1920x1200 as resolution. With different refresh frequencies, so nothing uncommon. > 3840x2400 is no usable resolution as the display content is much to > small to be usable. That's why we now have scaling and don't need to play with resolutions. Bastian -- The idea of male and female are universal constants. -- Kirk, "Metamorphosis", stardate 3219.8
Bug#1051577: iproute2: obsolete conffiles
On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote: > As far as I understand dpkg's conffile machinery should recognize if > you changed anything, and leave it in place. Upstream moved the > default ones to /usr, so we just follow what they do. Actually using rm_conffile is wrong. This moves the file to *.dpkg-bak. However the expected behaviour is to keep them around without renaming, just removed from the dpkg database. Bastian -- "That unit is a woman." "A mass of conflicting impulses." -- Spock and Nomad, "The Changeling", stardate 3541.9
Re: Releasing linux/6.1.52-1 bookworm-security update without armel build, Image size problems
Hi On Sat, Sep 09, 2023 at 11:13:56AM +0200, Paul Gevers wrote: > If we're now reaching the final limit and if it was foreseeable that we > would reach that limit, then yes it would have made sense to drop armel > *before* the bookworm release, but alas. If the kernel team can't support > the kernel on armel, than armel shouldn't be a release architecture for > trixie. If it's only some devices, than we "just" need to communicate that > clearly. We have two armel kernel currently: - "marvell", for some CPU from Marvell, and - "rpi", for Raspberry Pi 1 and related devices. The first one is the one with included size limitations, because those load the kernel from a pre-defined flash partition, whose size can't be easily changed by the user. This one is now overflowing for the second to last documented one in the kernel package config. The second one is for the original Raspberry Pi 1 type. There we don't have any size limits, as the kernel is loaded from a file system. However those systems contain a ARMv6 CPU. So our armel port is only partially usable anyway, as is is built for ARMv4. There exists with Raspbian a better suited forked distribution with ARMv6 as target. So yes there is a small number of devices we can still support with the armel port, but where we are a bad choice. Everything newer is ARMv7, supported by the armhf port, or ARMv8, supported by the arm64 port. Latest popcon for stable is: linux-image-marvell: 31 linux-image-rpi: 7 Debian itself does not have any armel hardware. Everything is done on armhf or arm64. Sadly the armhf supporting systems are already in the progress of drying up. Even some ARMv8 vendors do not longer include 32bit support. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Bug#1035378: linux - Backport changes to Microsoft Azure Network Adapter
Control: retitle -1 inux - Backport changes to Microsoft Azure Network Adapter Hi The driver for this special Microsoft hardware is really new (introduced only a few releases ago) and hardware just now really available. So fixes, even larger ones, should still count as support for new hardware. While the stock driver in 6.1 kind of works, it is not really usable for end user workloads. On Tue, May 02, 2023 at 01:38:40PM +0200, Bastian Blank wrote: > Microsoft asked to backport the jumbo frame support in the Microsoft > Azure Network Adapter from current master. The changes are not suitable > for stable@ and contained to this one driver. This was the first thing, but several others pilled up. Just doing a bulk backport of all changes have a lower risk of introducing new problems then more targeted changes. So just including the driver in the state of, currently, 6.4 was done. Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, "Friday's Child", stardate 3497.2
Bug#1051087: reportbug: linux-headers-amd64 from bullseye-backports cannot be installed (unmet dependencies)
Hi Laurent On Sun, Sep 03, 2023 at 11:16:03AM +0200, Laurent BRULET wrote: > It's still not entirely clear to me, whether this transient issue (where > linux- > image-amd64 can be installed while the corresponding linux-headers-amd64 > can't) > is a "standard case" for backports, or it is an "exceptional" situation ? It is a transient issue. The packages are created in two steps and in backports we have no way to make sure they show up at the same time. > As a matter of facts, if it is a "standard case" for backports, I understand > that specific precautions have to be taken before deciding to upgrade a kernel > from backports, so that DKMS modules won't break. Is this correct ? DKMS currently bails out, so you should at least see it. But a really good solution this is not. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Re: Debian Kernel version and ABI in respect of #1040901
On Mon, Jul 24, 2023 at 10:36:47PM +0300, Adrian Bunk wrote: > A policy question is that it might be a good idea to rename the packages > when publishing a regression update for a DSA, that's the only place I see > where this problem might otherwise reach production systems. Adding another modifier later is easy, as long as the overall setup works. Bastian -- Oblivion together does not frighten me, beloved. -- Thalassa (in Anne Mulhall's body), "Return to Tomorrow", stardate 4770.3.
Re: Debian Kernel version and ABI in respect of #1040901
On Sun, Jul 23, 2023 at 09:44:40AM +0200, Bastian Blank wrote: > After a lot of thinking, maybe a solution that allows for incompatible > package updates without renames would be more useful. Something like: > > We uncouple the package names and ABI. The ABI will include the > complete version, so every rebuild will change it. The package names > can include just the upstream version, aka 6.1.1. And in addition: header and other support packages are not longer renamed. So they can only be installed once and need to be searched by the actual version of the image package. In any way, everything is weird and broken. We currently often run into uninstallable meta packages, due to the signing stuff adding a race condition between the availability of the header packages and the image packages. Then people tend to not reboot, so they are searching for older headers, which are already removed. And there is no really good solution. The only real solution would be to always bundle headers and images and install everything. But this will make everything 50MB larger and does not fit for things like the stripped down cloud kernels. Regards, Bastian -- What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, "Metamorphosis", stardate 3219.8
