Bug#287367: marked as done (kernel-image-2.6-386: The meta-package is not up-to-date)
Your message dated Thu, 6 Jan 2005 17:17:26 +0900 with message-id [EMAIL PROTECTED] and subject line Bug#287367: kernel-image-2.6-386: The meta-package is not up-to-date 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; 27 Dec 2004 11:31:01 + From [EMAIL PROTECTED] Mon Dec 27 03:31:01 2004 Return-path: [EMAIL PROTECTED] Received: from 85-64-143-53.barak.net.il (fourbox.held.org.il) [85.64.143.53] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1Cit5X-0001Di-00; Mon, 27 Dec 2004 03:31:00 -0800 Received: from linbox ([192.168.0.1] helo=localhost) by fourbox.held.org.il with esmtp (Exim 3.36 #1 (Debian)) id 1Cit0U-0003LG-00; Mon, 27 Dec 2004 13:25:46 +0200 Received: from mar_garina by localhost with local (Exim 3.36 #1 (Debian)) id 1Cit0v-0003DA-00; Mon, 27 Dec 2004 13:26:13 +0200 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Oren Held [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: kernel-image-2.6-386: The meta-package is not up-to-date X-Mailer: reportbug 3.5 Date: Mon, 27 Dec 2004 13:26:13 +0200 Message-Id: [EMAIL PROTECTED] Sender: Mar Garina [EMAIL PROTECTED] 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: kernel-image-2.6-386 Severity: normal This meta-package purpose is to keep machines up to date with the kernel version. kernel-image-2.6-386 depends on an old kernel version (2.6.8-1), and should depend on the newest existing package: kernel-image-2.6.9-1-386. Same goes for kernel-image-2.6-* (686, k7, etc.) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=he_IL (charmap=ISO-8859-8) --- Received: (at 287367-done) by bugs.debian.org; 6 Jan 2005 08:45:13 + From [EMAIL PROTECTED] Thu Jan 06 00:45:13 2005 Return-path: [EMAIL PROTECTED] Received: from koto.vergenet.net [210.128.90.7] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CmTGb-0002PM-00; Thu, 06 Jan 2005 00:45:13 -0800 Received: by koto.vergenet.net (Postfix, from userid 7100) id A76393413A; Thu, 6 Jan 2005 17:26:58 +0900 (JST) Date: Thu, 6 Jan 2005 17:17:26 +0900 From: Horms [EMAIL PROTECTED] To: Oren Held [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#287367: kernel-image-2.6-386: The meta-package is not up-to-date Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i 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: On Mon, Dec 27, 2004 at 01:26:13PM +0200, Oren Held wrote: Package: kernel-image-2.6-386 Severity: normal This meta-package purpose is to keep machines up to date with the kernel version. kernel-image-2.6-386 depends on an old kernel version (2.6.8-1), and should depend on the newest existing package: kernel-image-2.6.9-1-386. Same goes for kernel-image-2.6-* (686, k7, etc.) The wording is a bit weird, but this is supposed to depend on the recommended package, which is 2.6.8, the target kernel for sarge, and correspondingly the latest kernel in sarge. -- Horms
Re: kernel 2.6.8 had problems with aic79xx?
On Wed, Dec 29, 2004 at 08:54:18PM -0800, John Web wrote: Hi, I just got a new dual Opteron system with onboard SCSI controller (aic79xx), and tried to install Debain AMD-64 on it (yeah, I love Debian :). However, after several hours of trying with several different versions of ISOs (Sarge and Sid), none of them could recognize the SCSI controller (even though aic79xx module was loaded without any complains, just nothing happened). And Redhat (Enterprise version), Gentoo (2004 r3), and Fedora didnot have such a problem when I tried those later. The only difference I could tell is the version of kernels, was it the source of problem? Any suggestions? Hi John, there have been a couple of ongoing problems with aic79xx in the 2.6.8 kernel packages. I think these have been resolved now, and I am guessing that the ISOs you have had an older version of the kernel. If you have a chance to test the latest kernel on d.o then that would be much appreciated. -- Horms
Bug#287770: marked as done (CAN-2004-1137: allow a local user to cause a denial of service)
Your message dated Thu, 6 Jan 2005 17:48:27 +0900 with message-id [EMAIL PROTECTED] and subject line Bug#287770: CAN-2004-1137: allow a local user to cause a denial of service 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; 29 Dec 2004 23:01:30 + From [EMAIL PROTECTED] Wed Dec 29 15:01:30 2004 Return-path: [EMAIL PROTECTED] Received: from gateway.bzzware.org [212.125.240.90] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1Cjmos-00015E-00; Wed, 29 Dec 2004 15:01:30 -0800 Received: from fajx300.home.bzzware.org ([10.54.39.3] helo=fajx300.bzzware.org) by gateway.bzzware.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cjmny-0002i2-00; Thu, 30 Dec 2004 00:00:34 +0100 Received: from finnarne by fajx300.bzzware.org with local (Exim 4.34) id 1Cjmo0-0007bv-EF; Thu, 30 Dec 2004 00:00:36 +0100 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Finn-Arne Johansen [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: CAN-2004-1137: allow a local user to cause a denial of service X-Mailer: reportbug 3.2 Date: Thu, 30 Dec 2004 00:00:36 +0100 Message-Id: [EMAIL PROTECTED] Sender: Finn-Arne Johansen [EMAIL PROTECTED] X-MailScanner: Found to be clean 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: kernel-image-2.4.27-i386 Severity: normal Petter Reinholdsen (pere) forwarded some issues regarding the RHEL kernels, and I've found that at least 2 of them affects kernel-image-2.4.27-i386 ISEC security research discovered multiple vulnerabilities in the IGMP functionality which was backported in the Red Hat Enterprise Linux 3 kernels. These flaws could allow a local user to cause a denial of service (crash) or potentially gain privileges. Where multicast applications are being used on a system, these flaws may also allow remote users to cause a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1137 to this issue. This one also Hangs one cpu effectivly (I checked CAN-2004-1016 first) --- Received: (at 287770-done) by bugs.debian.org; 6 Jan 2005 09:38:54 + From [EMAIL PROTECTED] Thu Jan 06 01:38:54 2005 Return-path: [EMAIL PROTECTED] Received: from koto.vergenet.net [210.128.90.7] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CmU6Y-yJ-00; Thu, 06 Jan 2005 01:38:54 -0800 Received: by koto.vergenet.net (Postfix, from userid 7100) id 3409F34089; Thu, 6 Jan 2005 18:20:40 +0900 (JST) Date: Thu, 6 Jan 2005 17:48:27 +0900 From: Horms [EMAIL PROTECTED] To: Finn-Arne Johansen [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#287770: CAN-2004-1137: allow a local user to cause a denial of service Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i 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: On Thu, Dec 30, 2004 at 12:00:36AM +0100, Finn-Arne Johansen wrote: Package: kernel-image-2.4.27-i386 Severity: normal Petter Reinholdsen (pere) forwarded some issues regarding the RHEL kernels, and I've found that at least 2 of them affects kernel-image-2.4.27-i386 ISEC security research discovered multiple vulnerabilities in the IGMP functionality which was backported in the Red Hat Enterprise Linux 3 kernels. These flaws could allow a local user to cause a denial of service (crash) or potentially gain privileges. Where multicast applications are being used on a system, these flaws may also allow remote users to cause a denial of service. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1137 to this issue. This one also Hangs one cpu effectivly (I checked CAN-2004-1016 first)
Bug#287769: marked as done (kernel-image-2.4.27-i386: CAN-2004-1016: flaw in the scm_send function)
Your message dated Thu, 6 Jan 2005 17:46:35 +0900 with message-id [EMAIL PROTECTED] and subject line Bug#287769: kernel-image-2.4.27-i386: CAN-2004-1016: flaw in the scm_send function 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; 29 Dec 2004 22:54:40 + From [EMAIL PROTECTED] Wed Dec 29 14:54:40 2004 Return-path: [EMAIL PROTECTED] Received: from gateway.bzzware.org [212.125.240.90] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CjmiG-fU-00; Wed, 29 Dec 2004 14:54:40 -0800 Received: from fajx300.home.bzzware.org ([10.54.39.3] helo=fajx300.bzzware.org) by gateway.bzzware.org with esmtp (Exim 3.35 #1 (Debian)) id 1CjmhB-0002LR-00; Wed, 29 Dec 2004 23:53:33 +0100 Received: from finnarne by fajx300.bzzware.org with local (Exim 4.34) id 1CjmhD-0007aj-0p; Wed, 29 Dec 2004 23:53:35 +0100 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Finn-Arne Johansen [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: kernel-image-2.4.27-i386: CAN-2004-1016: flaw in the scm_send function X-Mailer: reportbug 3.2 Date: Wed, 29 Dec 2004 23:53:34 +0100 Message-Id: [EMAIL PROTECTED] Sender: Finn-Arne Johansen [EMAIL PROTECTED] X-MailScanner: Found to be clean 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=-6.5 required=4.0 tests=BAYES_10,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: kernel-image-2.4.27-i386 Severity: normal Petter Reinholdsen (pere) forwarded some issues regarding the RHEL kernels, and I've found that at least 2 of them affects kernel-image-2.4.27-i386 ISEC security research and Georgi Guninski independantly discovered a flaw in the scm_send function in the auxiliary message layer. A local user could create a carefully crafted auxiliary message which could cause a denial of service (system hang). The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-1016 to this issue. I ran the code on a sarge installation - as root, and effectivly hang the installation. This was a 386-kernel. Retried as a normal user, using a 686-smp kernel, and it hang one CPU effectivly 100%. NOt even possible to kill with 'kill -9 PID' --- Received: (at 287769-done) by bugs.debian.org; 6 Jan 2005 09:38:54 + From [EMAIL PROTECTED] Thu Jan 06 01:38:54 2005 Return-path: [EMAIL PROTECTED] Received: from koto.vergenet.net [210.128.90.7] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CmU6Y-yC-00; Thu, 06 Jan 2005 01:38:54 -0800 Received: by koto.vergenet.net (Postfix, from userid 7100) id 1D8D93413A; Thu, 6 Jan 2005 18:20:40 +0900 (JST) Date: Thu, 6 Jan 2005 17:46:35 +0900 From: Horms [EMAIL PROTECTED] To: Martin Michlmayr [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#287769: kernel-image-2.4.27-i386: CAN-2004-1016: flaw in the scm_send function Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i 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: On Wed, Dec 29, 2004 at 11:26:40PM +, Martin Michlmayr wrote: * Finn-Arne Johansen [EMAIL PROTECTED] [2004-12-29 23:53]: Package: kernel-image-2.4.27-i386 Severity: normal Petter Reinholdsen (pere) forwarded some issues regarding the This is fixed in the pending 2.4.27 packages at http://debian.vergenet.net/pending/kernel-source-2.4.27-2.4.27/kernel-source-2.4.27_2.4.27-7_i386.changes I am closing this bug as those packages have now been uploaded. -- Horms
Bug#288712: other serious problems...
not only the power button is unactivated, but also the fn-F3 key (which should open a DOS console to check battery), and the small button that switches off the LCD when closing the lid. I have not checked the fn-F8 key which should activate the CRT-out video, but I am not optimistic... All of these worked with the previous version of kernel-image 2.4.27 San
Processed: Re: Bug#285181: Lockups caused by kernel fs driver
Processing commands for [EMAIL PROTECTED]: reassign 285181 kernel-image-2.6-386 Bug#285181: smbfs: Mounting with CIFS causes KDE to lock up Bug reassigned from package `smbfs' to `kernel-image-2.6-386'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#282083: Will be this patch integrate?
Hello I also use this patch, but with vanilla, because I can't patch the Debian Kernel. I hope you integrate this. greet Mario PS: Sorry for my English. -- [EMAIL PROTECTED] ( Auch verschluesselt !! ) http://www.marioscheel.de ( Mit Public-Key ) ICQ# 223567831
Bug#288010: PowerPC installed initrd misses files
On Sat, Jan 01, 2005 at 05:56:32PM +0100, Geert Stappers wrote: - the ohci1334 module needed to drive the external firewire disk is missing from the image. Is this simular as http://bugs.debian.org/283712, Reboot from USB Hard Disk failed? Thanks to this hint I now finally got the installtion finished. Steps needed: - boot in expert mode - follow everything step by step - for another reason yaboot did not install, so I continued without it. - Before finishing the installation, execute a shell. - nano /target/etc/mkinird/modules and add ieee1394, ohci1394, scsi_mod, sbp2, sd_mod, and ext3 - nano /target/etc/mkinird/mkinitrd.conf and add DELAY=10 (3 seconds might be sufficient, but this is what currently works) - chroot /target - mkinitrd -o /boot/initrd-version - exit the shell(s) and finish. The system now boots at last. A final remark, in the used /target/etc/mkinird/mkinitrd.conf BUSYBOX was set to no. Currently I am fighting keymap problems (it seems that none of the supllied keymaps allows ALT-Fx console switching), but that will be a separated bug report. Bye, Joerg signature.asc Description: Digital signature
Bug#288987: oops after connecting usb device
Package: kernel-image-2.6.8-1-686 Version: 2.6.8-10 Severity: normal Hi, This is my first bug report. Let me know if you need additional information. 1) Connect the usb device (midi keyboard) 2) cat /dev/midi00 USB DEVICE: T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0a4d ProdID=0090 Rev= 1.22 S: Manufacturer=Evolution Electronics Ltd. S: Product=Keystation 49e C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio I: If#= 1 Alt= 0 #EPs= 2 Cls=01(audio) Sub=03 Prot=00 Driver=midi E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms dmesg: bad: scheduling while atomic! [c011e420] autoremove_wake_function+0x0/0x60 [c029cd8f] schedule+0x88f/0x8a0 [f8bdd593] unlink1+0x23/0x40 [usbcore] [f8bdd753] hcd_unlink_urb+0x1a3/0x220 [usbcore] [c011e420] autoremove_wake_function+0x0/0x60 [f8bde28d] usb_kill_urb+0xfd/0x151 [usbcore] [c011e420] autoremove_wake_function+0x0/0x60 [c011e420] autoremove_wake_function+0x0/0x60 [f88c51f0] ext3_release_file+0x0/0x70 [ext3] [f8bde180] usb_unlink_urb+0x50/0x60 [usbcore] [f8c2f0b5] usb_midi_release+0xf5/0x130 [usb_midi] [f8c2efc0] usb_midi_release+0x0/0x130 [usb_midi] [c0160bda] __fput+0x12a/0x140 [c015eff9] filp_close+0x59/0x90 [c0122944] put_files_struct+0x64/0xd0 [c0123893] do_exit+0x1f3/0x530 [c0123ca2] do_group_exit+0x42/0xf0 [c012cf9b] get_signal_to_deliver+0x2db/0x410 [c0105f53] do_signal+0x93/0x120 [c011c4f0] default_wake_function+0x0/0x20 [c011c4f0] default_wake_function+0x0/0x20 [c015f99d] vfs_read+0xed/0x160 [c015fc71] sys_read+0x51/0x80 [c0106017] do_notify_resume+0x37/0x39 [c0106246] work_notifysig+0x13/0x15 Aslo the kernel-image-2.6.8-1-686-smp is affected. With kernel-image-2.6.8-1-386 everything goes well. Kind regards, Daniele -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages kernel-image-2.6.8-1-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.74 tools to create initrd image for p ii module-init-tools 3.1-rel-2 tools for managing Linux kernel mo -- no debconf information
kernel-panic not syncing : VFS : unable to mount boot fs on unknown-block
Hi, I'm new to linux and i've chosen to install Debian. Currently I'm running 2.4.27-1-686-sn. Beceause I have a ATI 9800XT I wanted to compile a new kernel with the ATI-drivers in it. I downloaded kernel 2.6.9. BUT when I rebooted in 2.6.9 I get an error: VFS: Cannot open root device hde3 or unknown-block(0,0) Please append a correct root= boot option Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0) My motherboard is a P4P800 deluxe. I have a S-ATA harddisk with the first two partitions as NTFS (windows). Then I have my linux(ext3) harddisk and a swapdisk. Details: fstab: http://www.easychilling.net/tmp/fstab.info config: http://www.easychilling.net/tmp/config-2.6.9.info grub: http://www.easychilling.net/tmp/grub_menu.lst.info lspci output: http://www.easychilling.net/tmp/hardware.info I think it's something with grub or the SATA driver. I hope someone can help me, i'm busy with it for 3 days now... Thanks in advance, Robin
Re: kernel-panic not syncing : VFS : unable to mount boot fs on unknown-block
On Thu, Jan 06, 2005 at 06:08:29PM +0100, Robin Bultot wrote: BUT when I rebooted in 2.6.9 I get an error: VFS: Cannot open root device hde3 or unknown-block(0,0) Please append a correct root= boot option Kernel panic: VFS: Unable to mount root fs on unknown-block(0,0) My motherboard is a P4P800 deluxe. I have a S-ATA harddisk with the first two partitions as NTFS (windows). Then I have my linux(ext3) harddisk and a swapdisk. SATA moves from hde to sda between 2.4 and 2.6. -- 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
2.4 (devfs) - 2.6 (udev !devfs) with raid+lvm on /root transition problems
No bug for this, mostly just getting this info out there somewhere in the hopes that if someone else is trying to do this it might be of some help. Configuration: 2.4.27 standard debian kernel with devfs=mount /dev/md/0 == swap /dev/md/1 == /boot /dev/md/6 + /dev/md/7 == shaktivg /dev/shaktivg/rootlv == /root The MDs are raid1. mkinitrd creats a flawless initrd for the 2.4.x kernel (big step up from some time ago where I had to drop in scripts for setting up lvm). 2.6.9 standard debian kernel with devfs=mount I didn't spend a lot of time with this setup (devfs is deprecated and udev seems like the right way to go). Interesting that in order for lvm to work we need devfs compiled in and we have to mount devfs temporarily. Same for md it seems (to get to the md device for mdadm). So, even though *I'm* not using devfs the system is. I probably should have just left things alone with devfs=mount. 2.6.9 standard kernel with no devfs=mount. This is where things started going downhill. 1) I've always used devfs on this system. So, /dev (the underlying dev directory) was completely empty. This resulted in all kinds of mischief. For instance, /dev/console was not in the initrd. So, in init where /dev/console is used I'd get an error that dev/console is read-only (shell can't create the file dev/console for redirection) and so it fails. I also lacked /dev/hd* and /dev/md*. 2) LVM isn't smart enuf to ignore RAID1 components. This means that unless you filter out the underlying devices (/dev/hd*) it will grab the first partition that looks like an LVM component and then complain about duplication UUIDs for the others. I didn't see a rational order to which components it scans but it always saw the /dev/hd* ones before the /dev/md* ones). 3) Creating the mkinitrd under 2.4.x resulted in trying to assemble the raid using devfs device names. You'd think this would work fine since the device nodes are copied over in the initrd too. For some reason it wasn't for me. After starting, mkinitrd under 2.6 would create a initrd without the raid because lvm had bypassed the raid device and used the underlying components. So, the initrd would be created with no madadm stuff. oops. 4) LVM seemed to be consistent in which side of the mirror it chose, so I booted into a CD that supported RAID+LVM and failed the drives that LVM chose. 5) Continued trying to make LVM work. After much playing (I had the syntax wrong for the filter) I finally got it to ignore all but /dev/md?. Then make a new mkinitrd, expanded the initrd, manually added the raid stuff, rebooted/edited a few times to fix stupid mistakes, realized that lvm suddenly switched which drives it was stealing for itself sigh so my saved mkinitrd work area kept switching from one version to another, but finally got a working initrd. 6) Added the failed drives back into the mirror and resynched. So, what prompted all this? Needed to hook up an aditional fax modem. Purchased a USB--serial adapter (prolifics 2303 based). Could not get it to work on 2.4.x. Thought to try it on 2.6. Ran out of space in root due to bloat in /lib/modules/*. I resized the root LV which was at 100%. /etc/lvm/* is on root (/) and so a backup of the VG was not able to be created. No biggie I thought, never had problems. My UPS then decided to take a dump (turned out to be a batt problem). Hooked up the new UPS (already had the new one, just no scheduled downtime to hook it up), and tried to boot. Unable to mount root. Boot from recovery CD and inspect. XFS knows root is supposed to be 250M (new size) but LVM is showing it as only 150M (old size). Since the VG backup is in root I can't restore the metadata (I now keep another copy in var and will probably also keep a copy in /boot (no LVM dependancy there). I had a level 0 backup by amanda of root from a day before, so I did a manual restore of that from a boot CD that supports xfs+lvm. I had to reinstall some of the packages I put in for 2.6 support (udev, hotplug, etc). The rest of the saga is above. I'm not sure there is much that the debian packages can do to do a better job in my case. The single biggest problems I ran into were: 1) No real dev when not running devfs which caused all kinds of problems especially for the initrd. 2) lvm stealing the underlying components of the RAID1 device. This is really scary because it 'works' but will result in corruption. I had to xfs_repair my filesystems -- luckily I made no real changes to the FSes while in this state so it didn't cause me too much problems. This is fairly silent though and the system appears to work. Only because I was having other problems did I notice this problem and spend time/effort addressing it. The only real indication of a problem (other than symptoms down the road) were the duplicate UUID warnings from the lvm tools. -- -Rupa smime.p7s Description: S/MIME Cryptographic Signature
Bug#288010: PowerPC installed initrd misses files
On Thu, Jan 06, 2005 at 04:20:34PM +0100, Joerg Dorchain wrote: On Sat, Jan 01, 2005 at 05:56:32PM +0100, Geert Stappers wrote: - the ohci1334 module needed to drive the external firewire disk is missing from the image. Is this simular as http://bugs.debian.org/283712, Reboot from USB Hard Disk failed? Thanks to this hint I now finally got the installtion finished. :-) those are the better messages :-D [ Steps needed ] The system now boots at last. Okay, nice. A final remark, in the used /target/etc/mkinird/mkinitrd.conf BUSYBOX was set to no. (I am not a mkinitrd expert) Did you left it set to no? Did you have to change it? If yes, in what? In other words: What do you want to achieve with your remark? Currently I am fighting keymap problems (it seems that none of the supllied keymaps allows ALT-Fx console switching), but that will be a separated bug report. I do know that is is not the ALT-key on Apple PowerPC, but I don't know which key it is (and have no FAQ at hand ;-) Bye, Joerg Cheers Geert Stappers signature.asc Description: Digital signature
Bug#285181: Lockups caused by kernel fs driver
On Thursday 06 January 2005 14:44, Eloy A. Paris wrote: If this is the case then this is a kernel bug and the bug should be reassigned to the kernel-image package. Once the Debian kernel maintainers upload 2.6.10 this bug should be closed. Yes. I have been running kernel 2.6.10 now for a few days, with two samba shares mounted during boot with cifs. I have not had any problems so far. And KDE used to be pretty much unusable. But everything works fine now. Thanks Anders
Bug#288998: Kernel crash with USB storage device
Package: kernel-image-2.6.8-1-k7 Version: 2.6.8-10 Tested with an AMD Duron 650/VIA KT266 and an AMD Athlon 1.33C/VIA KT 133A. This applies also to kernel-image-2.4.27-1-k7 version 2.4.27-6 When I have a USB stick connected at boot time the kernel seems to enter an infinite loop: ---start Jan 5 06:41:15 stephan kernel: SCSI device sda: 250880 512-byte hdwr sectors (128 MB) Jan 5 06:41:15 stephan kernel: sda: assuming Write Enabled Jan 5 06:41:15 stephan kernel: /dev/scsi/host0/bus0/target0/lun0: p1 Jan 5 06:41:15 stephan kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 Jan 5 06:41:17 stephan kernel: lp0: using parport0 (interrupt-driven). Jan 5 06:41:22 stephan kernel: usb 1-1: control timeout on ep0in Jan 5 06:41:27 stephan kernel: usb 1-1: control timeout on ep0in Jan 5 06:41:32 stephan kernel: usb 1-2: control timeout on ep0in Jan 5 06:41:48 stephan last message repeated 3 times Jan 5 06:41:53 stephan kernel: usb 1-1: control timeout on ep0in Jan 5 06:42:18 stephan last message repeated 5 times Jan 5 06:42:23 stephan kernel: usb 1-2: control timeout on ep0in Jan 5 06:42:28 stephan kernel: usb 1-2: control timeout on ep0in Jan 5 06:42:31 stephan shutdown[1018]: shutting down for system reboot ---end-- When I connect the device to the running system and try to mount it (mount /dev/sda1 /mnt) the kernel seems to do something bad and the system is locked up: ---start Jan 5 07:18:40 stephan kernel: usb 1-1: new full speed USB device using address 3 Jan 5 07:18:40 stephan kernel: scsi0 : SCSI emulation for USB Mass Storage devices Jan 5 07:18:40 stephan kernel: Vendor: Model: USB MP3 Rev: 1.02 Jan 5 07:18:40 stephan kernel: Type: Direct-Access ANSI SCSI revision: 02 Jan 5 07:18:46 stephan kernel: usb 1-1: control timeout on ep0in Jan 5 07:18:51 stephan kernel: usb 1-1: control timeout on ep0in Jan 5 07:18:56 stephan kernel: usb 1-2: control timeout on ep0in Jan 5 07:19:01 stephan kernel: NET: Registered protocol family 4 Jan 5 07:19:01 stephan kernel: usb 1-2: control timeout on ep0in Jan 5 07:19:01 stephan kernel: NET: Registered protocol family 3 Jan 5 07:19:02 stephan kernel: NET: Registered protocol family 5 Jan 5 07:19:06 stephan kernel: usb 1-2: control timeout on ep0in Jan 5 07:19:11 stephan kernel: usb 1-2: control timeout on ep0in Jan 5 07:19:37 stephan kernel: usb 1-2: USB disconnect, address 2 Jan 5 07:19:41 stephan kernel: usb 1-2: new low speed USB device using address 4 Jan 5 07:19:45 stephan kernel: apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac) Jan 5 07:19:45 stephan kernel: apm: overridden by ACPI. Jan 5 07:19:46 stephan kernel: usb 1-2: control timeout on ep0out Jan 5 07:19:49 stephan kernel: apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac) Jan 5 07:19:49 stephan kernel: apm: overridden by ACPI. Jan 5 07:19:51 stephan kernel: usb 1-2: control timeout on ep0out Jan 5 07:19:52 stephan kernel: usb 1-2: new low speed USB device using address 5 Jan 5 07:19:57 stephan kernel: usb 1-2: control timeout on ep0out Jan 5 07:20:02 stephan kernel: usb 1-2: control timeout on ep0out Jan 5 07:20:02 stephan kernel: usb 1-1: USB disconnect, address 3 Jan 5 07:20:02 stephan kernel: scsi: Device offlined - not ready after error recovery: host 0 channel 0 id 0 lun 0 Jan 5 07:20:02 stephan kernel: Badness in scsi_device_set_state at drivers/scsi/scsi_lib.c:1643 Jan 5 07:20:02 stephan kernel: [__crc_get_wchan+5175177/6133658] scsi_device_set_state+0xc6/0x120 [scsi_mod] Jan 5 07:20:02 stephan kernel: [__crc_get_wchan+5165255/6133658] scsi_eh_offline_sdevs+0x64/0x80 [scsi_mod] Jan 5 07:20:02 stephan kernel: [__crc_get_wchan+5166831/6133658] scsi_unjam_host+0xcc/0x200 [scsi_mod] Jan 5 07:20:02 stephan kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 Jan 5 07:20:02 stephan kernel: [__crc_get_wchan+5167398/6133658] scsi_error_handler+0x103/0x1c0 [scsi_mod] Jan 5 07:20:02 stephan kernel: [__crc_get_wchan+5167139/6133658] scsi_error_handler+0x0/0x1c0 [scsi_mod] Jan 5 07:20:02 stephan kernel: [kernel_thread_helper+5/20] kernel_thread_helper+0x5/0x14 Jan 5 07:20:05 stephan kernel: apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac) Jan 5 07:20:05 stephan kernel: apm: overridden by ACPI. Jan 5 07:20:32 stephan kernel: scsi: Device offlined - not ready after error recovery: host 0 channel 0 id 0 lun 0 Jan 5 07:20:32 stephan kernel: Badness in scsi_device_set_state at drivers/scsi/scsi_lib.c:1643 Jan 5 07:20:32 stephan kernel: [__crc_get_wchan+5175177/6133658] scsi_device_set_state+0xc6/0x120 [scsi_mod] Jan 5 07:20:32 stephan kernel: [__crc_get_wchan+5165255/6133658] scsi_eh_offline_sdevs+0x64/0x80 [scsi_mod] Jan 5 07:20:32
Bug#288010: PowerPC installed initrd misses files
On Thu, Jan 06, 2005 at 06:13:05PM +0100, Geert Stappers wrote: [ Steps needed ] The system now boots at last. Okay, nice. A final remark, in the used /target/etc/mkinird/mkinitrd.conf BUSYBOX was set to no. (I am not a mkinitrd expert) Did you left it set to no? Did you have to change it? If yes, in what? I left it at no. In other words: What do you want to achieve with your remark? The d-i generated config has BUSYBOX set to yes. Currently I am fighting keymap problems (it seems that none of the supllied keymaps allows ALT-Fx console switching), but that will be a separated bug report. I do know that is is not the ALT-key on Apple PowerPC, but I don't know which key it is (and have no FAQ at hand ;-) IMHO the Apple keys look like it. I am playing with showkey and dumpkeys ATM. Bye, Joerg signature.asc Description: Digital signature
Bug#284567: kernel-source-2.4.27: frequent program crashes - unable to handle kernel paging request errors
Package: kernel-source-2.4.27 Version: 2.4.27-7 Followup-For: Bug #284567 Since upgrading to 2.4.27 (compiled from debian source), I've experienced frequent crashes is various programs like dpkg, feh, ... The fact my KDE background turns black after a while is probably also related to this problem. Here's a recent entry in /var/log/syslog: Jan 6 19:17:25 localhost kernel: 1Unable to handle kernel paging request at virtual address 0088 Jan 6 19:17:25 localhost kernel: printing eip: Jan 6 19:17:25 localhost kernel: c0128810 Jan 6 19:17:25 localhost kernel: *pde = Jan 6 19:17:25 localhost kernel: Oops: Jan 6 19:17:25 localhost kernel: CPU:0 Jan 6 19:17:25 localhost kernel: EIP: 0010:[__find_lock_page_helper+16/96] Not tainted Jan 6 19:17:25 localhost kernel: EFLAGS: 00210206 Jan 6 19:17:25 localhost kernel: eax: d3b96194 ebx: 0080 ecx: 0080 edx: 00df Jan 6 19:17:25 localhost kernel: esi: d3b96194 edi: 00df ebp: 0080 esp: c3153e48 Jan 6 19:17:25 localhost kernel: ds: 0018 es: 0018 ss: 0018 Jan 6 19:17:25 localhost kernel: Process feh (pid: 12043, stackpage=c3153000) Jan 6 19:17:25 localhost kernel: Stack: ce3e3938 0001 0001 c0133245 d3b96194 00df c1567654 Jan 6 19:17:25 localhost kernel: d3b96200 d3b96194 d3b960e0 ce3e3938 0001 0001 Jan 6 19:17:25 localhost kernel:c0133651 d3b960e0 00df c3153e9c 0001 c818f300 c0125f83 Jan 6 19:17:25 localhost kernel: Call Trace: [shmem_getpage+357/1344] [shmem_nopage+49/96] [do_no_page+99/448] [kfree_skbmem+11/96] [handle_mm_fault+82/192] Jan 6 19:17:25 localhost kernel: [do_page_fault+364/1169] [sock_recvmsg+48/192] [sock_read+126/160] [schedule+497/800] [do_page_fault+0/1169] [error_code+52/64] Jan 6 19:17:25 localhost kernel: Jan 6 19:17:25 localhost kernel: Code: 39 73 08 74 0b 8b 5b 10 eb f2 8d b6 00 00 00 00 39 7b 0c 75 I've rebooted in 2.4.26 for now to verify this is indeed a 2.4.27 issue. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.26-mppe Locale: LANG=en_GB.ISO-8859-15, [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: LC_ALL set to en_GB.iso885915) Versions of packages kernel-source-2.4.27 depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii bzip2 1.0.2-2high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities -- no debconf information
Bug#270087: related bugs
I think that bugs 288759 and 270087 are related. Perhaps the busybox maintainer will merge them? Alex Owen
kernel-patch-powerpc-2.6.9_2.6.9-2_powerpc.changes UNACCEPT
Rejected: Rejected: kernel-image-power3-smp_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-patch-powerpc-2.6.9_2.6.9-2_all.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-patch-powerpc-2.6.9_2.6.9-2.dsc: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-powerpc-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power3-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power3_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-power3_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-powerpc_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power3-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-powerpc_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power3_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-power4-smp_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-powerpc_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power4_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-powerpc-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-power4_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power4_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-build-2.6.9-power4-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-2.6.9-power4-smp_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-image-powerpc-smp_2.6.9-2_powerpc.deb: old version (100) in unstable = new version (2.6.9-2) targeted at unstable. Rejected: Rejected: kernel-headers-2.6.9_2.6.9-2_powerpc.deb: old version (2.6.9-3) in unstable = new version (2.6.9-2) targeted at unstable. === Despite being ACCEPTed, this package failed the database sanity checks at the time of install. This should only happen rarely and in corner-cases (a binary upload of a package which has since been melanie'd for example), so no code to do the necessary unaccept actions has been written. These actions (e.g. bug reopening, announcement rescinding, etc.) will have to be done by hand. Also, the files have been left in the accepted directory; please deal with them as well.
Bug#270087: Related archived bug...
Seems insmod and lsmod and rmmod were removed from busybox on purpose to fix bug #85642. But this was a bug to fix woody so the reasons to remove insmod from busybox may have now changed!?! Alex Owen
Bug#277835: kernel-image-2.6.8-2-686: USB core bugs in 2.6.8
Package: kernel-image-2.6.8-2-686 Version: 2.6.8-11 Followup-For: Bug #277835 There's a patch at http://marc.theaimsgroup.com/?l=linux-usb-develm=109241303306477w=2 that claims to fix the USB problems that cropped up in 2.6.8. I found it because I got a new USB Gamepad (the Logitech Dual Action Gamepad), plugged it in, and saw that both usbview and 'cat /proc/bus/usb/devices' were hanging. Then I saw this posting: http://www.mail-archive.com/linux-usb-users@lists.sourceforge.net/msg11332.html mike -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kernel-image-2.6.8-2-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities ii initrd-tools 0.1.76 tools to create initrd image for p ii module-init-tools 3.1-rel-2 tools for managing Linux kernel mo -- no debconf information
Bug#287030: [patch] Re: Installing on a Dual CPU G5 Powermac?
On Sun, Dec 26, 2004 at 06:24:19PM -0800, shyamal wrote: Sven == Sven Luther [EMAIL PROTECTED] writes: Sven We worked out some missing patches in the debian kernel for Sven support of newer kernels with benh, well, benh sent me the Sven needed patches, and i added it to the debian upcoming Hi Sven, Thanks for the update. I'll be happy to assist in testing if you need a volunteer with a PowerMac7,3 dual G5. I'm looking forward to testing the new d-i for my final installation. Notice that the fixed kernel is still only in unstable, and has not yet propagated to testing, because we first need to remove the kernel-patch-powerpc-2.6.8 binary package from the archive, which needs a ftp-master intervention. It was already hinted, but i don't know how long it will take to get it done. The reason for this is that in the latest 2.6.8 kernels, there is no more need for a powerpc specific patch, as it was previously, but all the needed patches are directly present in the kernel-source package. As a workaround, it is only needed to install by hand the unstable package with : apt-get install -t unstable kernel-image-2.6.8-power4 (or -power4-smp more probably) This can be done in d-i by going to the second console and chrooting into /target. If apt-get -t unstable doesn't work, you can still wget the unstable kernel and dpkg -i it by hand. Friendly, Sven Luther
Re: preparing 2.6.10
On Wed, Jan 05, 2005 at 12:15:51AM -0500, Andres Salomon wrote: Alright, enough people are bothering me for 2.6.10 that we should probably get it into sid. I've committed a bunch of bk backports to the svn 2.6.10 k-s directory (small, obvious fixes for the most part); I'm going to aim for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has objections. I'd like to advocate that we remove 2.6.9 when 2.6.10 is added. -- Horms
Re: Status of Kernel 2.4.28 packages?
On Sun, Jan 02, 2005 at 09:18:33PM +0100, Christoph Hellwig wrote: On Sun, Jan 02, 2005 at 08:16:44PM +, Tim Cutts wrote: 2.6 is still too new as far as most ISVs are concerned, and so Debian shouldn't lower the priority of work on 2.4 kernels too much just yet, in my opinion. Debian isn't lowering priority on Linux 2.4 work but individual people are. I am one of the people who do work on 2.4 for debian, I won't raise the hands of others. Personally my focus is 2.4.27, because that is what will go into sarge and right now I don't have the time to do 2.4.27 and 2.4.28. And to be honest I think that any surplus time would be best spent working on 2.6 as that is a mountain of work. If someone wants to work on getting 2.4.28 up to scratch that would be great. But it won't go into testing before sarge is released. Also if anyone has backports from 2.4.28 I would be happy to consider them for 2.4.27. -- Horms
Bug#288787: IPTables does not work with kernel 2.6.8
On Wed, Jan 05, 2005 at 11:46:45PM +0100, Frederik Schueler wrote: Hello, On Wed, Jan 05, 2005 at 08:27:19PM +0100, Christoph Hellwig wrote: On Wed, Jan 05, 2005 at 06:52:26PM +0100, Kurt Huwig wrote: Package: kernel-image-2.6.8-9-amd64-k8 Version: 2.6.8-8 Fresh installation of Sarge with all updates from today: iptables doesn't work when you're running 32bit userland on 64bit kernel, and it's not fixable either. Run an i386 kernel and everything will be fine. Or use a 64bit iptables package, wich does not offcially exist in Debian yet. This is indeed an odd problem, and I dont think there will be a 32bit interface for iptables in the near future like it exists for alsa for example. Maybe this bug should be reassigned as a wishlist against iptables requesting a 64bit package for i386, or closed at all since this is not a kernel bug, but the effect of missing support on the userland side. Any suggestions? I like the wishlist + iptables option. The maintainer of that package can decide what to do. -- Horms
Bug#270087: Related archived bug...
On Thu, Jan 06, 2005 at 08:27:53PM +, Alex Owen wrote: Seems insmod and lsmod and rmmod were removed from busybox on purpose to fix bug #85642. But this was a bug to fix woody so the reasons to remove insmod from busybox may have now changed!?! In any case, it seems that we can resolve #270087 by symlinking /sin/insmod to /sbin/insmod.modutils as you previously suggested. -- Horms
Bug#278729: kernel-image-2.6-k7: kernel-image-2.6*-k7* and 2.6*-686* should recommend libc6-i686
On Mon, Jan 03, 2005 at 12:45:17PM +0200, AKL. Mantas Kriauciunas wrote: Hi, On Mon, Nov 01, 2004 at 11:30:09AM +0900, Horms wrote: On Fri, Oct 29, 2004 at 02:37:36AM +0300, Mantas Kriauinas wrote: In package libc6-i686 description I see this info: This set of libraries is optimized for i686 machines, and will only be used if you are running a 2.6 kernel on an i686 class CPU (check the output of `uname -m'). This includes Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class CPU's (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezla). This package includes support for NPTL. As I understant from this information, most systems, which have these CPUs should have installed libc6-i686 package, so please add libc6-i686 to recommends field of all kernel-image-2.6*-k7* and kernel-image-2.6*-686* packages. Also I think, that all kernel-image-2.6*-amd64* packages should recommend libc6-i686 too. I am not so sure this is a good idea as libc is a part of the base system, and thus not usually (ever?) included in a package's dependancies. It seems you don't understand me. libc is a part of the base system, but not libc6-i686. There is no package in debian, which depends or recommends libc6-i686 package, so in most systems with 2.6-686 and k7 kernel this package isn't installed :( You can view this situation from popularity-contest results - about 1500 people have kernel-image 2.6.x-686 and 2.6.x-k7 installed (acoording to http://popcon.debian.org/main/base/by_inst ) but only less than 400 have libc6-i686 package installed ( http://popcon.debian.org/main/libs/by_inst ) Kernel-images 2.6.x-686 and 2.6.x-k7 shoud recommend libc6-i686, because libc6-686 improves system performance when running with 2.6.x-686 and 2.6.x-k7 kernel-images. Thanks for the clarification. I now agree with your suggestion. I will get it into the tree, but my TODO list is rather long today. -- Horms
Bug#288279: kernel-patch-debian-2.4.27: patches are 600 instead of 644
On Sun, Jan 02, 2005 at 03:18:57PM -0500, Travis Crump wrote: Package: kernel-patch-debian-2.4.27 Version: 2.4.27-7 Severity: important The debian kernel patches are installed with permissions 600 instead of 644 making it impossible for a normal user to use the patches and most people do not compile their kernels as root. Since the patch files had the correct permissions in 2.4.27-5 and the change occurred in 2.4.27-6 without mention in the changelog I suspect it was an accidental oversight. Thanks for bringing this to my attention. Likely the files are being installed with the prevailing umask, rather than specific permissions. The newer packages were built by me, and my umask is 077, so that would explain the cause of this. I will look into making sure the permissions are sensible for the next release. -- Horms
Bug#288812: kernel-image-2.4.27-1-686: upgrade from v2 to v6 breaks nvidia-kernel-2.4.27-1-686
On Wed, Jan 05, 2005 at 10:03:24PM +0200, Vassilii Khachaturov wrote: Package: kernel-image-2.4.27-1-686 Version: 2.4.27-6 Severity: normal Following an upgrade from 2.4.27-2 to -6, the nvidia module from nvidia-kernel-2.4.27-1-686 stopped being able to be loaded, reporting unresolved symbols even to an explicit modprobe nvidia. Forcible downgrade of the kernel back to 2.4.27-2 solved the problem, thanks go to those on #debian that told me about the snapshots server where I could get the old .deb. I have preserved the aptitude log documenting the upgrade, and the XFree86.0.log and kern.log with both sane pre-upgrade and failing post-upgrade traces. Unfortunately, I didn't preserve the exact unresolved symbols info; but, if needed, can re-create the problem and get a log of that as well. If any of the above logs or the unresolved symbols log is needed, please tell, and I'll be happy to send it as well. The unresolved sumbols log would be useful, plus something like lspci that shows what nvida board you have. -- Horms
Re: Bug #266882 still not fixed
On Fri, Jan 07, 2005 at 11:41:51AM +0900, Horms wrote: Understood. Would it be helpful if security patches for the 2.4 kernel were forwarded to the security-team as they are added to SVN for inclusion in unstable and thus testing? Yes, absolutely. Perhaps being better about opening entries on the BTS for security bugs, being better about posting patches to these entires, and being better about tagging them as security would be a mechanism to do this. You could do that, but in general direct mail is the best way to get information to the security team. -- - mdz
Re: preparing 2.6.10
On Fri, 07 Jan 2005 12:06:38 +0900, Horms wrote: On Wed, Jan 05, 2005 at 12:15:51AM -0500, Andres Salomon wrote: Alright, enough people are bothering me for 2.6.10 that we should probably get it into sid. I've committed a bunch of bk backports to the svn 2.6.10 k-s directory (small, obvious fixes for the most part); I'm going to aim for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has objections. I'd like to advocate that we remove 2.6.9 when 2.6.10 is added. Assuming 2.6.10 doesn't blow up horribly on people's systems; sure. :)
Re: preparing 2.6.10
On Fri, Jan 07, 2005 at 12:19:10AM -0500, Andres Salomon wrote: On Wed, 05 Jan 2005 22:42:48 +0100, Christoph Hellwig wrote: On Wed, Jan 05, 2005 at 10:18:04PM +0100, Eduard Bloch wrote: [...] The IRQ-after-swsusp-awakening patch (attached). Needed to make some hardware drivers work after resuming from swsusp (Source: Message-ID: [EMAIL PROTECTED]) The swsusp-speedup-patch (attached) - makes the swsusp in kernel a lot faster on suspending (source: Message-ID: [EMAIL PROTECTED]) We don't ship with swsusp enabled so this is just a waste of time. I think enough people have been asking for swsusp that it may be worth trying to enable it again, and seeing how/if it breaks for people. I wouldn't want to do it for 2.6.10-1, though; rather, let's get 2.6.10-1 out there, and if that proves stable, we can start doing some more experimental stuff w/ 2.6.10-2. Ditto for the misrouted-irq patch. I personally have been using swsup to good effect with 2.6.10-rc1 and rc2. -- Horms - 2c worth
