Bug#894906: linux-cpupower: provide a systemd service and a default config file
On Sun, Sep 15, 2024 at 05:23:10PM +0200, Francesco Poli wrote: > Or otherwise, if you think there's something wrong with them, could you > please explain what is wrong? Maybe there's a way to fix them... The linux-cpupower package includes low level tools to interrogate and set certain low level CPU features. So the reasons for installing this package are two-fold, you either want to see various things, or you want to globally change them. But because of the two different usages, just installing the package can not change global settings without futher user interaction. Yes, we could provide them disabled. But overall we are currently at a point, where even desktop environments have rudimentary settings for this. And also basic cpu frequency is not longer a useful way to save energy, but things like p states as used, which just shut of whole parts of the chip. About the files itself: please loose the shell wrapper. You can use EnvironmentFile and multiple ExecStart with variable expansion (however no conditionals). Bastian -- In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, "Wolf in the Fold", stardate 3615.4
Re: Proposal: Switch to linear git history
Hi On Wed, Sep 18, 2024 at 04:53:09PM +0200, Ben Hutchings wrote: > On Thu, 2024-06-13 at 20:48 +0200, Bastian Blank wrote: > > What is not longer possible in non-confusing ways is to use branches > > named after Debian distributions. We would either need to do non fast > > forward or do --their merges. Both variants are highly confusing to > > users and the later one even got the same problems that I just described > > above. > For testing/unstable and for stable-backports suites I agree we > shouldn't do this any more. The -backports changes will need to > rebased when switching from e.g. 6.10.x to 6.11.x. Okay. We can then still work on reducing the differences and maybe at same time we only have a single changelog entry left. But this is for another day. > Having said that, a rebase isn't much more reviewable than a merge, so > I would prefer not to rebase -backports for upstream stable updates. > While merges for such updates are not automatic, the conflicts are in > practice trivial. Those are forward merges, not in both directions and not including huge version ranges. So that should be way easier manageable. > > > ## Proposal > > > > > > Stop merging back changes, but create version distinct branches. > > > Something like that: > > master: uploaded to experimental > Call this debian/latest so we follow DEP-14 as far as possible. I'm a bit reluctant on the latest, but well. The rest of the world agreed on main. > > -> debian/release/6.6: uploaded to unstable and stable releases > >-> debian/security/6.6.1+1: extra security releases > I would prefer to use suite names in these branch names, to make > itclearer what the branches correspond to. So those would be: > - debian/6.6/unstable How do you think the transition to stable will happen? Just leave it this way? I would prefer to directly use the release name, aka "debian/6.6/trixie", because this is what the package is destined for. That it is uploaded to unstable (or to (testing-)proposed-updates) is part of the technical implementation, but it does not change our policy for it (same version range etc, or did I miss some differences?). > - debian/6.6/bookworm-backports > - debian/6.6.1+1/booxie-security [*] > (swapping the release and suite so that they don't actually conflict > with DEP-14 branch names). Okay. We can then also use "debian/6.6/experimental" or "debian/6.6/latest", if necessary. Bastian -- A father doesn't destroy his children. -- Lt. Carolyn Palamas, "Who Mourns for Adonais?", stardate 3468.1.
Agenda items for kernel-team meeting on 2024-09-11
Hi This weeks meeting will happen tomorrow at 19:00 UTC in #debian-kernel. Here you can find the current agenda: https://salsa.debian.org/kernel-team/meetings/-/wikis/20240911 Please reply here if you would like to add more points. Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, "Friday's Child", stardate 3497.2
Bug#1081197: linux: please Build-Depends on 'gcc' or on 'build-essential' rather than 'gcc-13'
On Mon, Sep 09, 2024 at 05:56:50PM +0300, Martin-Éric Racine wrote: > Fair enough. In that case, I suggest editing the following (4.5.1. > Preparation) to remove the step about installing build-essential, > since it installs a compiler suite that won't be used by src:linux. build-essential is required to build any Debian package. https://www.debian.org/doc/debian-policy/ch-source.html#package-relationships Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Bug#1081197: linux: please Build-Depends on 'gcc' or on 'build-essential' rather than 'gcc-13'
On Mon, Sep 09, 2024 at 11:51:17AM +0300, Martin-Éric Racine wrote:
> src:linux currently has an explicit Build-Depends on gcc-13. This defeats the
> whole point of building against whatever 'build-essential' pulls in for the
> target Debian release, and it results in several GCC suites getting
> unnecessarily installed. It would instead be desirable for src:linux to
> Build-Depends on either the generic 'gcc' or on 'build-essential' for its
> compiler requirements.
And how will that work if src:linux uses gcc-13 to build?
Bastian
--
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
stardate unknown.
Bug#1078996: 4K vs 64K page size on upgrade
Control: tags -1 wontfix Hi Yes, this change is expected. It is documented in the NEWS file of the package and should be showed to the user via apt-listchanges. We decided to make this change, even if some systems will fail, to align Debian better to a general purpose use case. Bastian -- Beam me up, Scotty!
Agenda items for kernel-team meeting on 2024-08-21
Hi This weeks meeting will happen tomorrow at https://jitsi.debian.social/dkt. Here you can find the current agenda: https://salsa.debian.org/kernel-team/meetings/-/wikis/20240821 Please reply here if you would like to add more points. Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, "Friday's Child", stardate 3497.2
Bug#1078030: AW: AW: Bug#1078030: lpfc: lost all san paths
Hi
On Wed, Aug 07, 2024 at 08:31:28AM +, daniel.u...@telekom.de wrote:
> We are kind of lucky. My colleagues updated the kernel on one the hosts,
> rebooted it and the problem occurred right away. Currently the system is
> running, but it looks like all san paths are gone ("multipath -ll" shows
> nothing). I got the kernel log and a verbose output from multipath. If
> something other is required, please contact me.
Can you please verify that the firmware on the system and the HBA if
uptodate? Someone mentioned that there might be similar bugs fixed, but
I can not pinpoint any specifics.
According to Broadcom, 14.4.317.7 is current as of last month. See
https://www.broadcom.com/products/storage/fibre-channel-host-bus-adapters/lpe32000-m2
Bastian
--
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?" stardate 3468.1
Re: Bug#1065416: requesting input on recent posts to #1065416
On Fri, Aug 16, 2024 at 12:58:22PM +0200, Stefano Rivera wrote: > The Technical Committee is hoping that this will be resolved without > requiring us to make a decision. If the take-over offer resolves the > issue, then we will probably vote to take no further action. Well, take-over removes the need for talk. And talk is what is missing. We can do it this way, but it make the load higher for everyone. No idea if this is a good pretext to allow people to just not say anything about what they mean. But at least now Mathias actually told that his problems doesn't actually exist in the Debian archive, but outside of it. That's kind of unexpected. I have a patch to move the headers (or better said a symlink farm) to /usr/*/include. But we are still without any indication if this is the problem he talked about. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0
Bug#1077827: even with [[featureset]] name = 'rt' enable = false in config.local/defines.toml, linux-headers-*-common-rt is still getting built
On Sat, Aug 03, 2024 at 01:52:47AM +0200, Johannes Schauer Marin Rodrigues wrote: > according to Ben [1] this should disable the rt build and it mostly does but > the package linux-headers-*-common-rt will still be built. No bug in Debian, as we don't push this modification to Debian. But fixed in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1154 Bastian -- We have found all life forms in the galaxy are capable of superior development. -- Kirk, "The Gamesters of Triskelion", stardate 3211.7
Bug#1077640: update-miniramfs: 97: cannot create : Directory nonexistent
Control: reassign -1 miniramfs 1.0.2 On Wed, Jul 31, 2024 at 05:03:25PM +1000, Russell Coker wrote: > After the latest update to Debian/Unstable on my PinePhonePro I get the > following error when creating an initramfs. It didn't happen with the > previous > version of initramfs-tools which was 0.142. > > I downgraded to 0.142 and it worked correctly. > > root@pine:~# dpkg --configure -a > Setting up miniramfs (1.0.2) ... > update-miniramfs: Generating /boot/miniramfs-6.1-rockchip > /usr/sbin/update-miniramfs: 97: cannot create : Directory nonexistent > dpkg: error processing package miniramfs (--configure): > installed miniramfs package post-installation script subprocess returned > error exit status 2 > Errors were encountered while processing: > miniramfs miniramfs is not initramfs-tools, but is the only thing that shows up. I'm reassigning this to the package actually showing errors. Bastian -- There is a multi-legged creature crawling on your shoulder. -- Spock, "A Taste of Armageddon", stardate 3193.9
Agenda items for kernel-team meeting on 2024-07-31
Hi This weeks meeting will happen tomorrow. Here you can find the current agenda: https://salsa.debian.org/kernel-team/meetings/-/wikis/20240731 Please reply here if you would like to add more points. Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, "Friday's Child", stardate 3497.2
Bug#1076555: linux-image-6.9.9-amd64: boot crash RIP: 0010:kmem_cache_alloc
Control: tags -1 moreinfo On Thu, Jul 18, 2024 at 07:56:32PM +0200, Patrice Duroux wrote: > I just faced this boot problem on my sid system for the first time > since I updated the Linux kernel a few days ago. Could you please provide an unfiltered kernel log? The one you attached does not even contain the full crash message. Nor is it the first crash (visible by the D in the taint string). Regards, Bastian -- Beam me up, Scotty!
Bug#1076309: [s390x] lots of "User process fault: interruption code XXXX"
On Thu, Jul 18, 2024 at 08:06:46AM +0200, Paul Gevers wrote: > However, that doesn't seem to work on our s390x host as it seems to freeze > instead. Is this something known? Something I'm doing wrong (E.g. these > options behaving differently on s390x)? Is this a s390x kernel bug? This now points to a kernel bug. Which requires a new kernel first for further debugging. What does "freeze" mean"? Also no sysrq? See https://www.kernel.org/doc/html/v5.3/s390/debugging390.html#sysrq, but you need to enable that before. Bastian -- Not one hundred percent efficient, of course ... but nothing ever is. -- Kirk, "Metamorphosis", stardate 3219.8
Bug#1076309: [s390x] lots of "User process fault: interruption code XXXX"
Hi On Sun, Jul 14, 2024 at 09:22:32AM +0200, Paul Gevers wrote: > Today I restarted the s390x host of ci.d.n because I lost access. I > inspected the journal and noticed there were a lot kernel messages (several > tens to hundreds per day) like "User process fault: interruption code 003b > ilc:3 in my_kmcdump[2aa0798+f000]". I attached the first block I found > in the journal after the reboot. I see "003b" and "0007" as interruption codes. All those are page faults (and are reported to the user space process via SIGSEGV). Aka the process tries to access data that is not available in the page table. Why s390 decides to always dump them to the kernel log if the signal is unhandled is currently over me. There is similar code on other architectures, and also enabled by default, but I frankly have never seen it. Right now I have no idea what this could tell. Bastian -- Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, "Day of the Dove", stardate unknown
Bug#1076576: linux - Backport changes to Microsoft Azure Network Adapter
Source: linux Version: 6.1.99-1 Severity: important X-Debbugs-Cc: wa...@debian.org Microsoft asked to Backport further changes to the Microsoft Azure Network Adapter. This includes bug fixes and arm64 support. Requested where: - ec224d185e04131013121682e27adaa26b87a3a7 (bug fix) - 40a1d11fc670ac03c5dc2e5a9724b330e74f38b0 (arm64 support) The backport is done as bulk backport to minimize risks associated with it and all changes are limited to this one driver. Bastian -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (700, 'testing'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.9.8-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Agenda items for kernel-team meeting on 2024-06-26
On Tue, Jun 25, 2024 at 05:51:41PM +0100, Luca Boccassi wrote: >Anything build-depending on > linux-headers-generic for the BPF header (eg: src:systemd) is affected. Well, linux-headers is for kernel modules, not userland. Don't use it this way then? Bastian -- The joys of love made her human and the agonies of love destroyed her. -- Spock, "Requiem for Methuselah", stardate 5842.8
Agenda items for kernel-team meeting on 2024-06-26
Hi This weeks meeting will happen tomorrow. Currently the agenda is empty. See https://salsa.debian.org/kernel-team/meetings/-/wikis/20240626 If you have more points, please just reply here. Bastian -- Computers make excellent and efficient servants, but I have no wish to serve under them. Captain, a starship also runs on loyalty to one man. And nothing can replace it or him. -- Spock, "The Ultimate Computer", stardate 4729.4
Bug#1074111: [arm64] boot stops at 'Starting kernel ...' without any further output when kernel built with recent binutils
Control: reassign -1 binutils/2.42.50.20240618-1 Control: affects -1 src:linux On Sun, Jun 23, 2024 at 11:44:05AM +0200, Johannes Schauer Marin Rodrigues wrote: > One of the differences in the build environment between good and bad builds is > binutils-arm-linux-gnueabihf with version 2.42-4 in the good environment and > version 2.42.50.20240618-1 in the bad environment. To test whether this indeed > triggers the problem, we tested building our kernel with current unstable but > with binutils (= 2.42-4) and gcc-13 (= 13.2.0-25). We also have to choose an > older gcc from snapshot.d.o because recent gcc-13 requires recent binutils. > This makes the kernel work again. So for now binutils triggers the problem, lets reassign correctly to get the attention of the correct people. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4
Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool
On Sat, Jun 01, 2024 at 09:13:09PM +0100, Sudip Mukherjee wrote: > Absolutely. I dont remember why some of my packages (from 2019 - 2020) > are in github. But I will definitely move them to salsa. > About moving it under kernel team, I think I will say "no" to that > unless Luca can give some very good reasons about what is missing now > that will change if ts moved under kernel team. I then object to a move from linux to you and even using the packaged libbpf. Right now this package is also single maintainer and this is not acceptable for critical toolchain and basic userland stuff. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4
Agenda items for kernel-team meeting on 2024-06-19
Hi I started the agenda for this weeks meeting. It got already quite some points, as we have a lot of discussion items left from last week. See https://salsa.debian.org/kernel-team/meetings/-/wikis/20240619 If you have more points, please just reply here. Bastian -- Respect is a rational process -- McCoy, "The Galileo Seven", stardate 2822.3
Re: Proposal: Switch to linear git history
Hi folks On Thu, Dec 21, 2023 at 05:30:26PM +0100, Bastian Blank wrote: > What did I miss? After the discussion in our meeting today, it seems I did not properly describe the problem good enough. > 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. Okay, what we regularly do is merges between sid and master. Those merges are done by hand, but could be automated to some degree. Doing them requires the developer to take a lot of decisions in one single step: - The changelog could be managed automatically. - Added patches are usually meant just for this version and thus dropped (modified patches are unclear). - Other changes usually remain. But, especially for the last two, exceptions might be possible and can't be detected without revisiting every change in between one by one. Also those merges are not reviewed the normal way via merge requests. This makes those merge high risk, because - too broad changes can be merged, - changes can vanish, - the changes are unverified, and - inside large merges it is way easier to hide things. What we get from the merges is - a linear changelog, - the ability to select where to apply changes first, and - the ability to use per Debian distribution branches without confusing users. The linear changelog will make version tracking easier. However it is actually a lie. In certain cases it is correct (patch to 6.10 merge window and backported to 6.9.3, bug marked as fixed in 6.9.3). But in others it is a lie (breakage in 6.9.1, patch in 6.9.2). So it should be better to explicitly close such bugs in both 6.9.2 and 6.10~rc1. We also don't really need to select early where a patch should be applied. We can just backport merge requests to different branches, and we can even create some scripts to make it easier. Normal changes to to master, version specific fixes directly to this version. This also reduces the mental load for submitters, as they can always start at the master branch. What is not longer possible in non-confusing ways is to use branches named after Debian distributions. We would either need to do non fast forward or do --their merges. Both variants are highly confusing to users and the later one even got the same problems that I just described above. I believe we have to remove this task that currently is only done by three people. This is the reason why I propose branching schemes based on actual versions and not Debian distributions. > ## Proposal > > Stop merging back changes, but create version distinct branches. > Something like that: master: uploaded to experimental -> debian/release/6.6: uploaded to unstable and stable releases -> debian/backport/6.6.1-1: uploaded to backports (not really needed in most cases) -> debian/security/6.6.1+1: extra security releases Bastian -- Beam me up, Scotty, there's no intelligent life down here!
Re: Kernel features and Cloud (and GCE)
Hi Andrew On Wed, May 22, 2024 at 07:44:33AM -0700, Andrew Jorgensen wrote: > The Debian images in Google Compute Engine use the Debian cloud > kernel. This has been working well for us, because it includes the > VirtIO, NVMe, and gVNIC drivers that are needed for most GCE machine > types. As we move forward, additional kernel features are needed to > support all features of current and future machine types. > > For example, we’re going to make an Intel 6300ESB watchdog device > available, and that needs a driver that’s been in Linux a long time > but isn’t enabled in the cloud kernel. For that one, another Debian > user +1’d the request because it would benefit users of other > KVM-based clouds (including private clouds). We can enumerate other > examples, but many of those also require backports or a future Debian > release. We already backport the Microsoft MANA network driver. So at least backports to stable are not that of a problem, if someone does it. Backports to oldstable are most likely not happening, as this target is too far off. > Recently in response to another feature request for the cloud kernel, > Noah Meyerhans mentioned that, “historically the cloud kernels have > specifically targeted Amazon EC2 and Microsoft Azure.” Yes, this is the documented target. We did never properly add GCP, because no communication happened. I think we can do that, if someone does a due diligence and knows the documentation better then we. > So we have the problem that the Debian cloud kernel supports some, but > not all, of the devices our shared users need, and we’re not sure of > the right way to solve that. We wondered if we should switch the > images to the generic kernel, or if there’s a way we could help the > cloud kernel support more clouds, or if there’s a better solution we > haven’t thought of. We can support more clouds. It is just a matter of taking care of it. I currently play with splitting the modules into multiple different sets, like almost all other distributions already do. We would not need to do multiple builds then and more targeted packages would be possible if needed. Regards, Bastian -- Conquest is easy. Control is not. -- Kirk, "Mirror, Mirror", stardate unknown
Bug#1071825: linux-image-6.8.9-amd64: Fails to build some module(s) during install
Control: reassign -1 ddcci-dkms/0.4.4-1 Control: severity -1 serious On Sat, May 25, 2024 at 10:08:30AM +0200, Gregor Düster wrote: > unfortunately, configuration of the latest linux-image-6.8.9-amd64 > (6.8.9-1) fails with the following error: > Here's the content of /var/lib/dkms/ddcci/0.4.4/build/make.log: > > DKMS make.log for ddcci-0.4.4 for kernel 6.8.9-amd64 (x86_64) > Sat 25 May 09:43:08 CEST 2024 > make: Entering directory '/var/lib/dkms/ddcci/0.4.4/build' > make -C "ddcci" > make[1]: Entering directory '/var/lib/dkms/ddcci/0.4.4/build/ddcci' > make -C "/lib/modules/6.8.9-amd64/build" > M="/var/lib/dkms/ddcci/0.4.4/build/ddcci" modules > make[2]: Entering directory '/usr/src/linux-headers-6.8.9-amd64' > CC [M] /var/lib/dkms/ddcci/0.4.4/build/ddcci/ddcci.o > /var/lib/dkms/ddcci/0.4.4/build/ddcci/ddcci.c: In function ‘ddcci_detect’: > /var/lib/dkms/ddcci/0.4.4/build/ddcci/ddcci.c:1673:9: error: implicit > declaration of function ‘strlcpy’; did you mean ‘strscpy’? > [-Werror=implicit-function-declaration] > 1673 | strlcpy(info->type, (outer_addr == DDCCI_DEFAULT_DEVICE_ADDR) > ? "ddcci" : "ddcci-dependent", I2C_NAME_SIZE); > | ^~~ > | strscpy > /var/lib/dkms/ddcci/0.4.4/build/ddcci/ddcci.c: At top level: > /var/lib/dkms/ddcci/0.4.4/build/ddcci/ddcci.c:1831:27: error: ‘I2C_CLASS_DDC’ > undeclared here (not in a function); did you mean ‘I2C_CLASS_SPD’? > 1831 | .class = I2C_CLASS_DDC, > | ^ > | I2C_CLASS_SPD > cc1: some warnings being treated as errors > make[4]: *** [/usr/src/linux-headers-6.8.9-common/scripts/Makefile.build:248: > /var/lib/dkms/ddcci/0.4.4/build/ddcci/ddcci.o] Error 1 > make[3]: *** [/usr/src/linux-headers-6.8.9-common/Makefile:1946: > /var/lib/dkms/ddcci/0.4.4/build/ddcci] Error 2 > make[2]: *** [/usr/src/linux-headers-6.8.9-common/Makefile:252: __sub-make] > Error 2 > make[2]: Leaving directory '/usr/src/linux-headers-6.8.9-amd64' > make[1]: *** [Makefile:38: ddcci.ko] Error 2 > make[1]: Leaving directory '/var/lib/dkms/ddcci/0.4.4/build/ddcci' > make: *** [Makefile:28: ddcci] Error 2 > make: Leaving directory '/var/lib/dkms/ddcci/0.4.4/build' > > > Please point out in case I did anything wrong reporting this bug, this > is the first time I'm using reportbug. You opened it against the wrong package. Your ddcci module is broken and needs to be updated to be compatible with Linux 6.8. The package you have opened the bug against is only the messenger. Anyway, I fixed this for you. Bastian -- One does not thank logic. -- Sarek, "Journey to Babel", stardate 3842.4
Re: Contacting Debian Kernel team
Hi On Mon, May 20, 2024 at 01:06:52PM +0200, Diederik de Haas wrote: > >From "Salsa stats for the curious" on debian-project ML: > On Friday, 12 April 2024 17:32:04 CEST Joerg Jaspert wrote: > > The VM this all runs on has 8 cores and 32g > > I had several thoughts about that: > - But why doesn't have f.e. 4x or 8x those resources? As former Salsa admin, I might be able give some insight in that. GitLab is only so much able to scale vertically. Instead you need to scale all of that horizontally. With this you can get amazing things out of it. Just remember that gitlab.com is three to four magnitudes larger. We even had a plan to do that somewhat at that time, but in the end it failed due to external circumstances. > Not hindered by any knowledge in this specific area, this seems an area where > throwing money at it will actually help. Possibly substantially. It is not so much the problem of throwing money. It's disagreements between teams and how things can be made better. Bastian -- The joys of love made her human and the agonies of love destroyed her. -- Spock, "Requiem for Methuselah", stardate 5842.8
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&arch=powerpc&ver=6.7-1%7Eexp1&stamp=1704796355&raw=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&id=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
