Re: ABI-changing kernel security fixes for sarge
On Thu, 24 Mar 2005 08:56:52 +0100, Sven Luther wrote: On Wed, Mar 23, 2005 at 11:53:45PM -0500, Andres Salomon wrote: On Wed, 23 Mar 2005 23:10:18 +0100, Sven Luther wrote: On Wed, Mar 23, 2005 at 03:13:32PM -0500, Andres Salomon wrote: [...] Well, i was thinking about handling security issues in modules without needing the full kernel rebuild. You have the kernel as normal, and some infrastructure similar to the non-free-modules one, where the affected kernel will not be rebuilt, but we only generate a module package / .udeb that fixes said security hole, and upload it to security.d.o, together with a meta-package (kernel-security-modules or whatever) that depends on it and that will be installed per default in sarge. This means that a apt-get upgrade with security will pull in the new module, which will replace the actual module with the diversion mechanism, and then in the postinst ensure that the module gets unloaded and reloaded or whatever. Not sure about how this last mechanism will actually work in the face of permanent modules and module in a dependency chain where one part of the system depends on them. I was with you up until the module-reload-in-postinst bit. I think there are enough broken refcounting modules that this won't work; plus, modules that are actively in use (usb stuff that's mounted, nics, etc) won't be able to be reloaded. I also don't really think it's necessary; there has to be a better way to allow an admin to revert back to an older version of a driver if the new one is broken. But then, i have a feeling that mostly the security holes where not really in modules but in some main part. The main reason I like the idea of decoupling drivers is, I can see when something in core is broken. It may take a lot of tracing through code, but in the end, it makes sense (the notable exception being the arch/ subdir). With drivers, if something is broken, it tends to come down to some hardware bug, or incorrect usage of a device; that sort of thing needs people w/ hardware to test, vendor specs and errata, etc. As such, it typically means regressions galore during large updates. Mmm, you are thinking driver/modules updates separated from the kernel here, not security fixes. Core updates thus end up being safer, so doing them during, say, a stable release is not something I would overly worry about. Driver updates are another matter entirely. Ok. This seems to be material for etch though, and something we need to lengthily discuss. Do you have an idea whta proportion of security issues involve modules, and not the core part as you put above ? Well, I'd basically break up core by subdirectories; everything but the drivers/ subdir would be in core. Most of the (publicized) security issues are outside of drivers/; they've been in fs/, mm/, rarely in arch/, etc. People seem to put more effort into security holes that affect everyone, versus holes that only affect people w/ a specific card. That's not to say there aren't holes in drivers; for example, I noticed the following yesterday: http://gkernel.bkbits.net:8080/netdev-2.6/[EMAIL PROTECTED] Looks like a potential security hole to me. Will it be publicized? Probably not; it would be hard to exploit (I'm assuming someone would have to be on the local network to work around the gateway ensuring frames don't exceed the MTU), would only affect a small subset of Linux users, and someone would actually have to go through the trouble of making sure it actually *can* be exploited. There are plenty of these types of fixes all over the drivers/ subdir; there certainly have been publicized drivers/ holes (see Brad Spengler's advisories for moxa and so on), but they're typically easy to spot and fix (integer overflows in ioctls, etc). The holes in core generally get publicized, assigned CAN#s, etc; and those are the ones we (debian, ubuntu, redhat, etc) fix. They also tend to be a bit more complex; races in mmap, elf header mishandling, smbfs's crackheaded code doing wacky stuff, and so on. Ok. So that makes my own idea not so good, but i understand that building the core part apart from the drivers may be possible, but may represent lot of work. Not all things under drivers are modularizable, and some of them are built in the kernel (like fbdev drivers, or serial-ata console). This joins something i have been interested in a long time for the over-modular powerpc kernel. We have a problem with all the fbdev drivers. They have to be builtin to get early console output, but we cannot buildin all the fbdev drivers that are available. Yep. I think Herbert had the right idea w/ his modularization patches; they just needed to be in better shape (from upstream's perspective). It's probably worth spending time working w/ upstream to get all drivers that we actually care about using the driver model, and dealing w/ module issues nicely.
Re: ABI-changing kernel security fixes for sarge
On Thu, Mar 24, 2005 at 03:39:02AM -0500, Andres Salomon wrote: My idea would be to have a mechanism for loading modules earlier, and move the initrd initialization as early as possible, and load modules from there even before we do stuff like serial console setup or framebuffer setup. But this is probably something for etch too. Jeff Bailey has been doing work w/ initramfs. If we switch to this, post-sarge, it will allow us to have much cleaner initialization, and more intelligent, as well. Instead of a mess of initrd shell scripts, and magic initialization crud, we can have proper (small C) programs built against klibc. The setup that I've seen has been initializing networking from within the initramfs image, and mounting / over nfs. Rather nifty stuff. We could probably have a proper initialization via modules, where the proper fbdev modules get loaded first, followed by the rest of the initialization; without dealing w/ the initrd mess. Something to consider. We'll have to play w/ it some more. Well, yes, this is all fine, but we need something to load modules from the initrd from inside the kernel itself, namely the serial-console and fbdev drivers or anything else which provides visual output. Having no output until the initrd comes up and initialialises the fbdev driver is no option. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of kernel-image-2.6.8-amd64_2.6.8-12_i386.changes
kernel-image-2.6.8-amd64_2.6.8-12_i386.changes uploaded successfully to localhost along with the files: kernel-image-2.6.8-amd64_2.6.8-12.dsc kernel-image-2.6.8-amd64_2.6.8-12.tar.gz kernel-headers-2.6.8-10_2.6.8-12_i386.deb kernel-headers-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb kernel-image-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb kernel-headers-2.6.8-10-em64t-p4_2.6.8-12_i386.deb kernel-image-2.6.8-10-em64t-p4_2.6.8-12_i386.deb kernel-headers-2.6.8-10-amd64-generic_2.6.8-12_i386.deb kernel-image-2.6.8-10-amd64-generic_2.6.8-12_i386.deb kernel-headers-2.6.8-10-amd64-k8_2.6.8-12_i386.deb kernel-image-2.6.8-10-amd64-k8_2.6.8-12_i386.deb kernel-headers-2.6.8-10-em64t-p4-smp_2.6.8-12_i386.deb kernel-image-2.6.8-10-em64t-p4-smp_2.6.8-12_i386.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295412: marked as done (initrd-tools: Fails to ignore 32bit emulation layer on ldd calls)
Your message dated Thu, 24 Mar 2005 04:19:02 -0500
with message-id [EMAIL PROTECTED]
and subject line Bug#295422: fixed in kernel-image-2.6.8-amd64 2.6.8-12
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--
Received: (at submit) by bugs.debian.org; 15 Feb 2005 17:46:33 +
From [EMAIL PROTECTED] Tue Feb 15 09:46:33 2005
Return-path: [EMAIL PROTECTED]
Received: from mx4.informatik.uni-tuebingen.de [134.2.12.29]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1D16mO-0007bR-00; Tue, 15 Feb 2005 09:46:32 -0800
Received: from localhost (loopback [127.0.0.1])
by mx4.informatik.uni-tuebingen.de (Postfix) with ESMTP
id EF73B13D5; Tue, 15 Feb 2005 18:46:01 +0100 (NFT)
Received: from mx4.informatik.uni-tuebingen.de ([127.0.0.1])
by localhost (mx4 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
id 40754-05; Tue, 15 Feb 2005 18:46:01 +0100 (NFT)
Received: from localhost.localdomain (semeai.Informatik.Uni-Tuebingen.De
[134.2.15.66])
by mx4.informatik.uni-tuebingen.de (Postfix) with ESMTP
id EC84C13D1; Tue, 15 Feb 2005 18:46:00 +0100 (NFT)
Received: from mrvn by localhost.localdomain with local (Exim 4.44)
id 1D16jo-DY-OU; Tue, 15 Feb 2005 18:43:52 +0100
Content-Type: multipart/mixed; boundary2567455787233321472==
MIME-Version: 1.0
From: Goswin Brederlow [EMAIL PROTECTED]
To: Debian Bug Tracking System [EMAIL PROTECTED]
Subject: initrd-tools: Fails to ignore 32bit emulation layer on ldd calls
X-Mailer: reportbug 3.7.1
Date: Tue, 15 Feb 2005 18:43:52 +0100
Message-Id: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
This is a multi-part MIME message sent by reportbug.
--===2567455787233321472==
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Package: initrd-tools
Version: 0.1.77
Severity: important
Tags: patch
Hi,
when running a 64bit kernel with 32bit userspace on i386 the ldd
output includes the 32bit emulation layer as linux-gate.so library
without any realy file and mapped to 0x. Since mkinitrd tries
to cpio all {$3} from the ldd output it fails with (0x) being
missing.
--
[EMAIL PROTECTED]:~% sudo chroot /var/chroot ldd /bin/sh
linux-gate.so.1 = (0x)
libncurses.so.5 = /lib/libncurses.so.5 (0x55572000)
libdl.so.2 = /lib/tls/libdl.so.2 (0x555b1000)
libc.so.6 = /lib/tls/libc.so.6 (0x555b5000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x5000)
--
The attached patch filters out the extraneous entry from the ldd
output.
MfG
Goswin
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.8-frosties-1
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages initrd-tools depends on:
ii coreutils [fileutils] 5.2.1-2The GNU core utilities
ii cpio 2.5-1.2GNU cpio -- a program to manage ar
ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F
ii dash 0.5.2-1The Debian Almquist Shell
ii util-linux2.12p-2Miscellaneous system utilities
-- no debconf information
--===2567455787233321472==
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=mkinitrd.patch
--- mkinitrd.orig 2005-02-15 17:52:39.356880824 +0100
+++ mkinitrd2005-02-15 17:53:34.649475072 +0100
@@ -841,7 +841,7 @@
return $err
;;
esac
- echo $x
+ echo $x | grep -v linux-gate.so
}
add_modules_most() {
--===2567455787233321472==--
---
Received: (at 295422-close) by bugs.debian.org; 24 Mar 2005 09:30:11 +
From [EMAIL PROTECTED] Thu Mar 24 01:30:11 2005
Return-path: [EMAIL PROTECTED]
Received: from newraff.debian.org [208.185.25.31] (mail)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DEOfL-0005Dr-00; Thu, 24 Mar 2005
Bug#279382: marked as done (64-bit kernel - ldd - mkinitrd issue)
Your message dated Thu, 24 Mar 2005 04:19:02 -0500 with message-id [EMAIL PROTECTED] and subject line Bug#295422: fixed in kernel-image-2.6.8-amd64 2.6.8-12 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 2 Nov 2004 18:28:10 + From [EMAIL PROTECTED] Tue Nov 02 10:28:10 2004 Return-path: [EMAIL PROTECTED] Received: from webmail.cs.unm.edu (mail.cs.unm.edu) [64.106.20.39] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CP3O6-0001Nc-00; Tue, 02 Nov 2004 10:28:10 -0800 Received: from snot.cs.unm.edu ([64.106.46.98]) by mail.cs.unm.edu with esmtp (Exim 3.35 #1 (Debian)) id 1CP2RU-0007cL-00; Tue, 02 Nov 2004 10:27:36 -0700 Received: from bap by snot.cs.unm.edu with local (Exim 4.34) id 1CP2Po-0005Xw-Fx; Tue, 02 Nov 2004 10:25:52 -0700 From: Barak Pearlmutter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: 64-bit kernel - ldd - mkinitrd issue Reply-to: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] Sender: Barak Pearlmutter [EMAIL PROTECTED] Date: Tue, 02 Nov 2004 10:25:52 -0700 X-Scanner: exiscan *1CP2RU-0007cL-00*/fVpxy7ZVDI* Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: initrd-tools Version: 0.1.74 There is an unfortunate interaction that occurs when a system is running an em64t-p4 or amd64 kernel, but a standard 32-bit testing user space. When configuring a kernel-image package the mkinitrd fails with a cpio failure to read a file named (0x). The cause of this is that ldd has an extra entry: with a 32-bit kernel you see this # ldd /bin/cat libc.so.6 = /lib/tls/libc.so.6 (0x40028000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) but with a 64-bit kernel you see this # uname -a Linux x 2.6.8-9-em64t-p4-smp #1 SMP Thu Oct 7 16:01:47 CEST 2004 x86_64 GNU/Linux # ldd /bin/cat linux-gate.so.1 = (0x) libc.so.6 = /lib/tls/libc.so.6 (0x5557d000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x5000) When mkinitrd runs ldd on executables to find libraries to be included them in the initrd, it does not skip the linux-gate line and instead includes an entry for the strange filename, which fails. This would be really easy to fix by hacking mkinitrd, either by ignoring filenames that don't start with /, or that do start with (, or by ignoring the linux-gate lines specially, or whatever. Or (the right solution) ldd could be modified to take a flag telling it to just print the filenames of all used libraries and mkinitrd could call it that way, removing the need to parse ldd's output. But as a cheesy workaround for myself, which might be of value to others, I created a stub # cat /usr/local/bin/ldd #! /bin/sh /usr/bin/ldd $* | egrep -v linux-gate\[.\]so\[.\]1 and then did PATH=/usr/local/bin:$PATH dpkg --configure --pending which worked fine. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/ --- Received: (at 295422-close) by bugs.debian.org; 24 Mar 2005 09:30:11 + From [EMAIL PROTECTED] Thu Mar 24 01:30:11 2005 Return-path: [EMAIL PROTECTED] Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DEOfL-0005Dr-00; Thu, 24 Mar 2005 01:30:11 -0800 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1DEOUY-0004kg-00; Thu, 24 Mar 2005 04:19:02 -0500 From: =?utf-8?q?Frederik_Sch=C3=BCler?= [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Katie: $Revision: 1.55 $ Subject: Bug#295422: fixed in kernel-image-2.6.8-amd64 2.6.8-12 Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Thu, 24 Mar 2005 04:19:02 -0500 Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Source: kernel-image-2.6.8-amd64 Source-Version: 2.6.8-12 We
Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
On Thu, 24 Mar 2005 09:24:48 +0100, Sven Luther wrote: [...] The proposal is the following : 1) now that rc3 is out we forget about the current kernels, well, not exactly, but we forget about the current kernel build system, including .udebs. 2) we take as basis the ubuntu kernel build infrastructure. 3) we throw out the ubuntu patches, configs and 2.6.10 orig source tarball. Basing post-sarge kernels off the ubuntu kernel build infrastructure is something we've planned for a while. Are you saying do this for 2.6.8 as well? I'm not overly excited about doing more work on 2.6.8; I'd rather see sarge release. If it doesn't release, then let's pull 2.6.12 or whatever in (w/ whatever build infrastructure changes we might've made to it. No sense holding back progress in the sid kernels because sarge is taking forever). 4) we add our (2.4.27/2.6.8) own patches, and the kernel configs for all our arches. One of the things that both ubuntu and debian need is a config tool to make configs consistent across all archs. I started on this, but never finished it; I'll finish it at some point, but there are higher priority things to do right now. 5) we add support for the series patch handling support which is superior to the ubuntu one. While I agree that the series stuff is, the kernel-tree stuff shouldn't be necessary w/ a single-source kernel-source package. When a new upload is done, the buildds for all archs should rebuild kernel images; no mess, no fuss, no need to keep support for kernel-image packages that explicitly build against an older kernel-source patchset. Of course, we won't be able to do this immediately; not until all archs are generated from kernel-source. 6) we add support for per-arch/subarch patchsets, which is needed for replacing the current kernels. Ype. 7) we (well, probably joey and colin), adapt the .udeb generation to generate those .udebs directly from the kernel packages as ubuntu does. We need to keep our current working rc3 module list though. I'm not sold on the udeb generation stuff, but I haven't looked into it that much. If you, joeyh, and the rest of the d-i people think it's a good idea, then I don't see a reason not to. I haven't heard the opinions of the rest of the d-i people, other than someone mentioning something about breaking dpkg due to the sheer number of generated binary packages. I dunno if that's still the case. Once we have that, which can be done concurently with the remaining of sarge release process, we are in a good shape to launch a final rebuild of the d-i images with those kernels, and we will have an infrastructure which will allow streamlined new d-i uploads in a couple of says, even with kernel abi changes, since it would only need : A) fix the only kernel-source's security issue, check that it doesn't break arch/subarch specific patches (can be automated to a degree), and fix those. The way that arch/subarch specific patches are handled needs to be thought out. There are architectures that are close to linus kernels, and there are those that aren't. The preferred way to do things is to have something similar to what k-s does now; all patches (whether arch-specific or not) are applied. Of course, when arch-specific patches end up being megabytes in size, and conflict w/ each other, I realize that we need another layer on top of that; patches that are only applied to k-s when building for a certain arch. This does add complexity, though. I'd like to avoid that, if possible. If that means working really hard to get upstream to sync up w/ arch-specific stuff, so be it (really, that seems like a better long term solution then to add infrastructure to allow more and more source drift away from linus' kernels for each arch). B) the security team launches the build on the security network, resulting in a set of security fixed .debs/.udebs. C) the security/d-i rebuilds d-i with those kernels. Should take less than a day, i believe, since we mostly already do daily builds of those. D) the iso images are autobuilt on a fast machine (i hear there is a new one available that does the job pretty fast), which may even if possible be only a partial rebuild because only a small subset of packages will need to be changed. Only A includes the real work, B-C can be automated, and the time delay on those can be quantified and get an upper bound. I believe this is a good solution, which i would have pushed for etch, but which i feel we do need for the sarge release, even if this means a little delay, altough this delay can be minimal indeed since the work can happen in parallel with the rest of the RC bug fixing, and we can easily check that the new kernels produce the exact same files built from the exact same sources/patches with the exact same configs, except for build host and timestamp modification they should even be
Bug#295422: marked as done (kernel-image-2.6.8-9-amd64-k8-smp: unable to install new kernels)
Your message dated Thu, 24 Mar 2005 04:19:02 -0500 with message-id [EMAIL PROTECTED] and subject line Bug#295422: fixed in kernel-image-2.6.8-amd64 2.6.8-12 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 15 Feb 2005 18:47:48 + From [EMAIL PROTECTED] Tue Feb 15 10:47:48 2005 Return-path: [EMAIL PROTECTED] Received: from (mail.richard-group.com) [205.234.170.66] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1D17jg-00037r-00; Tue, 15 Feb 2005 10:47:48 -0800 Received: by mail.richard-group.com (Postfix, from userid 1000) id EA99C828084; Tue, 15 Feb 2005 13:47:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Kurt Yoder [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: kernel-image-2.6.8-9-amd64-k8-smp: unable to install new kernels X-Mailer: reportbug 3.2 Date: Tue, 15 Feb 2005 13:47:47 -0500 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: kernel-image-2.6.8-9-amd64-k8-smp Version: 2.6.8-8 Severity: normal After installing the amd64 kernel, I am unable to install any other kernels. I see this: Unpacking kernel-image-2.6-amd64-generic (from .../kernel-image-2.6-amd64-generic_100_i386.deb) ... Setting up kernel-image-2.6.8-9-amd64-generic (2.6.8-8) ... cpio: (0x): No such file or directory cp: cannot stat `(0x)': No such file or directory run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return code 1 Failed to create initrd image. After some amd64 users mailing list postings, I found out that I needed e2fsprogs = version 1.35-7. At this version, a grep -v linux-gate.so line was added in /usr/share/initrd-tools/scripts/e2fsprogs, which is required for initrd to work with 64-bit kernels. Thus, for amd64 kernels, I would propose a version dependency of e2fsprogs = 1.35-7 to fix this in the future. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.8-9-amd64-k8-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages kernel-image-2.6.8-9-amd64-k8-smp depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.77 tools to create initrd image for p ii module-init-tools 3.1-rel-2 tools for managing Linux kernel mo -- no debconf information --- Received: (at 295422-close) by bugs.debian.org; 24 Mar 2005 09:30:11 + From [EMAIL PROTECTED] Thu Mar 24 01:30:11 2005 Return-path: [EMAIL PROTECTED] Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DEOfL-0005Dr-00; Thu, 24 Mar 2005 01:30:11 -0800 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1DEOUY-0004kg-00; Thu, 24 Mar 2005 04:19:02 -0500 From: =?utf-8?q?Frederik_Sch=C3=BCler?= [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Katie: $Revision: 1.55 $ Subject: Bug#295422: fixed in kernel-image-2.6.8-amd64 2.6.8-12 Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Thu, 24 Mar 2005 04:19:02 -0500 Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Source: kernel-image-2.6.8-amd64 Source-Version: 2.6.8-12 We believe that the bug you reported is fixed in the latest version of kernel-image-2.6.8-amd64, which is due to be installed in the Debian FTP archive: kernel-headers-2.6.8-10-amd64-generic_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-headers-2.6.8-10-amd64-generic_2.6.8-12_i386.deb kernel-headers-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-headers-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb kernel-headers-2.6.8-10-amd64-k8_2.6.8-12_i386.deb to
Bug#292080: marked as done (error installing kernel-image-2.6.8-9-em64t-p4-smp)
Your message dated Thu, 24 Mar 2005 04:19:02 -0500 with message-id [EMAIL PROTECTED] and subject line Bug#295422: fixed in kernel-image-2.6.8-amd64 2.6.8-12 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 25 Jan 2005 00:33:12 + From [EMAIL PROTECTED] Mon Jan 24 16:33:11 2005 Return-path: [EMAIL PROTECTED] Received: from port-222-152-49-221.fastadsl.net.nz (mx2.networker.co.nz) [222.152.49.221] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CtEdr-0005Fc-00; Mon, 24 Jan 2005 16:33:11 -0800 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.networker.co.nz (Postfix) with ESMTP id 2E47A1E5296 for [EMAIL PROTECTED]; Tue, 25 Jan 2005 13:33:14 +1300 (NZDT) Received: from mx2.networker.co.nz ([127.0.0.1]) by localhost (mx2.networker.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04765-04 for [EMAIL PROTECTED]; Tue, 25 Jan 2005 13:33:12 +1300 (NZDT) Received: from [192.168.1.10] (203-167-190-1.dsl.clear.net.nz [203.167.190.1]) by mx2.networker.co.nz (Postfix) with ESMTP id F05781E524B for [EMAIL PROTECTED]; Tue, 25 Jan 2005 13:33:11 +1300 (NZDT) Message-ID: [EMAIL PROTECTED] Date: Tue, 25 Jan 2005 13:33:04 +1300 From: Simon Buchanan [EMAIL PROTECTED] User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: [EMAIL PROTECTED] Subject: error installing kernel-image-2.6.8-9-em64t-p4-smp Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at networker.co.nz Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: kernel-image-2.6.8-9-em64t-p4-smp Version: 2.6.8-8 When i try to apt-get install the kernel-image-2.6.8-9-em64t-p4-smp i get a error code back. The transcript is: mx1:/# apt-get install kernel-image-2.6.8-9-em64t-p4-smp Reading Package Lists... Done Building Dependency Tree... Done kernel-image-2.6.8-9-em64t-p4-smp is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Setting up kernel-image-2.6.8-9-em64t-p4-smp (2.6.8-8) ... cpio: (0x): No such file or directory cp: cannot stat `(0x)': No such file or directory run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return code 1 Failed to create initrd image. dpkg: error processing kernel-image-2.6.8-9-em64t-p4-smp (--configure): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: kernel-image-2.6.8-9-em64t-p4-smp E: Sub-process /usr/bin/dpkg returned an error code (1) I am using Debian testing on a dual xeon (nocona). --- Received: (at 295422-close) by bugs.debian.org; 24 Mar 2005 09:30:11 + From [EMAIL PROTECTED] Thu Mar 24 01:30:11 2005 Return-path: [EMAIL PROTECTED] Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DEOfL-0005Dr-00; Thu, 24 Mar 2005 01:30:11 -0800 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1DEOUY-0004kg-00; Thu, 24 Mar 2005 04:19:02 -0500 From: =?utf-8?q?Frederik_Sch=C3=BCler?= [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Katie: $Revision: 1.55 $ Subject: Bug#295422: fixed in kernel-image-2.6.8-amd64 2.6.8-12 Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Thu, 24 Mar 2005 04:19:02 -0500 Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Source: kernel-image-2.6.8-amd64 Source-Version: 2.6.8-12 We believe that the bug you reported is fixed in the latest version of kernel-image-2.6.8-amd64, which is due to be installed in the Debian FTP archive: kernel-headers-2.6.8-10-amd64-generic_2.6.8-12_i386.deb to
Bug#297724: marked as done (kernel-image-2.6.8-10-amd64-k8 fials to install)
Your message dated Thu, 24 Mar 2005 04:19:02 -0500 with message-id [EMAIL PROTECTED] and subject line Bug#295422: fixed in kernel-image-2.6.8-amd64 2.6.8-12 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 2 Mar 2005 14:58:50 + From [EMAIL PROTECTED] Wed Mar 02 06:58:50 2005 Return-path: [EMAIL PROTECTED] Received: from smtp-vbr3.xs4all.nl [194.109.24.23] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1D6VJJ-0005EP-00; Wed, 02 Mar 2005 06:58:49 -0800 Received: from yellowmatter.xs4all.nl (yellowmatter.xs4all.nl [213.84.170.149]) by smtp-vbr3.xs4all.nl (8.12.11/8.12.11) with ESMTP id j22EwmuC073577 for [EMAIL PROTECTED]; Wed, 2 Mar 2005 15:58:48 +0100 (CET) (envelope-from [EMAIL PROTECTED]) Received: from custard.yellowmatter (custard.yellowmatter [10.0.0.159]) by yellowmatter.xs4all.nl (Postfix) with ESMTP id A6594142D8 for [EMAIL PROTECTED]; Wed, 2 Mar 2005 15:58:47 +0100 (CET) Received: from 10.0.0.155 (SquirrelMail authenticated user jaap) by custard.yellowmatter with HTTP; Wed, 2 Mar 2005 15:58:47 +0100 (CET) Message-ID: [EMAIL PROTECTED] Date: Wed, 2 Mar 2005 15:58:47 +0100 (CET) Subject: kernel-image-2.6.8-10-amd64-k8 fials to install From: Jaap van Wingerde [EMAIL PROTECTED] To: [EMAIL PROTECTED] User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by XS4ALL Virus Scanner Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-5.6 required=4.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HAS_PACKAGE,PRIORITY_NO_NAME autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: kernel-image-2.6.8-10-amd64-k8 Version: 2.6.8-11 Processor: Athlon 64 3000+ jaap:~# uname -a Linux jaap 2.6.8-9-amd64-k8 #1 Wed Dec 8 13:26:29 UTC 2004 x86_64 GNU/Linux jaap:~# jaap:~# dselect ... running dpkg --pending --configure ... Setting up kernel-image-2.6.8-10-amd64-k8 (2.6.8-11) ... cpio: (0x): No such file or directory cp: cannot stat `(0x)': No such file or directory run-parts: /usr/share/initrd-tools/scripts/e2fsprogs exited with return code 1 Failed to create initrd image. dpkg: error processing kernel-image-2.6.8-10-amd64-k8 (--configure): subprocess post-installation script returned error exit status 9 Errors were encountered while processing: jaap:~# image-2.6.8-10-amd64-k8 dpkg --configure returned error exit status 1. Press enter to continue. -- ** Homo bureaucrasis: survival of the fittest? ** Jaap van Wingerde e-mail: [EMAIL PROTECTED] internet: http://jaap.vanwingerde.net/ --- Received: (at 295422-close) by bugs.debian.org; 24 Mar 2005 09:30:11 + From [EMAIL PROTECTED] Thu Mar 24 01:30:11 2005 Return-path: [EMAIL PROTECTED] Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DEOfL-0005Dr-00; Thu, 24 Mar 2005 01:30:11 -0800 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1DEOUY-0004kg-00; Thu, 24 Mar 2005 04:19:02 -0500 From: =?utf-8?q?Frederik_Sch=C3=BCler?= [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Katie: $Revision: 1.55 $ Subject: Bug#295422: fixed in kernel-image-2.6.8-amd64 2.6.8-12 Message-Id: [EMAIL PROTECTED] Sender: Archive Administrator [EMAIL PROTECTED] Date: Thu, 24 Mar 2005 04:19:02 -0500 Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Source: kernel-image-2.6.8-amd64 Source-Version: 2.6.8-12 We believe that the bug you reported is fixed in the latest version of kernel-image-2.6.8-amd64, which is due to be installed in the Debian FTP archive: kernel-headers-2.6.8-10-amd64-generic_2.6.8-12_i386.deb to pool/main/k/kernel-image-2.6.8-amd64/kernel-headers-2.6.8-10-amd64-generic_2.6.8-12_i386.deb kernel-headers-2.6.8-10-amd64-k8-smp_2.6.8-12_i386.deb to
Processed: reopening 295412
Processing commands for [EMAIL PROTECTED]: reopen 295412 Bug#295412: initrd-tools: Fails to ignore 32bit emulation layer on ldd calls Bug#279382: 64-bit kernel - ldd - mkinitrd issue Bug#292080: error installing kernel-image-2.6.8-9-em64t-p4-smp Bug#295422: kernel-image-2.6.8-9-amd64-k8-smp: unable to install new kernels Bug#297724: kernel-image-2.6.8-10-amd64-k8 fials to install Bug reopened, originator not changed. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 295412
Processing commands for [EMAIL PROTECTED]: tags 295412 + sarge Bug#295412: initrd-tools: Fails to ignore 32bit emulation layer on ldd calls Tags were: patch Bug#279382: 64-bit kernel - ldd - mkinitrd issue Bug#292080: error installing kernel-image-2.6.8-9-em64t-p4-smp Bug#295422: kernel-image-2.6.8-9-amd64-k8-smp: unable to install new kernels Bug#297724: kernel-image-2.6.8-10-amd64-k8 fials to install Tags added: sarge End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
On Thu, Mar 24, 2005 at 04:31:24AM -0500, Andres Salomon wrote: Now, for this to be fully efficient, there is still a little change that needs done to d-i. Support for the kernel meta-packages for all arches. A common kernel-official or whatever package will be created, including all the kernel-latest or whatever fixes, and base-installer will exclusively install those packages (altough at lower priority it could propose to bypass them or something), since this is needed to make abi-breaking arches kernel security uploads transparent to the user doing an apt-get upgrade. Ok, this is my proposal, i am waiting for feedback, and i hope those that put me in your blacklist would reconsider and still follow up on this proposal. One of the things not mentioned was ABI stuff. I implemented an ABI-check-during-build for ubuntu, but I don't feel that's a long term solution; really, I don't care for our current ABI handling at all. I don't want to deal w/ package renames, nor do I want to deal w/ toolchain breakage fucking our ABI, and other misc things that might happen. I had intended to brainstorm w/ fabbione and other people at the next ubuntu conference regarding this, but I'll mention my thoughts now, as well. We can assume, if the user is keeping up on kernel upgrades, that they either have a kernel build environment installed, or have a central machine that does builds for them. If they're not keeping up on kernel upgrades.. Well, they should be, unless they're completely disconnected from the internet or something. There is always some manual work involved during an ABI-changing upgrade; every upgrade means a rebuild of third party modules on some machine. My idea is to do away w/ ABI considerations, and instead compile modules in the kernel's postinst. This would happen for every kernel upgrade, iff there are third party modules registered w/ the system. The way this might look is: - hostap-source installs /usr/src/modules/hostap.tar.bz2, and depends upon gcc, make, bzip2, and module-assistant. - kernel-image-2.6.10-686 (pre-?)depends upon kernel-headers-2.6.10-686. - During k-i-2.6.10-686's preinst, for each module tarball in /usr/src/modules, untar and build using module-assistant. If any build fails, abort the upgrade/install. If all builds succeed, proceed with the upgrade/install - During k-i-2.6.10-686's postinst, for each module tarball in /usr/src/modules, install the appropriate module package (built in preinst). A pre-dependency on kernel-headers doesn't seem to guarantee that gcc, module-assistant, or any of the module-source packages are in a usable state. Currently nothing depends on kernel-images, so re-running the dist-upgrade should be enough to fix this case without hitting nasty dep loops, but even that seems much more awkward than I'd like. Is it your intention that in such a system, the core kernel-image packages would no longer declare abinames at all? That would mean either gratuitous recompiles on every revision of a kernel-image package, which is slightly irritating; or failing to provide a smooth downgrade path in the event of an ABI change that coincides with a silently broken module, which is truly ugly. The idea of automatically recompiling modules sounds good to me, but I still think it needs to be coupled with kernel ABI tracking to avoid the risk of slagging the user's initrd. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#301188: initrd-tools: tries to install module qla6322 which is missing in kernel 2.6.11.x
Package: initrd-tools Version: 0.1.77 Severity: important Hello, the driver for the QLogic adapter 6322 is now merged with qla6312 and mkinitrd failes to run with kernels = 2.6.11 because it still tries to find the qla6322 module. BTW, generally it would be better not to bail out with an error if a module is missing. A nice warning would be good enough. Regards, Torsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298927: Testers wanted for kernel/discover1
On Thursday 24 March 2005 05:51, Jurij Smakov wrote: We have a couple of pretty important bugfixes, which I would like to see tested as soon (and as much) as possible. Those are: * Modular IDE in kernel 2.4.27. That change potentially may affect all sparc machines with IDE controllers I've tested this kernel on my Ultra 10 which has the CMD64x controller. I still get the errors on boot: kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx kernel: CMD646: IDE controller at PCI slot 01:03.0 kernel: CMD646: chipset revision 3 kernel: CMD646: chipset revision 0x03, MultiWord DMA Force Limited kernel: CMD646: 100%% native mode on irq 4,7e0 kernel: ide0: BM-DMA at 0x1fe02c00020-0x1fe02c00027, BIOS settings: hda:pio, hdb:pio kernel: ide1: BM-DMA at 0x1fe02c00028-0x1fe02c0002f, BIOS settings: hdc:pio, hdd:pio kernel: hda: ST34342A, ATA DISK drive kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx kernel: hdc: CD-ROM 56X/AKH, ATAPI CD/DVD-ROM drive kernel: ide0 at 0x1fe02c0-0x1fe02c7,0x1fe02ca on irq 4,7e0 kernel: ide1 at 0x1fe02c00010-0x1fe02c00017,0x1fe02c0001a on irq 4,7e0 (shared with ide0) kernel: Partition check: kernel: hda:end_request: I/O error, dev 03:00 (hda), sector 0 kernel: end_request: I/O error, dev 03:00 (hda), sector 2 kernel: end_request: I/O error, dev 03:00 (hda), sector 4 kernel: end_request: I/O error, dev 03:00 (hda), sector 6 kernel: end_request: I/O error, dev 03:00 (hda), sector 8 kernel: end_request: I/O error, dev 03:00 (hda), sector 10 kernel: end_request: I/O error, dev 03:00 (hda), sector 12 kernel: end_request: I/O error, dev 03:00 (hda), sector 14 kernel: end_request: I/O error, dev 03:00 (hda), sector 0 kernel: end_request: I/O error, dev 03:00 (hda), sector 2 kernel: end_request: I/O error, dev 03:00 (hda), sector 4 kernel: end_request: I/O error, dev 03:00 (hda), sector 6 kernel: end_request: I/O error, dev 03:00 (hda), sector 8 kernel: end_request: I/O error, dev 03:00 (hda), sector 10 kernel: end_request: I/O error, dev 03:00 (hda), sector 12 kernel: end_request: I/O error, dev 03:00 (hda), sector 14 kernel: unable to read partition table (and of course the unimplemented Sparc system call 188) However, the system boots fine and as the kernel.log is written without errors, I'm not sure if these errors can safely be ignored or are still an indication that something may fail horribly later... I never really tested older 2.4.27 kernels beyond seeing these messages, so I'm not sure is anything has actually changed. 'fdisk -l /dev/hda' returns the correct output. Cheers, FJP pgpRql62yhaCi.pgp Description: PGP signature
Bug#100421: haven't heard from you in a while! ;)
there, I have to show you this It's basically a date site that you don't have to pay for. There are many guys, girls, couples, and I'm sure something for you. Just so you know, alot of them are just looking for a one-night stand, or fuckfriend as they call it. So yeah, you can either find one-nighter, or someone you can fall in love with. Whatever you want, pretty much :) http://www.just1night.com/d2/ 'nuff? http://www.just1night.com/rmv/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
Frank Lichtenheld wrote: Hi all. As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. JFTR, all mips/mipsel subarchitectures are also affected. For those, however, the sarge kernel without userland backports is good enough, because modules aren't needed for basic system operation. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
Hi, at this moment I am testing the Debian Installer on a SS5 (sun4m I thougt) cause I wanted a newer kernel then 2.2.20. but it isn't working very well I am willing to test this upgrade-kernel to get a beter kernel and be able to do a woody-sarge upgrade I think I will start with it right afther I finished my test with the debian installer and filled in a report I hope I will be able to help :) Greetings Robin Harmsen [EMAIL PROTECTED] http://www.rharmsen.nl - Original Message - From: Frank Lichtenheld [EMAIL PROTECTED] To: debian-release@lists.debian.org; debian-hppa@lists.debian.org; debian-sparc@lists.debian.org Cc: [EMAIL PROTECTED] Sent: Thursday, March 24, 2005 2:31 PM Subject: RFC and status report: Kernel upgrades for woody-sarge upgrades Hi all. As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. Because of the pain to maintain a kernel backport over the lifetime of sarge we have decided to only offer backports of the needed tools (modutils, module-init-tools and initrd-tools) to use stock sarge kernels on woody. It is planned to upload these files together with some documentation into a upgrade-kernel (or whatever else name the ftpmasters will prefer) directory in the archive. I've prepared the necessary backports and some rudimentary documentation and put it online at http://higgs.djpig.de/upgrade/upgrade-kernel/ We now need people that - test the backports - read/comment on/improve the documentation Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
On Thu, Mar 24, 2005 at 02:31:55PM +0100, Frank Lichtenheld wrote: As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. It's all hppa machines, not just hppa64. I've prepared the necessary backports and some rudimentary documentation and put it online at http://higgs.djpig.de/upgrade/upgrade-kernel/ I'll give it a try now. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#298136: kernel-image-2.4.27-2-smp: aieee with isp1020
Processing commands for [EMAIL PROTECTED]: reassign 298136 kernel-image-2.4.27-alpha Bug#298136: kernel-image-2.4.27-2-smp: aieee with isp1020 Bug reassigned from package `kernel-image-2.4.27-2-smp' to `kernel-image-2.4.27-alpha'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: CAN-2005-0531: Buffer overflow in atm_get_addr
Processing commands for [EMAIL PROTECTED]: tag 296905 +pending Bug#296905: CAN-2005-0531: Buffer overflow in atm_get_addr Tags were: security Tags added: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298136: kernel-image-2.4.27-2-smp: aieee with isp1020
reassign 298136 kernel-image-2.4.27-alpha thanks On Fri, Mar 04, 2005 at 11:55:15PM +0100, Adrian Zaugg wrote: Package: kernel-image-2.4.27-2-smp Version: 2.4.27-7 Severity: normal I did a bit of searching on google, seems that there might be an old bug in there. I am reasigning the bug to kernel-image-2.4.27-alpha as it seems to be alpha specific. That is, all other similar reports seem to also be on alpha. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
Hi Matthew, On Thursday, 24 Mar 2005, you wrote: On Thu, Mar 24, 2005 at 02:31:55PM +0100, Frank Lichtenheld wrote: As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. It's all hppa machines, not just hppa64. IIRC we did some upgrade tests on hppa(32) at the BSP in Frankfurt in November last year and had no problems with that, but i might be wrong. Frank, could you please confirm this, as i recall you and Uli did these tests Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#100421: Order Pending
Hi, Delivered right to your door. We have a large variety of all meds. DHL Package tracking. We have the lowest prices anywhere, guaranteed! regotune.info Thanks Alot, Samantha Brown blue mango yellow watermellon Until that day, he could not hear the language differences. He asked for the computer every day by pointing to it. He was allowed to spend time each day on the noun program. One year later he was talking in full sentences and was staffed into normal preschool.. tomorrow i will wash my hair and go to the salon. But, I spent the next three weeks making a piece of simple software for her son to her specifications. While I was at it, I put 4-8 pictures on the screen as well. The simple program was finished and ready for her child to see. As I was presenting it, the other children in my classroom were pushing each other to get to the computer screen to touch that Touch Window and hear the word spoken again and again. I looked at these kids and was amazed. There was no music, no animation, nothing cute about this program at all, just real pictures with real words. I was stunned. I just watched the children. Within 10 minutes, several children who had never said a word in their life, made approximations of several words. I was hooked.. I didn't hate dancing last night at eleven..
Bug#120116: Recurring Payment Pending
Good day, Delivered right to your door. We have a large variety of all meds. DHL Package tracking. We have the lowest prices anywhere, guaranteed! regotune.info Best Regards, Miguel Faris red watermellon brown watermellon Were those farmers practicing shouting next to the police station?. Was Michael enjoying running early last month?. Did Alfred's niece like playing well?. Those bus drivers aren't missing praying on the street just now..
Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
Andres Salomon wrote: Cons: - Does not address issues with d-i udebs and abi changes at all. - It becomes impossible to include third-party modules in d-i, since we have no precompiled modules for them anymore. -- see shy jo signature.asc Description: Digital signature
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
I installed a minimal basic stable installation of Debian (no packages selected with tasksel or dselect) when doing the upgade as stated on http://higgs.djpig.de/upgrade/upgrade-kernel/ via the dpkg method. I first needed to install zlib1g, ash and stat. maby it is better to mention that those need to be installed prior. and there is no mentioning of what to change in silo.conf cause you need to specify the initrd somehow. I added: initrd=1/initrd.img is this correct? afther rebooting I get the following error(s): modprobe: Noting to load ??? Specify at least a module or a wildcard like \* pivot_root: No such file or directory /sbin/init: cannot open dev/console: no such file Kernel panic: Attempted to kill init! - Original Message - From: Frank Lichtenheld [EMAIL PROTECTED] To: debian-release@lists.debian.org; debian-hppa@lists.debian.org; debian-sparc@lists.debian.org Cc: [EMAIL PROTECTED] Sent: Thursday, March 24, 2005 2:31 PM Subject: RFC and status report: Kernel upgrades for woody-sarge upgrades Hi all. As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. Because of the pain to maintain a kernel backport over the lifetime of sarge we have decided to only offer backports of the needed tools (modutils, module-init-tools and initrd-tools) to use stock sarge kernels on woody. It is planned to upload these files together with some documentation into a upgrade-kernel (or whatever else name the ftpmasters will prefer) directory in the archive. I've prepared the necessary backports and some rudimentary documentation and put it online at http://higgs.djpig.de/upgrade/upgrade-kernel/ We now need people that - test the backports - read/comment on/improve the documentation Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
On Thu, Mar 24, 2005 at 04:31:24AM -0500, Andres Salomon wrote: The way that arch/subarch specific patches are handled needs to be thought out. There are architectures that are close to linus kernels, and there are those that aren't. The preferred way to do things is to have something similar to what k-s does now; all patches (whether arch-specific or not) are applied. Of course, when arch-specific patches end up being megabytes in size, and conflict w/ each other, I realize that we need another layer on top of that; patches that are only applied to k-s when building for a certain arch. This does add complexity, though. I'd like to avoid that, if possible. If that means working really hard to get upstream to sync up w/ arch-specific stuff, so be it (really, that seems like a better long term solution then to add infrastructure to allow more and more source drift away from linus' kernels for each arch). I've been working on that for parisc -- got around 6-700k of patches into Linus' tree. Of course, that benefit is only felt by Debian after 2.6.12 is released. There's some stuff in the parisc patch that could break other architectures -- only in 64 bit mode (it's part of the compat layer), but I'm sure ppc64 doesn't want to be broken by a parisc patch. Now, I've certainly tried to *not* break other architectures (I personally use the parisc kernels on i386 and ia64 machines), but no promises that I haven't, and Debian doesn't want to be the ones debugging this. So I think we do need to have per-arch patches. -- Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ...
Otavio Salvador wrote: || On Thu, 24 Mar 2005 12:05:05 -0500 || Joey Hess [EMAIL PROTECTED] wrote: jh Andres Salomon wrote: Cons: jh - Does not address issues with d-i udebs and abi changes at all. jh - It becomes impossible to include third-party modules in d-i, since we jh have no precompiled modules for them anymore. I think the udebs won't be build from kernel-source directly. The udebs should be build using the kernel-wedge like now. But it can be all did together and will be faster then the current way. Suppose that sarge releases and you buy a copy of the official sarge businesscard CD image for your wallet. Or you burn a set of floppies. Now a security fix comes out, the kernel ABI is changed, and you try to install using your old official sarge installation media. At this point, with or without Andres's plan, you'll get a message that the installer was unable to find any kernel module udebs matching it kernel on the debian mirror. Although, with Andres's plan, we don't even track ABIs anymore, so perhaps the installer won't even be able to tell that the new udebs will not work with it, and will just fail horribly later on instead of displaying the error message. -- see shy jo signature.asc Description: Digital signature
Re: a kernel plan for sarge and beyond ...
On Thu, 24 Mar 2005 13:32:43 -0500, Joey Hess wrote: Otavio Salvador wrote: || On Thu, 24 Mar 2005 12:05:05 -0500 || Joey Hess [EMAIL PROTECTED] wrote: jh Andres Salomon wrote: Cons: jh - Does not address issues with d-i udebs and abi changes at all. jh - It becomes impossible to include third-party modules in d-i, since we jh have no precompiled modules for them anymore. I think the udebs won't be build from kernel-source directly. The udebs should be build using the kernel-wedge like now. But it can be all did together and will be faster then the current way. Suppose that sarge releases and you buy a copy of the official sarge businesscard CD image for your wallet. Or you burn a set of floppies. Now a security fix comes out, the kernel ABI is changed, and you try to install using your old official sarge installation media. At this point, with or without Andres's plan, you'll get a message that the installer was unable to find any kernel module udebs matching it kernel on the debian mirror. Although, with Andres's plan, we don't even track ABIs anymore, so perhaps the installer won't even be able to tell that the new udebs will not work with it, and will just fail horribly later on instead of displaying the error message. Right. My suggestion doesn't address d-i issues. We have two options, it seems; the modules that are downloaded from a debian mirror can either be versioned to support multiple ABIs (either by package name, or by including multiple versions of modules in the package), or by downloading module source along w/ a compiler, and building them during install. Steve expressed concern about doing something like that (for obvious reasons); however, something to consider is using tcc for building modules. I have not tried it yet, but one of its touted features is its ability to compile a kernel in 10 seconds on a 2.4ghz p4. The i386 package appears to be about 100k. I'm not sure if it's been ported to !i386. More research into that would need to be done, if the d-i folks found that to be an acceptable solution. I really don't see any other options available to us, as long as we're requiring d-i images to download kernel modules from a mirror. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ...
Andres Salomon wrote: [snip] Steve expressed concern about doing something like that (for obvious reasons); however, something to consider is using tcc for building modules. I have not tried it yet, but one of its touted features is its ability to compile a kernel in 10 seconds on a 2.4ghz p4. The i386 package appears to be about 100k. I'm not sure if it's been ported to !i386. More research into that would need to be done, if the d-i folks found that to be an acceptable solution. The last time I looked it was i386 only. And anyways, using a different compiler is hardly a guarantee for stability. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ...
|| On Thu, 24 Mar 2005 13:32:43 -0500 || Joey Hess [EMAIL PROTECTED] wrote: jh Otavio Salvador wrote: || On Thu, 24 Mar 2005 12:05:05 -0500 || Joey Hess [EMAIL PROTECTED] wrote: jh Andres Salomon wrote: Cons: jh - Does not address issues with d-i udebs and abi changes at all. jh - It becomes impossible to include third-party modules in d-i, since we jh have no precompiled modules for them anymore. I think the udebs won't be build from kernel-source directly. The udebs should be build using the kernel-wedge like now. But it can be all did together and will be faster then the current way. jh Suppose that sarge releases and you buy a copy of the official sarge jh businesscard CD image for your wallet. Or you burn a set of floppies. jh Now a security fix comes out, the kernel ABI is changed, and you try to jh install using your old official sarge installation media. At this point, jh with or without Andres's plan, you'll get a message that the installer jh was unable to find any kernel module udebs matching it kernel on the jh debian mirror. Will work if you use a meta-package in base-installer for it, don't will? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
On Thu, Mar 24, 2005 at 01:54:38PM +, Matthew Wilcox wrote: On Thu, Mar 24, 2005 at 02:31:55PM +0100, Frank Lichtenheld wrote: As many of you may know on some machines users will need to install a current kernel before they will be able to upgrade woody to sarge (or better: glibc of woody to glibc of sarge). I've tried to use the available information to provide the needed files for these kernel upgrades. To my knowledge the affected machines/architecures are currently hppa64, sparc sun4m (only some of them) and 80386. It's all hppa machines, not just hppa64. Then why does the libc6 preinst say that the minimum kernel is 2.4.17 for parisc, and 2.4.19 for parisc64? If this is an error, it will need to be reconciled before release. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
On Thu, Mar 24, 2005 at 02:57:35PM +0100, Robin Harmsen wrote: at this moment I am testing the Debian Installer on a SS5 (sun4m I thougt) cause I wanted a newer kernel then 2.2.20. but it isn't working very well I am willing to test this upgrade-kernel to get a beter kernel and be able to do a woody-sarge upgrade I think I will start with it right afther I finished my test with the debian installer and filled in a report I hope I will be able to help :) To the best of our knowledge, the SS5 is not one of the systems affected by this upgrade issue; only systems using the Cypress chips are known to be affected. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: a kernel plan for sarge and beyond ...
Andres Salomon wrote: Right. My suggestion doesn't address d-i issues. We have two options, it seems; the modules that are downloaded from a debian mirror can either be versioned to support multiple ABIs (either by package name, or by including multiple versions of modules in the package) This still requires tracking ABIs. As far as I can understand, your suggestion was to give up on tracking kernel ABI changes between any two uploads of the kernel. downloading module source along w/ a compiler, and building them during install. Some third party modules may be necessary for things like disk drive support or ethernet support. Before these are available, d-i has only an initrd available; d-i already brely fits on lower memory machines (32 mb or so); I hope you're not suggesting we run gcc there. Even a minimal compiler seems like quite a stretch, even assuming it would work. -- see shy jo signature.asc Description: Digital signature
Re: a kernel plan for sarge and beyond ...
Joey Hess wrote: Suppose that sarge releases and you buy a copy of the official sarge businesscard CD image for your wallet. Or you burn a set of floppies. Correction: businesscard does not have this problem; only installs from floppy and netboot (and netboot mini-iso) does. -- see shy jo signature.asc Description: Digital signature
Re: a kernel plan for sarge and beyond ...
Otavio Salvador wrote: Will work if you use a meta-package in base-installer for it, don't will? I'm talking about ABI mersion mismatches between installer initrds and kernel udebs, not in kernel debs. -- see shy jo signature.asc Description: Digital signature
Bug#241497: RFC and status report: Kernel upgrades for woody-sarge upgrades
Actualy the SS5 (at least the one I have got here) does have the problem for libc6 version I need a kernel above 2.4.21, and for that kernel I need that libc6 version. - Original Message - From: Steve Langasek [EMAIL PROTECTED] To: debian-release@lists.debian.org; debian-sparc@lists.debian.org Cc: [EMAIL PROTECTED] Sent: Thursday, March 24, 2005 11:44 PM Subject: Re: RFC and status report: Kernel upgrades for woody-sarge upgrades -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sarge kernel security transition
The ABI/security discussions have left me with a question - at what point does security maintenance of our kernels transition from the debian-kernel/testing security teams to the Debian security team, and how will we interact with one another? I assume there will be some overlap, but it might be good to define this transition before it happens. Source Control == I assume at some point we'll want to branch off our 2.4.27/2.6.8 kernels and lock them down for only security changes. I think it would be nice to keep our svn repo up to date with the security releases, even if it is an after-the-fact svn_load_dirs dump. I assume this would fall to the kernel team to maintain, if we choose to do so (versus the security team doing the committing). Sarge package vs. latest packages = When the first security update happens, will the uploaders start with whatever is in sarge, or the latest version? When sarge happens, its likely there will be pending changes in kernel-source in svn, and maybe in sid. Its also possible that some kernel-image re-builds may not have propagated into sarge yet. The changes here should be mostly security fixes at this point; however we've not formally frozen these packages to my knowledge, so this isn't guaranteed. Maybe now is the time to do that? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
On Thu, Mar 24, 2005 at 03:30:01PM -0500, Andres Salomon wrote: (ignoring -release followup-to, since it affects -kernel and -boot as well) Sorry, mailer misfire, I guess. On Thu, 24 Mar 2005 03:24:53 -0800, Steve Langasek wrote: recompiles on every revision of a kernel-image package, which is slightly irritating; or failing to provide a smooth downgrade path in the event of an That is irritating, but less so than rebooting and discovering you need to run `module-assistant auto-install foo` to compile a module for an ABI change (and if the machine requires the third party module to boot and get online, fun ensues). That said, if we could get a solution to long NEW processing times, then doing both in tandem (ABINAMEs + recompile hooks upon ABI and major kernel upgrades) is a possibility. I don't believe long NEW processing times are seriously an issue here; the ftp team is very responsive to needs for quick processing of release-relevant kernel packages. The problem, AFAICT, is that it currently takes so many *iterations* of NEW processing to get everything updated for a kernel ABI change, including kernel-image packages for 11 architectures that arrive in NEW over a span of weeks, plus whatever module binary packages there are. ABI change that coincides with a silently broken module, which is truly ugly. The idea of automatically recompiling modules sounds good to me, but I still think it needs to be coupled with kernel ABI tracking to avoid the risk of slagging the user's initrd. How would the initrd get slagged? It would need to be regenerated, of course, during the upgrade to pull in newly built modules. Any time you rebuild your kernel binary modules, there's a non-zero chance that the rebuilt version will not work correctly even though it built successfully. If you aren't going to track ABI changes, then you have no backup kernel to use in this case (because you've overwritten the old one with a binary-incompatible one) that would let you roll back the change in the event that one of the modules that broke rendered your system unbootable. It's a standard part of my system administration practices to keep a previous kernel version around that I can roll back to when upgrading to a new version; this approach would seem to make that more awkward. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
kernel-image-2.6.8-ia64 ABI reversion
I'm trying to decide what I want to do about the ia64 kernel ABI. I rev'd it from -2 (currently in sarge) to -3 to turn off PREEMPT (prevents at least one user triggerable oops). This seemed convenient, since the k-s-2.6.8-14 had its own ABI change. Well, turns out this was a bad idea - we've decided to revert the ABI change from the kernel-source, and the ia64 images are blocked from sarge because of it. Is it feasible (or even a good idea) to revert this ABI change? The only problem I can come up with is that sid systems that installed the -2 ABI version and the -3 ABI version won't use -2 as a default kernel after the upgrade. That seems acceptable since after all, this is sid, and once we do the pending ABI roll, it will be -3 once again. And, I'd like for sarge users to be able to test new uploads. (Sorry for the broad distribution, but I want to be sure to get this right). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2.4.27-9
I have finally finished wading through the bug reports and put togther kernel-source-2.4.27 2.4.27-9 and kernel-image-2.4.27-i386 2.4.27-9. This update does _NOT_ contain ABI breakage, although one symbol has been added to the ABI. That is, the fix for CAN-2005-0449 has been omitted. I am currently doing the final builds and intend to tag and upload these later today, or tomorrow at the latest. If you have feedback, now would be an excellent time to make it known. If anyone wants to test these packages, or kick off some builds, I have made the kernel-source packages available at the URL below. I will add the i386 kernel-image packages as soon as they finish building (which takes an hour or so). http://debian.vergenet.net/pending/ The changelogs are below. -- Horms kernel-image-2.4.27-i386 (2.4.27-9) unstable; urgency=low * Remove one more file in clean target. (Josh Kwan) * Build against 2.4.27-kernel-tree-2.4.27-9. (Simon Horman) * Fix up AMD descriptions to include CPU name. Thanks to J. Grant. (Simon Horman) -- Simon Horman [EMAIL PROTECTED] Fri, 25 Mar 2005 11:19:31 +0900 kernel-source-2.4.27 (2.4.27-9) unstable; urgency=low * There was a stray file in 2.4.27-8. Don't include it this time. (Simon Horman) (closes: Bug#291536) * Updated kernel-tree description from Martin F Krafft (Simon Horman) * Updated apply script so it can handle point versions (Simon Horman) * 134_skb_reset_ip_summed.diff: [CAN-2005-0209] resolve checksumming exploit in fragmented packet forwarding (Joshua Kwan) * 135_fix_ip_options_leak.diff: [CAN-2004-1335] fix leak of IP options data. (Joshua Kwan) * 136_vc_resizing_overflow.diff: [CAN-2004-1333] make sure VC resizing fits in 16 bits. (Joshua Kwan) * 137_io_edgeport_overflow.diff: [CAN-2004-1017] fix buffer overflow (underflow, really) that opens multiple attack vectors. (Joshua Kwan) * 138_amd64_syscall_vuln.diff: [CAN-2004-1144] fix the int 0x80 hole that allowed overflow of the system call table. (Joshua Kwan) * 139_sparc_context_switch.diff: fix FPU context switching dirtiness on sparc32 SMP. (Joshua Kwan) * 140_VM_IO.diff: [CAN-2004-1057] fix possible DoS from accessing freed kernel pages by flagging VM_IO where necessary. * 141_acpi_noirq.patch: [ACPI] Enhanced PCI probe, CONFIG_HPET_TIMER build warning fix (Simon Horman) * 142_acpi_skip_timer_override-1.diff, 142_acpi_skip_timer_override-2.diff, 142_acpi_skip_timer_override-3.diff, 142_acpi_skip_timer_override-4.diff: [ACPI] skip_timer_override including early PCI bridge detection. (closes: #296639) (Simon Horman) * 121_drm-locking-checks-3.diff: LOCK_TEST_WITH_RETURN build cleanup (Simon Horman) * 143_outs.diff: [SECURITY]: AMD64, allows local users to write to privileged IO ports via OUTS instruction (CAN-2005-0204) (Simon Horman) (closes: #296700) * 144_sparc64-sb1500-clock-2.4.diff by David Miller: enable recognition of the clock chip on SunBlade 1500, it won't boot otherwise. (Jurij Smakov). * 145_insert_vm_struct-no-BUG.patch: [SECURITY] make insert_vm_struct return an error rather than BUG(). See CAN-2005-0003. (dann frazier) * 146_ip6_copy_metadata_leak.diff 147_ip_copy_metadata_leak.diff: [SECURITY] Do not leak dst entries in ip_copy_metadata() See CAN-2005-0210. (Simon Horman) * 148_ip_evitor_smp_loop.diff: Fix theoretical loop on SMP in ip_evictor(). (Simon Horman, Andres Salomon) * 149_fragment_queue_flush.diff: Flush fragment queue on conntrack unload. (Simon Horman, Andres Salomon) * *** ABI Change! Notify D-I team or delay for future release *** Omitted from release *** 150_private_fragment_queues-1.diff, 150_private_fragment_queues-2.diff: *** Keep fragment queues private to each user. See CAN-2005-0449 and *** http://oss.sgi.com/archives/netdev/2005-01/msg01048.html *** (Simon Horman, Andres Salomon) * 151_atm_get_addr_signedness_fix.diff: [SECURITY] Fix ATM copy-to-user usage. See: CAN-2005-0531. See: http://www.guninski.com/where_do_you_want_billg_to_go_today_3.html (closes: #296905) (Simon Horman) * 153_ppp_async_dos.diff: [SECURITY] remote Linux DoS on ppp servers. See: CAN-2005-0384 (Simon Horman) * 111-smb-client-overflow-fix-2.diff, 111-smb-client-overflow-fix-1.diff: [SECURITY] The above patches, included in 2.4.27-6 resolve: local information leak caused by race in SMP systems with more than 4GB of memory. remote information leak cansed by handling of TRANS2 packets handling in smbfs. See CAN-2004-1191. (see: #300163) (Simon Horman) * 154_cmsg_compat_signedness_fix.diff: Fix CMSG32_OK macros. (Dann Frazier, Simon Horman) -- Simon Horman [EMAIL PROTECTED] Fri, 25 Mar 2005 10:42:50 +0900 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.6.8-ia64 ABI reversion
On Thu, Mar 24, 2005 at 06:22:32PM -0700, dann frazier wrote: I'm trying to decide what I want to do about the ia64 kernel ABI. I rev'd it from -2 (currently in sarge) to -3 to turn off PREEMPT (prevents at least one user triggerable oops). This seemed convenient, since the k-s-2.6.8-14 had its own ABI change. Well, turns out this was a bad idea - we've decided to revert the ABI change from the kernel-source, and the ia64 images are blocked from sarge because of it. Is it feasible (or even a good idea) to revert this ABI change? The only problem I can come up with is that sid systems that installed the -2 ABI version and the -3 ABI version won't use -2 as a default kernel after the upgrade. That seems acceptable since after all, this is sid, and once we do the pending ABI roll, it will be -3 once again. And, I'd like for sarge users to be able to test new uploads. We want to keep any of these kernel updates from reaching testing before sarge release, unless there's agreement that we should do a full update (including revision of the d-i kernel udebs). Kernels also aren't affected by the autobuilder problems with t-p-u right now, so that option is open for anything that does need to be uploaded for sarge. I'd say there's no reason not to play with longshot-for-sarge kernel changes in unstable. Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: a kernel plan for sarge and beyond ... (Was Re: ABI-changing kernel security fixes for sarge)
On Thu, 24 Mar 2005 17:02:29 -0800, Steve Langasek wrote: On Thu, Mar 24, 2005 at 03:30:01PM -0500, Andres Salomon wrote: (ignoring -release followup-to, since it affects -kernel and -boot as well) Sorry, mailer misfire, I guess. On Thu, 24 Mar 2005 03:24:53 -0800, Steve Langasek wrote: recompiles on every revision of a kernel-image package, which is slightly irritating; or failing to provide a smooth downgrade path in the event of an That is irritating, but less so than rebooting and discovering you need to run `module-assistant auto-install foo` to compile a module for an ABI change (and if the machine requires the third party module to boot and get online, fun ensues). That said, if we could get a solution to long NEW processing times, then doing both in tandem (ABINAMEs + recompile hooks upon ABI and major kernel upgrades) is a possibility. I don't believe long NEW processing times are seriously an issue here; the ftp team is very responsive to needs for quick processing of release-relevant kernel packages. The problem, AFAICT, is that it currently takes so many *iterations* of NEW processing to get everything updated for a kernel ABI change, including kernel-image packages for 11 architectures that arrive in NEW over a span of weeks, plus whatever module binary packages there are. Release-relevant kernels are not the only kernels we (the kernel team) care about. I uploaded kernel-image-2.6.10-sparc a week ago. For a normal package, a long wait is fine (I have ruby libraries that have been in NEW for 2 months, but I'm not in any sort of rush). However, for kernel updates, a long wait is not fine. New kernels fix numerous bugs, security holes, etc. By leaving them rotting in NEW, we do a disservice to our users using unstable. And, quite frankly, it's annoying having to *constantly* work around NEW. Oh, well, let's fix this and this, and not this; build and upload; then fix this other thing, bump the ABINAME, and upload. I have come to despise NEW, since joining the kernel team. ABI change that coincides with a silently broken module, which is truly ugly. The idea of automatically recompiling modules sounds good to me, but I still think it needs to be coupled with kernel ABI tracking to avoid the risk of slagging the user's initrd. How would the initrd get slagged? It would need to be regenerated, of course, during the upgrade to pull in newly built modules. Any time you rebuild your kernel binary modules, there's a non-zero chance that the rebuilt version will not work correctly even though it built successfully. If you aren't going to track ABI changes, then you have no backup kernel to use in this case (because you've overwritten the old one with a binary-incompatible one) that would let you roll back the change in the event that one of the modules that broke rendered your system unbootable. Non-ABI changing upgrades don't allow this anyways, and they're the most common scenario. I've never seen an i386 kernel's ABINAME go past -2. Older kernels would still function perfectly well as backup kernels, as well. If something in 2.6.11 breaks during an upgrade, boot into 2.6.10 and fix it. It's a standard part of my system administration practices to keep a previous kernel version around that I can roll back to when upgrading to a new version; this approach would seem to make that more awkward. I'd argue that our current practice of tracking ABIs has done more damage, by allowing ABI changes to slip through, breaking already built modules, as well as assuming the user wants to boot into the latest kernel without handling their third party modules automatically. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ...
On Thu, 24 Mar 2005 18:36:52 -0500, Joey Hess wrote: Andres Salomon wrote: Right. My suggestion doesn't address d-i issues. We have two options, it seems; the modules that are downloaded from a debian mirror can either be versioned to support multiple ABIs (either by package name, or by including multiple versions of modules in the package) This still requires tracking ABIs. As far as I can understand, your suggestion was to give up on tracking kernel ABI changes between any two uploads of the kernel. That's correct; this option is the one I'd rather not pursue, if possible. downloading module source along w/ a compiler, and building them during install. Some third party modules may be necessary for things like disk drive support or ethernet support. Before these are available, d-i has only an initrd available; d-i already brely fits on lower memory machines (32 mb or so); I hope you're not suggesting we run gcc there. Even a minimal compiler seems like quite a stretch, even assuming it would work. Wishful thinking on my part, I guess. A minimal compiler would still require kernel-headers, which would take up a significant amount of space (25MB for 2.6.10). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.6.8-ia64 ABI reversion
On Thu, 2005-03-24 at 19:37 -0800, Steve Langasek wrote: On Thu, Mar 24, 2005 at 06:22:32PM -0700, dann frazier wrote: I'm trying to decide what I want to do about the ia64 kernel ABI. I rev'd it from -2 (currently in sarge) to -3 to turn off PREEMPT (prevents at least one user triggerable oops). This seemed convenient, since the k-s-2.6.8-14 had its own ABI change. Well, turns out this was a bad idea - we've decided to revert the ABI change from the kernel-source, and the ia64 images are blocked from sarge because of it. Is it feasible (or even a good idea) to revert this ABI change? The only problem I can come up with is that sid systems that installed the -2 ABI version and the -3 ABI version won't use -2 as a default kernel after the upgrade. That seems acceptable since after all, this is sid, and once we do the pending ABI roll, it will be -3 once again. And, I'd like for sarge users to be able to test new uploads. We want to keep any of these kernel updates from reaching testing before sarge release, unless there's agreement that we should do a full update (including revision of the d-i kernel udebs). Kernels also aren't affected by the autobuilder problems with t-p-u right now, so that option is open for anything that does need to be uploaded for sarge. I'd say there's no reason not to play with longshot-for-sarge kernel changes in unstable. Thanks Steve. I think this decision makes the outcome of the thread 'sarge kernel security transition' pretty important. It seems to me that the best use of everyone's time would be for the kernel team to have an agreement with the security team that we will restrict changes to our 2.4.27/2.6.8 kernels in such a way that they can start with our unstable packages for sarge updates (with maybe a sarge toolchain rebuild). This way we can keep doing security updates and uploading kernels to sid to get some testing, and if $deity forbid we need to do an rc4, we've got new bits prepared for that as well. There's no reason for us to be working w/ these kernel revs if our changes aren't going to make it into sarge. Security Team: is there a set of rules for our changes that would make a transition like this work? -- dann frazier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge kernel security transition
dann frazier wrote: The ABI/security discussions have left me with a question - at what point does security maintenance of our kernels transition from the debian-kernel/testing security teams to the Debian security team, and how will we interact with one another? I assume there will be some overlap, but it might be good to define this transition before it happens. When security.debian.org has to be used the security team needs to be in the loop. We need to work together with the kernel maintainers, though. I believe that this is even more important for the kernel than for other packages. Source Control == I assume at some point we'll want to branch off our 2.4.27/2.6.8 kernels and lock them down for only security changes. I think it would be nice to keep our svn repo up to date with the security releases, even if it is an after-the-fact svn_load_dirs dump. I assume this would fall to the kernel team to maintain, if we choose to do so (versus the security team doing the committing). That should be doable. Sarge package vs. latest packages = When the first security update happens, will the uploaders start with whatever is in sarge, or the latest version? Regular security updates always take care of the version that was released with the released/frozen Debian distribution. When the kernel is frozen, that package should probably be used. Until that, a more recent version can be used as basis, I guess, to be judged by the kernel team. Updates to the once-released distributions will be based on the latest version in that particular distribution (here: woody, sarge). When sarge happens, its likely there will be pending changes in kernel-source in svn, and maybe in sid. Its also possible that some kernel-image re-builds may not have propagated into sarge yet. The changes here should be mostly security fixes at this point; however we've not formally frozen these packages to my knowledge, so this isn't guaranteed. Maybe now is the time to do that? Ack. Regards, Joey -- The only stupid question is the unasked one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ...
Joey Hess wrote: Suppose that sarge releases and you buy a copy of the official sarge businesscard CD image for your wallet. Or you burn a set of floppies. Now a security fix comes out, the kernel ABI is changed, and you try to install using your old official sarge installation media. At this point, with or without Andres's plan, you'll get a message that the installer was unable to find any kernel module udebs matching it kernel on the debian mirror. Although, with Andres's plan, we don't even track ABIs anymore, so perhaps the installer won't even be able to tell that the new udebs will not work with it, and will just fail horribly later on instead of displaying the error message. How about using a system a la snapshot.debian.net so that downloading module udebs will always be correct for any given installer image? Just throwing out an idea... -- Joshua Kwan signature.asc Description: OpenPGP digital signature
Re: ABI-changing kernel security fixes for sarge
Sven Luther wrote: We'd need at least a list of module packages that we need to recompile when a kernel update changes the ABI and all the modules become void. This also means that we need to be able to rebuild modules from their corresponding source package. Notice that enabling auto-NEW for such abi-changes will speed up this process considerably, but i was told a whinner for even suggesting such, and bashed upon unendlessly. What is auto-NEW? Alos, please find someone else for building the powerpc 2.6.8 and 2.4.27 security updates as i will most certainly not do that anymore. I'd assume that another powerpc kernel developer/maintainer is part of the kernel team then. Otherwise it will be difficult to support powerpc kernels security-wise. Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.6.8-ia64 ABI reversion
On Fri, Mar 25, 2005 at 08:04:30AM +0100, Martin Schulze wrote: I've also been told that many module packages aren't built the Debian way with a .dsc file that can be used as basis for dpkg-buildpackage or similar. This makes the problem more difficult. The kernel module packages we know of that are built in this fashion are being blocked from testing, based on your comments. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: ABI-changing kernel security fixes for sarge
Matthew Wilcox wrote: On Wed, Mar 23, 2005 at 04:09:42PM +0100, Frank Lichtenheld wrote: How big is the chance that we will have another ABI change during sarge's lifetime (100%?). So it can't hurd to figure out the problems with that now independently of our decision in this matter... I'd say the probability is about 99.%, fwiw. Absolutely. It's bound to happen again. We also need to figure out how to do driver updates during sarge's lifetime. I suspect virtually everybody has had the experience of trying to install woody on a new PC. Some of the problems I remember: For this I have suggested to use a semi-official / unofficial repository for the installer and kernels. I agree that there should be some way to support new hardware, but it doesn't have to be in the main archive of ftp.debian.org, imho. Maybe backports.org/d-i/ would be a proper place, maybe not. Either that, or we need to commit to a 6-month release goal for etch and future releases. Which wouldn't suck, we used to do it... We should probably stick to a 6-month release goal anyway and achieve 12-months... Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-image-2.6.8-ia64 ABI reversion
Steve Langasek wrote: On Fri, Mar 25, 2005 at 08:04:30AM +0100, Martin Schulze wrote: I've also been told that many module packages aren't built the Debian way with a .dsc file that can be used as basis for dpkg-buildpackage or similar. This makes the problem more difficult. The kernel module packages we know of that are built in this fashion are being blocked from testing, based on your comments. Thanks. waldi, could you be more specific about which other modules packages aren't built the Debian way in sarge? Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: a kernel plan for sarge and beyond ...
On Thu, Mar 24, 2005 at 02:57:45PM -0300, Otavio Salvador wrote: || On Thu, 24 Mar 2005 12:05:05 -0500 || Joey Hess [EMAIL PROTECTED] wrote: jh Andres Salomon wrote: Cons: jh - Does not address issues with d-i udebs and abi changes at all. jh - It becomes impossible to include third-party modules in d-i, since we jh have no precompiled modules for them anymore. I think the udebs won't be build from kernel-source directly. The udebs should be build using the kernel-wedge like now. But it can be all did together and will be faster then the current way. My idea was to build them all together, one per arch. I am not fully sure what the situation is though, and was told that they did break the package handling thingy, but i think this was when all arches where built from a single source. The way the ubuntu kernels works is to invoke kernel-wedge during the arch build stuff, so i believe that this will only be the normal assortiment of kernel packages (10 or so), plus the exact content of one .udeb generating kernel package, which i don't think causes a problem. My plan is to experiment for that with the 2.6.11 kernels, and if it works well enough and in enough time, replicate the same stuff for 2.6.8 packages in experimental, so that if later on we decide for a d-i rebuild, we can upload those packages to unstable and do the build easy enough. Won't have time today, i think, but will try to make it happen over the WE. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
