mkvmlinuz 21 MIGRATED to testing
FYI: The status of the mkvmlinuz source package in Debian's testing distribution has changed. Previous version: 20 Current version: 21 -- This email is automatically generated; [EMAIL PROTECTED] is responsible. See http://people.debian.org/~henning/trille/ for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#367125: knfsd / bad inode number on ext3
We're also seeing this bug with 2.6.15 after replacing disks in an NFS server. It seems worth mentioning that the new filesystem has fewer inodes, both in use and available total than the old filesystem. In the kernel source, look at nfs_vfs_read() in fs/nfsd/vfs.c. It's called through about a half-dozen other functions from the top level nfsd_proc_read(). It looks like it's getting the inode number from a structure which originated in the NFS read request itself and I don't see anything doing validation. The code in ext3 appears to assume that the only source of unchecked inode numbers is the filesystem itself (like a corrupted directory), so attempting to access one which does not exist is an error that triggers the filesystem error behavior (continue, remount-ro, or panic). I see a similar report from late 2003 on RH's web site at http://www.redhat.com/archives/ext3-users/2003-December/msg00024.html , which suggests it's a longstanding but infrequently occurring bug. The exporter's method of generating the fsid also seems suspect. The exports manual page says it's generated from the block device major/minor but maybe it ought to come from the filesystem UUID instead to avoid the case where clients have stale FH's pointing at non-existent or wrong files if a filesystem needs to be remade. Such a method would also avoid unnecessary E_STALE's when the physical attachment of disks in a system changes. I'll open a separate bug for that problem. "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [EMAIL PROTECTED] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
aacraid 1.1.5-2392
Seems we are rediscovering a known issue with DELL PERC 3/Di and aacraid causing intermittent I/O issues on 2.6.8 Sarge stock kernel. I suspect same as this one (amongst others); http://lists.us.dell.com/pipermail/linux-poweredge/2005-September/022494.html DELL advises using aacraid-1.1.5-2392 (which is ahead of the version on the Adaptec website -- eek). I'm sure I can hack something from the Redhat RPM's, or speak to the author directly, but has this issue been addressed formally in the Debian kernel somewhere? I can't match kernel aacraid versions up with Adaptecs, but clearly 2.6.16-1 is 1.1.4 based so later than 1.1.2-lk2, although I assume it is maintained separately. Afraid kernel bug reporting in Debian leaves me feeling inadequate as I never know which package to file bugs against. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#368667: unmet dependencies: linux-kbuild-2.6.17
Package: linux-headers-2.6.17-rc3-686 Severity: serious Tags: experimental Hello, % apt-get install linux-headers-2.6.17-rc3-686 The following packages have unmet dependencies: linux-headers-2.6.17-rc3-686: Depends: linux-kbuild-2.6.17 but it is not installable E: Broken packages Cheers, -- Julien Danjou // <[EMAIL PROTECTED]> http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD // Ferns will rule the world. signature.asc Description: Digital signature
Processed: Merge
Processing commands for [EMAIL PROTECTED]: > severity 368667 grave Bug#368667: unmet dependencies: linux-kbuild-2.6.17 Severity set to `grave' from `serious' > tags 368667 - experimental Bug#368667: unmet dependencies: linux-kbuild-2.6.17 Tags were: experimental Tags removed: experimental > reassign 368667 linux-2.6 Bug#368667: unmet dependencies: linux-kbuild-2.6.17 Bug reassigned from package `linux-headers-2.6.17-rc3-686' to `linux-2.6'. > reassign 368544 linux-2.6 Bug#368544: linux-headers-2.6.17-rc3-amd64-k8: depends on non-existant package linux-kbuild-2.6.17 Bug reassigned from package `linux-headers-2.6.17-rc3-amd64-k8' to `linux-2.6'. > merge 368667 368544 Bug#368544: linux-headers-2.6.17-rc3-amd64-k8: depends on non-existant package linux-kbuild-2.6.17 Bug#368667: unmet dependencies: linux-kbuild-2.6.17 Merged 368544 368667. > found 368544 2.6.16+2.6.17-rc3-0experimental.1 Bug#368544: linux-headers-2.6.17-rc3-amd64-k8: depends on non-existant package linux-kbuild-2.6.17 Bug#368667: unmet dependencies: linux-kbuild-2.6.17 Bug marked as found in version 2.6.16+2.6.17-rc3-0experimental.1. > 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: kernel/d-i/security/release meeting at DebConf6
* dann frazier ([EMAIL PROTECTED]) [060524 05:33]: > On Sun, May 21, 2006 at 10:46:44PM +0200, Sven Luther wrote: > > On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: > > > Kernel udeb creation process (possibly using k-p?) > > > - > > > If we build all of the *existing* udebs from a single source, we outgrow > > > the limit of the Binary: field in the control file. > > > > Huh ? This problem is known since over 2 years now, and i thought it was one > > of the things that where fixed earlier this year or late last year ? > > Immediately after I sent out the notes from this meeting, aba said > he'd followed up with an ftp master (neuro, iirc). From what he was > told, it sounds like the information we had during this meeting was > stale/inaccurate. Actually, if I understood everything correct, the issue with the long lines used to be that on the way from the buildd to the buildd maintainer, the long line in the changes-file could be broken by MTAs, and this has been fixed. The best way to test if this is all would be to upload one source package producing all udebs to experimental, and see what happens. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 06:33]: > Well, as a proof of my claims, the sarge d-i released with a known remote > security hole, and there has been no (or maybe 1 by now ?) d-i update since > then. You mean, a remote root exploitable hole? If so, which bug, and why wasn't that information sent to debian-release? Or is it "just" a remote DoS-issue? > And again this time, d-i freeze is scheduled > first week of august, and this means we need to have the kernels frozen a week > or so before that. This is something like 5 month before the actual release > date of etch. You are ignoring that we have scheduled a time to update the kernel again before release of etch. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Wed, May 24, 2006 at 10:27:14AM +0200, Andreas Barth wrote: > * dann frazier ([EMAIL PROTECTED]) [060524 05:33]: > > On Sun, May 21, 2006 at 10:46:44PM +0200, Sven Luther wrote: > > > On Sun, May 21, 2006 at 01:09:45PM -0500, dann frazier wrote: > > > > Kernel udeb creation process (possibly using k-p?) > > > > - > > > > If we build all of the *existing* udebs from a single source, we outgrow > > > > the limit of the Binary: field in the control file. > > > > > > Huh ? This problem is known since over 2 years now, and i thought it was > > > one > > > of the things that where fixed earlier this year or late last year ? > > > > Immediately after I sent out the notes from this meeting, aba said > > he'd followed up with an ftp master (neuro, iirc). From what he was > > told, it sounds like the information we had during this meeting was > > stale/inaccurate. > > Actually, if I understood everything correct, the issue with the long > lines used to be that on the way from the buildd to the buildd > maintainer, the long line in the changes-file could be broken by MTAs, > and this has been fixed. The best way to test if this is all would be to > upload one source package producing all udebs to experimental, and see > what happens. A, good thinking. Who volunteers for doing so ? I don't think i am the right person, as i would again be seen as over-stepping my place, and stuff. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [060524 06:33]: > > Well, as a proof of my claims, the sarge d-i released with a known remote > > security hole, and there has been no (or maybe 1 by now ?) d-i update since > > then. > > You mean, a remote root exploitable hole? If so, which bug, and why > wasn't that information sent to debian-release? Or is it "just" a remote > DoS-issue? Ah, i don't remember the details exactly. It was indeed a remote security issue, but i don't remember if it was an exploit or a DoS kind of thingy. The issue was well known by the release managers of the time, and the decision to ship with it was taken in conjunction between the release managers and the d-i team. The rationale was that d-i was going to install a newer kernel anyway, and the system would be vulnerable only during the time of the install, which still seemed unacceptable to me back then, altough a bit less so if it was just a DoS, but my understanding of back then was that it was a hole. I may have been wrong though. The issue is widely documented on the lists, debian-boot, probably debian-kernel, and maybe even debian-release in april 2005, as well as the subsequent kernel changelog entry of the sarge kernel. The problem back then was that the poor kernel state meant a 30+ days upgrade path, which was partly caused by the kernel, but partly by the d-i folk too. > > And again this time, d-i freeze is scheduled > > first week of august, and this means we need to have the kernels frozen a > > week > > or so before that. This is something like 5 month before the actual release > > date of etch. > > You are ignoring that we have scheduled a time to update the kernel > again before release of etch. Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not, given the trouble of abi changes for security upgrades. In any case, it doesn't include an upstream kernel version bump in the planes i have read, right ? We should be able to rebuild all those packages on all release arches within a couple of days, a week at most, if we do it right. This doesn't seem to be worth the effort to many in this discussion though, who prefer the status-quo. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: > On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: > > You are ignoring that we have scheduled a time to update the kernel > > again before release of etch. > > Ah, nice. But would this include an abi-changing kernel upgrade ? I fear not, > given the trouble of abi changes for security upgrades. In any case, it > doesn't include an upstream kernel version bump in the planes i have read, > right ? It would even allow a newer minor kernel version, so an abi-change should be possible as well. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Wed, May 24, 2006 at 11:35:00AM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: > > On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: > > > You are ignoring that we have scheduled a time to update the kernel > > > again before release of etch. > > > > Ah, nice. But would this include an abi-changing kernel upgrade ? I fear > > not, > > given the trouble of abi changes for security upgrades. In any case, it > > doesn't include an upstream kernel version bump in the planes i have read, > > right ? > > It would even allow a newer minor kernel version, so an abi-change > should be possible as well. Nice then, the question remains of how often and in what timeframe we can do such. Imagine there is a security issue shortly before the release, will we say like last time, let's ship with it, because we have not put into place the procedure to handle it in a timely fashion ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 11:52]: > On Wed, May 24, 2006 at 11:35:00AM +0200, Andreas Barth wrote: > > * Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: > > > On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: > > > > You are ignoring that we have scheduled a time to update the kernel > > > > again before release of etch. > > > > > > Ah, nice. But would this include an abi-changing kernel upgrade ? I fear > > > not, > > > given the trouble of abi changes for security upgrades. In any case, it > > > doesn't include an upstream kernel version bump in the planes i have read, > > > right ? > > > > It would even allow a newer minor kernel version, so an abi-change > > should be possible as well. > > Nice then, the question remains of how often and in what timeframe we can do > such. Imagine there is a security issue shortly before the release, will we > say like last time, let's ship with it, because we have not put into place the > procedure to handle it in a timely fashion ? There will definitly be a time when it is too late to replace the kernel without delaying the release (just consider that we e.g. notice after starting the CD build that there is some issue). Also, we need a minimum testing periode for the final kernel and the final installer. If we set that minimum testing periode to something like 6 weeks (which seems sane to me), we cannot update the installer later than mid of October, and the kernel needs to be a little bit earlier, which is like the beginning of October. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
On Wed, May 24, 2006 at 12:04:59PM +0200, Andreas Barth wrote: > * Sven Luther ([EMAIL PROTECTED]) [060524 11:52]: > > On Wed, May 24, 2006 at 11:35:00AM +0200, Andreas Barth wrote: > > > * Sven Luther ([EMAIL PROTECTED]) [060524 11:23]: > > > > On Wed, May 24, 2006 at 10:31:08AM +0200, Andreas Barth wrote: > > > > > You are ignoring that we have scheduled a time to update the kernel > > > > > again before release of etch. > > > > > > > > Ah, nice. But would this include an abi-changing kernel upgrade ? I > > > > fear not, > > > > given the trouble of abi changes for security upgrades. In any case, it > > > > doesn't include an upstream kernel version bump in the planes i have > > > > read, > > > > right ? > > > > > > It would even allow a newer minor kernel version, so an abi-change > > > should be possible as well. > > > > Nice then, the question remains of how often and in what timeframe we can do > > such. Imagine there is a security issue shortly before the release, will we > > say like last time, let's ship with it, because we have not put into place > > the > > procedure to handle it in a timely fashion ? > > There will definitly be a time when it is too late to replace the kernel > without delaying the release (just consider that we e.g. notice after > starting the CD build that there is some issue). Also, we need a minimum > testing periode for the final kernel and the final installer. If we set > that minimum testing periode to something like 6 weeks (which seems sane > to me), we cannot update the installer later than mid of October, and > the kernel needs to be a little bit earlier, which is like the beginning > of October. Err, do you really need to retest everything when a kernel change only includes a small set of security fixes ? I think 6 weeks may be overkill there, unless naturally you are speaking of a version bump with a huge load of changes. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel/d-i/security/release meeting at DebConf6
* Sven Luther ([EMAIL PROTECTED]) [060524 12:14]: > On Wed, May 24, 2006 at 12:04:59PM +0200, Andreas Barth wrote: > > There will definitly be a time when it is too late to replace the kernel > > without delaying the release (just consider that we e.g. notice after > > starting the CD build that there is some issue). Also, we need a minimum > > testing periode for the final kernel and the final installer. If we set > > that minimum testing periode to something like 6 weeks (which seems sane > > to me), we cannot update the installer later than mid of October, and > > the kernel needs to be a little bit earlier, which is like the beginning > > of October. > > Err, do you really need to retest everything when a kernel change only > includes a small set of security fixes ? I think 6 weeks may be overkill > there, unless naturally you are speaking of a version bump with a huge load of > changes. If it is a minimal patch, we will see. However, I don't think it's usefull to discuss that now in theory. We need to see the patchset (and also what amount of open issues there still is elsewhere) to decide what to do. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: initramfs-tools confdir mv
On Mon, May 22, 2006 at 09:04:11AM +0200, maximilian attems wrote: > latest initramfs-tools mv /etc/mkinitramfs /etc/initramfs-tools > for better consistency. (package on mentors not yet in unstable) Just a plain NACK. It moves files around which don't belongs to the package, it don't takes care about upgrades where another package already put files into /etc/initramfs-tools, which is not forbidden. Bastian -- "... freedom ... is a worship word..." "It is our worship word too." -- Cloud William and Kirk, "The Omega Glory", stardate unknown
Bug#349354: initramfs-tools - kernel -udev dependency loop
On May 15, Marco d'Itri <[EMAIL PROTECTED]> wrote: > These packages are not actually needed by udev, and again they may be > unpacked in the wrong order. Next? I am still waiting for your proposals. -- ciao, Marco signature.asc Description: Digital signature
