kernel-image-2.6.8-2-686: oops in hiddev
Package: kernel-image-2.6.8-2-686 Version: 2.6.8-16 Severity: normal *** Please type your report below this line *** Current setup: server protected by APC UPS. Monitoring of UPC status using apcupsd package via USB. Unable to handle kernel paging request at virtual address f05c7670 printing eip: e09bd096 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: smbfs appletalk lp autofs4 ipv6 pcspkr rtc floppy parport_pc parport ehci_hcd pci_hotplug intel_agp e1000 ohci_hcd snd_cmipci snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_opl3_lib snd_timer snd_hwdep usbhid gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore uhci_hcd usbcore agpgart nls_cp437 isofs dm_mod capability commoncap tsdev mousedev raid1 md evdev ide_cd cdrom psmouse ext3 jbd mbcache ide_generic piix ide_disk pdc202xx_new ide_core unix font vesafb cfbcopyarea cfbimgblt cfbfillrect CPU:0 EIP:0060:[e09bd096]Not tainted EFLAGS: 00010246 (2.6.8-2-686) EIP is at hiddev_cleanup+0x16/0x50 [usbhid] eax: c3f01694 ebx: df407a80 ecx: edx: esi: df407a94 edi: ddad7000 ebp: ddb4badc esp: ddf91f4c ds: 007b es: 007b ss: 0068 Process apcupsd (pid: 3022, threadinfo=ddf9 task=ddec9770) Stack: dc23f980 df407a80 e09bd179 df407a80 dc23f980 dc23f980 e09bd0d0 dffb7f00 c01557fe ddb4badc dc23f980 ddb49654 dc23f980 ddd6e300 ddf9 c0153d59 dc23f980 ddd6e300 ddd6e300 dc23f980 0808b7f8 Call Trace: [e09bd179] hiddev_release+0xa9/0xb0 [usbhid] [e09bd0d0] hiddev_release+0x0/0xb0 [usbhid] [c01557fe] __fput+0x11e/0x130 [c0153d59] filp_close+0x59/0x90 [c0153df1] sys_close+0x61/0xa0 [c010603b] syscall_call+0x7/0xb Code: 89 14 85 20 1c 9c e0 b8 80 1a 9c e0 89 44 24 04 8b 43 10 8b 6hiddev97: USB HID v1.00 Device [American Power Conversion Back-UPS 350 FW: 5.4.I USB FW: c1 ] on usb-:00:1f.2-1 # cat /proc/version Linux version 2.6.8-2-686 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 Thu May 19 17:53:30 JST 2005 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 1 model name : Intel(R) Pentium(R) 4 CPU 1.60GHz stepping: 2 cpu MHz : 1615.176 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips: 3194.88 -- System Information: Debian Release: 3.1 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.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327115: Floppy unexpected interrupt
On Wed, 07 Sep 2005, Luca PERSICO wrote: I tried out your distro on a laptop PC (Pentium III 900MHz); it is not a brand PC, it is a [EMAIL PROTECTED] PC, thus it is quite easy for me to have trouble installing GNU/Linux on it, so that till now the only distro that has been acceptable has been Slackware (both 9.1 and 10.1). Recently, I decided to try also Debian because it appeared very impressive (in the positive sense) to me, but I had a bad surprise which I didn't find with Slackware instead: when I mount the floppy drive I continuously receive the message: Floppy unexpected interrupt together with some other strange indication like sensei repl[80]. To try to solve this problem I put the parameter floppy=thinkpad (even if it is not a thinkpad) in the kernel options in GRUB, but without any success; after that I tried the kernel parameter floppy=no_unexpected_interrupts and even then I had no result at all. Please, can you suggest to me a solution of any kind to this problem? Take note that the kernel installed is the one obtained specifying linux26 at the installation boot prompt; the problem arised also with linux24 choosen at boot time at the beginning of the installation. Thank you a lot and many congratulation: Debian is really great! Luca Killer Fish PERSICO i'm not aware that slackware patches its kernel, thout it was upstream. nor am i aware of any debian patch concerning the floppy driver. could you please post dmesg from both the 2.6 and 2.4 kernels after boot. thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327355: linux-image-2.6.12-1-k7: amverify w/ ide-tape causes bug, then kernel panic
Package: linux-image-2.6.12-1-k7 Version: 2.6.12-6 Severity: important amverify started, then shortly later (after the first thing was done verifying, I think) these managed to make it to syslog. As you can see, it got the bug message, then rebooted itself a few minutes later: Sep 9 01:12:27 Maxwell kernel: ide-tape: bug: tape-next_stage != NULL Sep 9 01:16:14 Maxwell kernel: klogd 1.4.1#17, log source = /proc/kmsg started. Sep 9 01:16:14 Maxwell kernel: Inspecting /boot/System.map-2.6.12-1-k7 This is quite repeatable, and I never saw it on 2.6.8 (sarge). I'll test that particular tape on 2.6.8 just to be sure. Shortly (as in a second at most) after that, it panics (with the in the interrupt handler, not syncing message), which doesn't make it to the log. If that info is imporant, I'll work on getting a serial console to capture it. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (101, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.12-1-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.12-1-k7 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.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] DTSA for 2.6.8 and 2.4.27
Moritz Muehlenhoff schrieb am Friday, den 09. September 2005: Micah Anderson wrote: Neither of these advisories is a typical DTSA, as we normally we only do advisories for things that are blocked from reaching testing by some other issue, but I think that it would be good to do these two advisories because of the sheer number of security holes fixed as well as the necessary upgrade path that people need to take if they wish to maintain the integrity of their machines. Good idea, but I'd suggest to make a clean-sweep run over all kernel issues before. Some entries definitely need updating, (wrt to 2.4/2.6 You mean cross reference all the entries in CAN/list to make sure there isn't anything missing or still has a TODO label? mapping and IIRC Horms has some mails pending as well, he told me some days ago. I'll check with horms about any additional pending fixes. Also several more issues should receive a CVE mapping. What do you refer to here? I was thinking that the issues that do not have CVE numbers should possibily be submitted so that they do, although I'm not sure how long that will take and if it is worth holding up an advisory. Wrt keeping a complete history we should also move the entries based on older kernel-source packages to linux-2.6, as this will be the new permanent source package for 2.6 kernels. I'm not following you here -- do you mean change all the entries in CAN/list that are for kernel-source-#.#.# to be linux-2.6? If so, why? Thanks! Micah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] DTSA for 2.6.8 and 2.4.27
Micah Anderson wrote: Micah Anderson wrote: Neither of these advisories is a typical DTSA, as we normally we only do advisories for things that are blocked from reaching testing by some other issue, but I think that it would be good to do these two advisories because of the sheer number of security holes fixed as well as the necessary upgrade path that people need to take if they wish to maintain the integrity of their machines. Good idea, but I'd suggest to make a clean-sweep run over all kernel issues before. Some entries definitely need updating, (wrt to 2.4/2.6 You mean cross reference all the entries in CAN/list to make sure there isn't anything missing or still has a TODO label? This as well, but there are also some entries, which are only marked vulnerable as 2.4, which also apply to 2.6, e.g. CAN-2005-2800 and 2801. And vice versa possibly as well. We should double check them with the debian kernel SVN. Also several more issues should receive a CVE mapping. What do you refer to here? CAN-2005- [Four potentially DoS exploitable deadlocks and leaks in kernel 2.6] - linux-2.6 2.6.12-6 (low) CAN-2005- [DoS by removal of default ACLs in ext2/ext3] I was thinking that the issues that do not have CVE numbers should possibily be submitted so that they do, although I'm not sure how long that will take and if it is worth holding up an advisory. Half a day, I can request the rest of the missing ones tomorrow. Wrt keeping a complete history we should also move the entries based on older kernel-source packages to linux-2.6, as this will be the new permanent source package for 2.6 kernels. I'm not following you here -- do you mean change all the entries in CAN/list that are for kernel-source-#.#.# to be linux-2.6? Yes. If so, why? To preserve a complete history of security issues for the kernels. linux-2.6 will be the new permanent source package and if someone wants to check the state of a vulnerability for he shouldn't be referred to a kernel-source package that is no longer in the archive, but instead have the information from which point in time it is fixed in linux-2.6. (Practically 2.6.12-1 for almost all vulnerabilities). Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DTSA for 2.6.8 and 2.4.27
Horms schrieb am Friday, den 09. September 2005: On Thu, Sep 08, 2005 at 09:17:25PM -0500, Micah Anderson wrote: Hi, I think it would be a good idea to get a DTSA (Debian Testing Security Advisory) issued for 2.4.27 and 2.6.8. That seems fine to me, at a glance. Though there have been some aditional bugs fixed in SVN. I have added the relevant patches to all trees that were effected, though as only 2.4.27 and 2.6.12 are reevant to this discussion. It might be a good time to spin 2.4.27-12 and get that into unstable. And linux-2.6 2.6.12-6, which was released earleier this week, should be up to date. If there are new security issues in SVN, definately spin out a new 2.4.27-12, but this brings up a question -- We haven't being doing DTSAs for every security hole that is fixed in unstable and naturally migrates to testing, at this point we are only doing them for those packages which can't enter testing on their own because they are blocked by something. The reason I was suggesting doing one for 2.4.27-11 was because there are a significant number of holes fixed in that release compared to previous, but since it migrates fine from unstable to testing, perhaps we shouldn't do a DTSA on it at all? Notifying testing users of security holes in all packages that enter testing from unstable is useful, but it may be too much of a burden on the team to issue advisories on them all. Do we want to be doing DTSAs for every new kernel version that comes out with security holes? If we do, we need to make a policy decision. Either we: 1. make it our policy to always do DTSAs for kernel security issues regardless if they enter testing naturally or not; or 2. make it our policy to do a DTSA for all packages that fix a significant number[1] of security issues because the significance of the threat is large enough to draw attention to the fix. Thoughts? Issuing an advisory for 2.6.8 still seems to make sense to me, since the transition to 2.6.12 is not so obvious. Micah 1. The definition of significant number is up to the team or the person willing to write the DTSA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of linux-2.6_2.6.12-6_m68k.changes
linux-2.6_2.6.12-6_m68k.changes uploaded successfully to localhost along with the files: linux-headers-2.6.12-1_2.6.12-6_m68k.deb linux-headers-2.6.12-1-amiga_2.6.12-6_m68k.deb linux-image-2.6.12-1-amiga_2.6.12-6_m68k.deb linux-image-amiga_2.6.12-6_m68k.deb linux-image-2.6-amiga_2.6.12-6_m68k.deb linux-headers-2.6-amiga_2.6.12-6_m68k.deb linux-headers-2.6.12-1-atari_2.6.12-6_m68k.deb linux-image-2.6.12-1-atari_2.6.12-6_m68k.deb linux-image-atari_2.6.12-6_m68k.deb linux-image-2.6-atari_2.6.12-6_m68k.deb linux-headers-2.6-atari_2.6.12-6_m68k.deb linux-headers-2.6.12-1-bvme6000_2.6.12-6_m68k.deb linux-image-2.6.12-1-bvme6000_2.6.12-6_m68k.deb linux-image-bvme6000_2.6.12-6_m68k.deb linux-image-2.6-bvme6000_2.6.12-6_m68k.deb linux-headers-2.6-bvme6000_2.6.12-6_m68k.deb linux-headers-2.6.12-1-hp_2.6.12-6_m68k.deb linux-image-2.6.12-1-hp_2.6.12-6_m68k.deb linux-image-hp_2.6.12-6_m68k.deb linux-image-2.6-hp_2.6.12-6_m68k.deb linux-headers-2.6-hp_2.6.12-6_m68k.deb linux-headers-2.6.12-1-mac_2.6.12-6_m68k.deb linux-image-2.6.12-1-mac_2.6.12-6_m68k.deb linux-image-mac_2.6.12-6_m68k.deb linux-image-2.6-mac_2.6.12-6_m68k.deb linux-headers-2.6-mac_2.6.12-6_m68k.deb linux-headers-2.6.12-1-mvme147_2.6.12-6_m68k.deb linux-image-2.6.12-1-mvme147_2.6.12-6_m68k.deb linux-image-mvme147_2.6.12-6_m68k.deb linux-image-2.6-mvme147_2.6.12-6_m68k.deb linux-headers-2.6-mvme147_2.6.12-6_m68k.deb linux-headers-2.6.12-1-mvme16x_2.6.12-6_m68k.deb linux-image-2.6.12-1-mvme16x_2.6.12-6_m68k.deb linux-image-mvme16x_2.6.12-6_m68k.deb linux-image-2.6-mvme16x_2.6.12-6_m68k.deb linux-headers-2.6-mvme16x_2.6.12-6_m68k.deb linux-headers-2.6.12-1-q40_2.6.12-6_m68k.deb linux-image-2.6.12-1-q40_2.6.12-6_m68k.deb linux-image-q40_2.6.12-6_m68k.deb linux-image-2.6-q40_2.6.12-6_m68k.deb linux-headers-2.6-q40_2.6.12-6_m68k.deb linux-headers-2.6.12-1-sun3_2.6.12-6_m68k.deb linux-image-2.6.12-1-sun3_2.6.12-6_m68k.deb linux-image-sun3_2.6.12-6_m68k.deb linux-image-2.6-sun3_2.6.12-6_m68k.deb linux-headers-2.6-sun3_2.6.12-6_m68k.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-2.6_2.6.12-6_m68k.changes ACCEPTED
Accepted: linux-headers-2.6-amiga_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-amiga_2.6.12-6_m68k.deb linux-headers-2.6-atari_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-atari_2.6.12-6_m68k.deb linux-headers-2.6-bvme6000_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-bvme6000_2.6.12-6_m68k.deb linux-headers-2.6-hp_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-hp_2.6.12-6_m68k.deb linux-headers-2.6-mac_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-mac_2.6.12-6_m68k.deb linux-headers-2.6-mvme147_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-mvme147_2.6.12-6_m68k.deb linux-headers-2.6-mvme16x_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-mvme16x_2.6.12-6_m68k.deb linux-headers-2.6-q40_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-q40_2.6.12-6_m68k.deb linux-headers-2.6-sun3_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6-sun3_2.6.12-6_m68k.deb linux-headers-2.6.12-1-amiga_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1-amiga_2.6.12-6_m68k.deb linux-headers-2.6.12-1-atari_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1-atari_2.6.12-6_m68k.deb linux-headers-2.6.12-1-bvme6000_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1-bvme6000_2.6.12-6_m68k.deb linux-headers-2.6.12-1-hp_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1-hp_2.6.12-6_m68k.deb linux-headers-2.6.12-1-mac_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1-mac_2.6.12-6_m68k.deb linux-headers-2.6.12-1-mvme147_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1-mvme147_2.6.12-6_m68k.deb linux-headers-2.6.12-1-mvme16x_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1-mvme16x_2.6.12-6_m68k.deb linux-headers-2.6.12-1-q40_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1-q40_2.6.12-6_m68k.deb linux-headers-2.6.12-1-sun3_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1-sun3_2.6.12-6_m68k.deb linux-headers-2.6.12-1_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-headers-2.6.12-1_2.6.12-6_m68k.deb linux-image-2.6-amiga_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6-amiga_2.6.12-6_m68k.deb linux-image-2.6-atari_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6-atari_2.6.12-6_m68k.deb linux-image-2.6-bvme6000_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6-bvme6000_2.6.12-6_m68k.deb linux-image-2.6-hp_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6-hp_2.6.12-6_m68k.deb linux-image-2.6-mac_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6-mac_2.6.12-6_m68k.deb linux-image-2.6-mvme147_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6-mvme147_2.6.12-6_m68k.deb linux-image-2.6-mvme16x_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6-mvme16x_2.6.12-6_m68k.deb linux-image-2.6-q40_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6-q40_2.6.12-6_m68k.deb linux-image-2.6-sun3_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6-sun3_2.6.12-6_m68k.deb linux-image-2.6.12-1-amiga_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6.12-1-amiga_2.6.12-6_m68k.deb linux-image-2.6.12-1-atari_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6.12-1-atari_2.6.12-6_m68k.deb linux-image-2.6.12-1-bvme6000_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6.12-1-bvme6000_2.6.12-6_m68k.deb linux-image-2.6.12-1-hp_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6.12-1-hp_2.6.12-6_m68k.deb linux-image-2.6.12-1-mac_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6.12-1-mac_2.6.12-6_m68k.deb linux-image-2.6.12-1-mvme147_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6.12-1-mvme147_2.6.12-6_m68k.deb linux-image-2.6.12-1-mvme16x_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6.12-1-mvme16x_2.6.12-6_m68k.deb linux-image-2.6.12-1-q40_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6.12-1-q40_2.6.12-6_m68k.deb linux-image-2.6.12-1-sun3_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-2.6.12-1-sun3_2.6.12-6_m68k.deb linux-image-amiga_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-amiga_2.6.12-6_m68k.deb linux-image-atari_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-atari_2.6.12-6_m68k.deb linux-image-bvme6000_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-bvme6000_2.6.12-6_m68k.deb linux-image-hp_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-hp_2.6.12-6_m68k.deb linux-image-mac_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-mac_2.6.12-6_m68k.deb linux-image-mvme147_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-mvme147_2.6.12-6_m68k.deb linux-image-mvme16x_2.6.12-6_m68k.deb to pool/main/l/linux-2.6/linux-image-mvme16x_2.6.12-6_m68k.deb linux-image-q40_2.6.12-6_m68k.deb to
Re: acct v3 support
On Wed, Sep 07, 2005 at 02:57:47PM -0700, Ryan Lovett wrote: Are there plans to have more architectures enable the newer accounting file format via CONFIG_BSD_PROCESS_ACCT_V3 ? I'm actually only interested in amd64. $ egrep 'CONFIG_BSD_PROCESS_ACCT_V3=y|linux-2.6-2.6.12/debian/arch/' \ linux-2.6_2.6.12-5.diff The above seems to indicate that v3 is enabled for alpha and hppa. I realize enabling this feature may require changes in the user space tools, e.g. http://www.physik3.uni-rostock.de/tim/kernel/utils/acct/ Should I file a wishlist bug? This breaks the accounting format, so it's a change that needs a lot of thought. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: standardizing on a language
On Thu, Sep 08, 2005 at 01:23:30AM -0400, Andres Salomon wrote: Naturally, we'll still need to have things that end up being run on the user's system in perl or shell (shell for things that can't use or are too simplistic perl, and perl for other things). We are not restricted to essential packages. I'm comfortable with either ruby or python; I suppose it depends on what others are more comfortable with. I don't know anything about ruby. Once we have a common language, we can have a common library as well linux-2.6/debian/lib/python already exists. (ages ago, I wrote half a Kconfig parser in racc; I have a fullblown parser which is derived from the original yacc and flex files written in python. Bastian -- First study the enemy. Seek weakness. -- Romulan Commander, Balance of Terror, stardate 1709.2 signature.asc Description: Digital signature
Bug#312255: Problems booting kernel-image-2.6.8-2-k7
Package: kernel-image-2.6.8-2-k7 Version: 2.6.8-16 Followup-For: Bug #312255 If I boot the system using kernel 2.6, after the message Starting GNOME DISPLAY MANAGER: gdm, a messy image appears, similar to my desktop background: except for the mouse, everything is blocked. To go on I have to reset: mysteriously, after the reboot I can use kernel 2.6 (sometimes I have to repeat this procedure many times). Kernel 2.4, instead, works fine. I installed the kernel-image-2.6.8-2-k7 package after the installation of Debian 3.1 sarge with kernel-image-2.4.27-2-386. I use an AMD Athlon XP 1800+ CPU and an ATI Radeon 7000 graphic card on an ASUS A7V880 motherboard (VIA KT880/VT8237 chipset). lspci -v output: :00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0269 (rev 80) Subsystem: Asustek Computer, Inc.: Unknown device 8122 Flags: bus master, 66MHz, medium devsel, latency 64 Memory at e000 (32-bit, prefetchable) [size=256M] Capabilities: [80] AGP version 3.5 Capabilities: [50] Power Management version 2 :00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1269 Subsystem: Asustek Computer, Inc.: Unknown device 8122 Flags: bus master, medium devsel, latency 0 :00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2269 Subsystem: Asustek Computer, Inc.: Unknown device 8122 Flags: bus master, medium devsel, latency 0 :00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3269 Subsystem: Asustek Computer, Inc.: Unknown device 8122 Flags: bus master, medium devsel, latency 0 :00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4269 Subsystem: Asustek Computer, Inc.: Unknown device 8122 Flags: bus master, medium devsel, latency 0 :00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7269 Subsystem: Asustek Computer, Inc.: Unknown device 8122 Flags: bus master, medium devsel, latency 0 :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: fe10-fe4f Prefetchable memory behind bridge: 9ff0-afef Capabilities: [70] Power Management version 2 :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) Subsystem: Asustek Computer, Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 64, IRQ 20 I/O ports at eff0 [size=8] I/O ports at efe4 [size=4] I/O ports at efa8 [size=8] I/O ports at efe0 [size=4] I/O ports at ef90 [size=16] I/O ports at e800 [size=256] Capabilities: [c0] Power Management version 2 :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: Asustek Computer, Inc. A7V600 motherboard Flags: bus master, medium devsel, latency 32, IRQ 20 I/O ports at fc00 [size=16] Capabilities: [c0] Power Management version 2 :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 64, IRQ 21 I/O ports at eec0 [size=32] Capabilities: [80] Power Management version 2 :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 64, IRQ 21 I/O ports at ef00 [size=32] Capabilities: [80] Power Management version 2 :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 64, IRQ 21 I/O ports at ef20 [size=32] Capabilities: [80] Power Management version 2 :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller Flags: bus master, medium devsel, latency 64, IRQ 21 I/O ports at ef40 [size=32] Capabilities: [80] Power Management version 2 :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) Subsystem: VIA Technologies, Inc. USB 2.0 Flags: bus master, medium devsel, latency 64, IRQ 21 Memory at fe90 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management
how to detect a debian kernel from `uname -r`
Hello everyone, I'm trying to detect a debian kernel from uname -r. My suggestion would be to add a -debian at the end of the localversion of kernels _patched_/modified by debian, and to leave the localversion completely _empty_ (or an unchanged localversion compared to the mainline defconfig) for unmodified mainline kernels shipped by debian (if you ship them in the first place). I also wonder how to detect ubuntu kernels, perhaps they're the same as debian I don't know. If they're the same from a sourcecode standpoint then I guess it's better to call them -debian too at the end of the extraversion. Note: I don't care about which userland is running, I only care to detect the kernel branch that is running (i.e. mainline/mm/ac/debian/suse/fedora etc..), so trying to detect the distro in userland is not an option (plus I suspect it would be even less standard). Currently I'm using this regexp and it still can't detect everything, plus I hope I'm not marking as debian kernels that are identical to mainline from a sourcecode standpoint (I'm not tracking _who_ compiled it): 'Debian' : re.compile(r'^(\d+)\.(\d+)\.(\d+)(?:\.?(\d+)?|-rc(\d+))(?:-git(\d+))?-(\d+)-(?:[3456]86|k7|generic|amd64-k8)'), Full GPL'd sourcecode of the regexp is here: http://klive.cpushare.com/downloads/klive-0.7.tar.bz2 see the branch_regexp in klive/server/web.py. You can see the results of the current regexp here: http://klive.cpushare.com/?branch=Debian but I can't detect everything, for example in unknown there are still debian kernels very strangely called -p4-2 (google tells me it comes from some .deb package): http://klive.cpushare.com/?branch=unknown No idea what the -2 at the end stands for (perhaps it's compiled with max_cpus=2?). Suggestions are welcome. Thanks! PS. I'm off-list so please make sure to include me in CC if the list software adds a reply-to: to the email. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: acct v3 support
On Fri, Sep 09, 2005 at 04:50:03PM +0200, Christoph Hellwig wrote: This breaks the accounting format, so it's a change that needs a lot of thought. Okay, thanks for considering this. The file http://www.physik3.uni-rostock.de/tim/kernel/utils/acct/readme.txt mentions: Note that the --raw option of dump-acct makes for a nice little format converter together with the new --format and --byteswap options, if multiformat support is compiled in. It works in any direction, which particularly means you don't get locked into using this special version of the accounting tools. Rather, you might back out at any time and in any direction (v0 or v3 format). You might decide to completely switch over to v3 format and use multiformat-enabled acct tools only once during conversion. v3 format is source compatible with unmodified GNU acct 6.3.5, but only if v0/v1/v2 format is completely removed from the kernel (see acct cleanup patch at http://www.physik3.uni-rostock.de/tim/kernel/2.7/) and the resulting linux/include/acct.h file is copied into /usr/include/linux before ./configure is invoked. among other things. Ryan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327416: CAN-2005-2490/CAN-2005-2492: Two sendmsg() related vulnerabilites
Package: linux-2.6
Severity: important
Tags: security
[Severity important only, as amd64 is not yet officially in the archive]
These patches were posted as part of the stable review cycle on linux-kernel,
they're probably available in git already.
CAN-2005-2490: (local privilege escalation on amd64)
When we copy 32bit -msg_control contents to kernel, we walk the same
userland data twice without sanity checks on the second pass.
Second version of this patch: the original broke with 64-bit arches
running 32-bit-compat-mode executables doing sendmsg() syscalls with
unaligned CMSG data areas
Another thing is that we use kmalloc() to allocate and sock_kfree_s()
to free afterwards; less serious, but also needs fixing.
Patch by Al Viro, David Miller, David Woodhouse
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
include/net/compat.h |2 +-
net/compat.c | 44 ++--
net/socket.c |3 ++-
3 files changed, 29 insertions(+), 20 deletions(-)
Index: linux-2.6.13.y/include/net/compat.h
===
--- linux-2.6.13.y.orig/include/net/compat.h
+++ linux-2.6.13.y/include/net/compat.h
@@ -33,7 +33,7 @@ extern asmlinkage long compat_sys_sendms
extern asmlinkage long compat_sys_recvmsg(int,struct compat_msghdr __user
*,unsigned);
extern asmlinkage long compat_sys_getsockopt(int, int, int, char __user *, int
__user *);
extern int put_cmsg_compat(struct msghdr*, int, int, int, void *);
-extern int cmsghdr_from_user_compat_to_kern(struct msghdr *, unsigned char *,
+extern int cmsghdr_from_user_compat_to_kern(struct msghdr *, struct sock *,
unsigned char *,
int);
#endif /* NET_COMPAT_H */
Index: linux-2.6.13.y/net/compat.c
===
--- linux-2.6.13.y.orig/net/compat.c
+++ linux-2.6.13.y/net/compat.c
@@ -135,13 +135,14 @@ static inline struct compat_cmsghdr __us
* thus placement) of cmsg headers and length are different for
* 32-bit apps. -DaveM
*/
-int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg,
+int cmsghdr_from_user_compat_to_kern(struct msghdr *kmsg, struct sock *sk,
unsigned char *stackbuf, int stackbuf_size)
{
struct compat_cmsghdr __user *ucmsg;
struct cmsghdr *kcmsg, *kcmsg_base;
compat_size_t ucmlen;
__kernel_size_t kcmlen, tmp;
+ int err = -EFAULT;
kcmlen = 0;
kcmsg_base = kcmsg = (struct cmsghdr *)stackbuf;
@@ -156,6 +157,7 @@ int cmsghdr_from_user_compat_to_kern(str
tmp = ((ucmlen - CMSG_COMPAT_ALIGN(sizeof(*ucmsg))) +
CMSG_ALIGN(sizeof(struct cmsghdr)));
+ tmp = CMSG_ALIGN(tmp);
kcmlen += tmp;
ucmsg = cmsg_compat_nxthdr(kmsg, ucmsg, ucmlen);
}
@@ -167,30 +169,34 @@ int cmsghdr_from_user_compat_to_kern(str
* until we have successfully copied over all of the data
* from the user.
*/
- if(kcmlen stackbuf_size)
- kcmsg_base = kcmsg = kmalloc(kcmlen, GFP_KERNEL);
- if(kcmsg == NULL)
+ if (kcmlen stackbuf_size)
+ kcmsg_base = kcmsg = sock_kmalloc(sk, kcmlen, GFP_KERNEL);
+ if (kcmsg == NULL)
return -ENOBUFS;
/* Now copy them over neatly. */
memset(kcmsg, 0, kcmlen);
ucmsg = CMSG_COMPAT_FIRSTHDR(kmsg);
while(ucmsg != NULL) {
- __get_user(ucmlen, ucmsg-cmsg_len);
+ if (__get_user(ucmlen, ucmsg-cmsg_len))
+ goto Efault;
+ if (!CMSG_COMPAT_OK(ucmlen, ucmsg, kmsg))
+ goto Einval;
tmp = ((ucmlen - CMSG_COMPAT_ALIGN(sizeof(*ucmsg))) +
CMSG_ALIGN(sizeof(struct cmsghdr)));
+ if ((char *)kcmsg_base + kcmlen - (char *)kcmsg
CMSG_ALIGN(tmp))
+ goto Einval;
kcmsg-cmsg_len = tmp;
- __get_user(kcmsg-cmsg_level, ucmsg-cmsg_level);
- __get_user(kcmsg-cmsg_type, ucmsg-cmsg_type);
-
- /* Copy over the data. */
- if(copy_from_user(CMSG_DATA(kcmsg),
- CMSG_COMPAT_DATA(ucmsg),
- (ucmlen - CMSG_COMPAT_ALIGN(sizeof(*ucmsg)
- goto out_free_efault;
+ tmp = CMSG_ALIGN(tmp);
+ if (__get_user(kcmsg-cmsg_level, ucmsg-cmsg_level) ||
+ __get_user(kcmsg-cmsg_type, ucmsg-cmsg_type) ||
+ copy_from_user(CMSG_DATA(kcmsg),
+ CMSG_COMPAT_DATA(ucmsg),
+ (ucmlen -
CMSG_COMPAT_ALIGN(sizeof(*ucmsg)
+ goto Efault;
/* Advance. */
- kcmsg = (struct cmsghdr *)((char *)kcmsg + CMSG_ALIGN(tmp));
+ kcmsg = (struct
Bug#327432: kernel-image-2.4.27-2-sparc32: upgrading from 2.2 kernel deadlocks with libc upgrade
Package: kernel-image-2.4.27-2-sparc32 Version: 2.4.27-9 Severity: important I had an old sparc which was running a 2.2.20 kernel (yes, old) and libc6 2.2.5-11.5. I tried to upgrade it (apt-get install dist-upgrade) and it choked. In particular, the kernel depends on a newer version of libc: locks-keyed-alike:~# apt-get install kernel-image-2.4-sparc32 Reading Package Lists... Done Building Dependency Tree... Done You might want to run `apt-get -f install' to correct these: Sorry, but the following packages have unmet dependencies: kernel-image-2.4-sparc32: Depends: kernel-image-2.4.27-2-sparc32 but it is not going to be installed libdb1-compat: Depends: libc6 (= 2.2.5-13) but 2.2.5-11.5 is to be installed E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). And the libc won't install without a newer kernel version: Do you want to upgrade glibc now? [Y/n] WARNING: You have a cpu which requires kernel 2.4.21 or greater in order to install this version of glibc. Please upgrade the kernel before installing this package. You should be able to install the latest version of the sparc kernel-image in order to satisfy this need. You can also download and compile the latest kernel source yourself from a kernel mirror (see http://www.kernel.org/). dpkg: error processing /var/cache/apt/archives/libc6_2.3.2.ds1-22_sparc.deb (--unpack): subprocess pre-installation script returned error exit status 1 At this point, apt-get -f install fails as above, I can't install the new libc without the new kernel, and I can't install the new kernel without the new libc. I eventually got myself out of this by replacing uname with a shell script which claimed I was running 2.4.21, and then actually upgraded everything, but this is a pretty absurd thing to have to do. -- System Information: Debian Release: 3.1 Architecture: sparc Kernel: Linux 2.4.27-2-sparc32 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kernel-image-2.4.27-2-sparc32 depends on: ii initrd-tools 0.1.81.1 tools to create initrd image for p ii modutils 2.4.26-1.2 Linux module utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327432: kernel-image-2.4.27-2-sparc32: upgrading from 2.2 kernel deadlocks with libc upgrade
On Fri, 9 Sep 2005, Marc Horowitz wrote: I had an old sparc which was running a 2.2.20 kernel (yes, old) and libc6 2.2.5-11.5. I tried to upgrade it (apt-get install dist-upgrade) and it choked. In particular, the kernel depends on a newer version of libc: This is a known issue, arising when attempting woody-sarge upgrade on sparc. Proper procedure for upgrading the kernel is documented in Sarge release notes (paragraph 4.3 and appendix A): http://www.debian.org/releases/stable/sparc/release-notes/ap-kernel-upgrade-howto.en.html Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327432: kernel-image-2.4.27-2-sparc32: upgrading from 2.2 kernel deadlocks with libc upgrade
Jurij Smakov [EMAIL PROTECTED] writes: On Fri, 9 Sep 2005, Marc Horowitz wrote: I had an old sparc which was running a 2.2.20 kernel (yes, old) and libc6 2.2.5-11.5. I tried to upgrade it (apt-get install dist-upgrade) and it choked. In particular, the kernel depends on a newer version of libc: This is a known issue, arising when attempting woody-sarge upgrade on sparc. Proper procedure for upgrading the kernel is documented in Sarge release notes (paragraph 4.3 and appendix A): http://www.debian.org/releases/stable/sparc/release-notes/ap-kernel-upgrade-howto.en.html Shouldn't the system somehow warn me I have a gun aimed at my foot *before* I pull the trigger? Marc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327436: kernel segv after SMB server (buffalo linkstation, running linux) was reconfigured
Package: kernel-image-2.6.8-11-amd64-k8
Version: 2.6.8-14
Severity: minor
After reconfiguration of permissions on a mounted SMB volume, the Kernel
decided to segfault (system continued to run, blocking processes that
were accessing the affected volume).
Here is what /var/log/messages had to say:
Sep 9 20:45:44 localhost kernel: Pid: 4851, comm: df Not tainted
2.6.8-11-amd64-k8
Sep 9 20:45:44 localhost kernel: RIP: 0010:[8017e533]
8017e533{invalidate_list+67}
Sep 9 20:45:44 localhost kernel: RSP: :0100243ddc78 EFLAGS:
00010282
Sep 9 20:45:44 localhost kernel: RAX: 01000ae5acf0 RBX:
171ff4f441aae856 RCX: 01003917f930
Sep 9 20:45:44 localhost kernel: RDX: 0100243ddcb8 RSI:
01003f42c800 RDI: 802e2770
Sep 9 20:45:44 localhost kernel: RBP: 01002391acf8 R08:
010007043e5c R09: 010007043e00
Sep 9 20:45:44 localhost kernel: R10: 010002117930 R11:
801adeb0 R12: 171ff4f441aae856
Sep 9 20:45:44 localhost kernel: R13: 802e2770 R14:
01003f42c800 R15: 0100243ddcb8
Sep 9 20:45:44 localhost kernel: FS: 58636000()
GS:803b1540() knlGS:56a57840
Sep 9 20:45:44 localhost kernel: CS: 0010 DS: 002b ES: 002b CR0:
80050033
Sep 9 20:45:44 localhost kernel: CR2: 081c9350 CR3:
00101000 CR4: 06e0
Sep 9 20:45:44 localhost kernel: Process df (pid: 4851, threadinfo
0100243dc000, task 01002c6e8ac0)
Sep 9 20:45:44 localhost kernel: Stack:
010007043e00 0100023ec8b0 0100023ec800
Sep 9 20:45:44 localhost kernel:01003f42c800
802e2740 08d5 8017f0ec
Sep 9 20:45:44 localhost kernel:0100243ddcb8
0100243ddcb8
Sep 9 20:45:44 localhost kernel: Call
Trace:8017f0ec{invalidate_inodes+76}
a018dd35{:smbfs:smbiod_retry+53}
Sep 9 20:45:44 localhost kernel:
a018dd02{:smbfs:smbiod_retry+2}
a018e645{:smbfs:smb_add_request+725}
Sep 9 20:45:44 localhost kernel:
8014f6bf{__get_free_pages+31}
80152cdb{cache_alloc_refill+619}
Sep 9 20:45:44 localhost kernel:
a0186bef{:smbfs:smb_request_ok+63}
a018a265{:smbfs:smb_proc_dskattr+85}
Sep 9 20:45:44 localhost kernel:
a018cda9{:smbfs:smb_statfs+9}
8016528d{vfs_statfs+93}
Sep 9 20:45:44 localhost kernel:
8018b0fa{compat_statfs64+106}
80288f1e{thread_return+41}
Sep 9 20:45:44 localhost kernel:
801673d3{sys_write+83} 80110ab1{error_exit+0}
Sep 9 20:45:44 localhost kernel:
80120a81{ia32_sysret+0}
Sep 9 20:45:44 localhost kernel:
Sep 9 20:45:44 localhost kernel: Code: 4d 8b 24 24 4c 39 eb 0f 84 87 00
00 00 48 8d 6b f0 4c 39 b5
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (650, 'testing'), (600, 'unstable')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.8-11-amd64-k8
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages kernel-image-2.6.8-11-amd64-k8 depends on:
ii coreutils [fileutils] 5.2.1-2 The GNU core utilities
ii e2fsprogs 1.37-2sarge1 ext2 file system utilities and lib
ii initrd-tools0.1.81.1 tools to create initrd image for p
ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327432: kernel-image-2.4.27-2-sparc32: upgrading from 2.2 kernel deadlocks with libc upgrade
On Fri, 9 Sep 2005, Marc Horowitz wrote: Shouldn't the system somehow warn me I have a gun aimed at my foot *before* I pull the trigger? Marc Well, it did prevent you from installing a broken combination of things. And there is a documented workaround. Anyway, nothing can be done to improve the situation now, as we can't really change Sarge kernels anymore (apart from security fixes). Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to detect a debian kernel from `uname -r`
On Fri, Sep 09, 2005 at 11:16:38PM +0200, Andrea Arcangeli wrote: Hello everyone, I'm trying to detect a debian kernel from uname -r. My suggestion would be to add a -debian at the end of the localversion of kernels _patched_/modified by debian, and to leave the localversion completely _empty_ (or an unchanged localversion compared to the mainline defconfig) for unmodified mainline kernels shipped by debian (if you ship them in the first place). Not a good idea. Why clutter the namespace of versions in order to adapt to non-debian needs. ? What is it you intent to do anyway ? I also wonder how to detect ubuntu kernels, perhaps they're the same as debian I don't know. If they're the same from a sourcecode standpoint then I guess it's better to call them -debian too at the end of the extraversion. The ubuntu kernel is similar but different. What about : more /proc/version Linux version 2.6.12-1-powerpc ([EMAIL PROTECTED]) (gcc version 4.0.2 20050806 (prerelease) (Debian 4.0.1-4)) #1 Tue Aug 16 20:08:54 UTC 2005 Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: acct v3 support
On Fri, Sep 09, 2005 at 04:50:03PM +0200, Christoph Hellwig wrote: On Wed, Sep 07, 2005 at 02:57:47PM -0700, Ryan Lovett wrote: Are there plans to have more architectures enable the newer accounting file format via CONFIG_BSD_PROCESS_ACCT_V3 ? I'm actually only interested in amd64. $ egrep 'CONFIG_BSD_PROCESS_ACCT_V3=y|linux-2.6-2.6.12/debian/arch/' \ linux-2.6_2.6.12-5.diff The above seems to indicate that v3 is enabled for alpha and hppa. I realize enabling this feature may require changes in the user space tools, e.g. http://www.physik3.uni-rostock.de/tim/kernel/utils/acct/ Should I file a wishlist bug? This breaks the accounting format, so it's a change that needs a lot of thought. I agree, though it is curious that it is enabled on alpha and hppa. Does that imply that it works with their userspace, and thus should work on other arches too. Or does it imply that no one has noticed that it doesn't work? It seems that it should be consistently on or off for all builds that have CONFIG_BSD_PROCESS_ACCT enabled, which is all builds except sparc and some arm flavours. I'd like some feedback on if CONFIG_BSD_PROCESS_ACCT should be enabled for those builds. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] DTSA for 2.6.8 and 2.4.27
On Fri, Sep 09, 2005 at 08:05:58AM -0500, Micah Anderson wrote: Moritz Muehlenhoff schrieb am Friday, den 09. September 2005: Micah Anderson wrote: Neither of these advisories is a typical DTSA, as we normally we only do advisories for things that are blocked from reaching testing by some other issue, but I think that it would be good to do these two advisories because of the sheer number of security holes fixed as well as the necessary upgrade path that people need to take if they wish to maintain the integrity of their machines. Good idea, but I'd suggest to make a clean-sweep run over all kernel issues before. Some entries definitely need updating, (wrt to 2.4/2.6 You mean cross reference all the entries in CAN/list to make sure there isn't anything missing or still has a TODO label? mapping and IIRC Horms has some mails pending as well, he told me some days ago. I'll check with horms about any additional pending fixes. Other than 2.6.13.1, I do not have anything pending. But I could well have missed stuff. Actually, thats extremely likely. So please feel free to post missing patches. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Secure-testing-team] DTSA for 2.6.8 and 2.4.27
On Fri, Sep 09, 2005 at 02:49:18PM +0200, Moritz Muehlenhoff wrote: Micah Anderson wrote: I think it would be a good idea to get a DTSA (Debian Testing Security Advisory) issued for 2.4.27 and 2.6.8. Neither of these advisories is a typical DTSA, as we normally we only do advisories for things that are blocked from reaching testing by some other issue, but I think that it would be good to do these two advisories because of the sheer number of security holes fixed as well as the necessary upgrade path that people need to take if they wish to maintain the integrity of their machines. Good idea, but I'd suggest to make a clean-sweep run over all kernel issues before. Some entries definitely need updating, (wrt to 2.4/2.6 mapping and IIRC Horms has some mails pending as well, he told me some days ago. Also several more issues should receive a CVE mapping. Wrt keeping a complete history we should also move the entries based on older kernel-source packages to linux-2.6, as this will be the new permanent source package for 2.6 kernels. I also notice that 2.6.13.1 has now been released. This likely contains fixes relevant for us. Though I'm not sure which if any apply to our 2.4.27, 2.6.8 or 2.6.12. Nor, which ones are security problems. I'll look through it on Monday, unless someone gets there before me. I usually get the broken out patches from here, though 2.6.13.1 doesn't seem to be there, I'm not sure if that is a tempoary problem or not. http://www.kernel.org/git/?p=linux/kernel/git/chrisw/stable-queue.git;a=tree -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DTSA for 2.6.8 and 2.4.27
On Fri, Sep 09, 2005 at 08:30:39AM -0500, Micah Anderson wrote: Horms schrieb am Friday, den 09. September 2005: On Thu, Sep 08, 2005 at 09:17:25PM -0500, Micah Anderson wrote: Hi, I think it would be a good idea to get a DTSA (Debian Testing Security Advisory) issued for 2.4.27 and 2.6.8. That seems fine to me, at a glance. Though there have been some aditional bugs fixed in SVN. I have added the relevant patches to all trees that were effected, though as only 2.4.27 and 2.6.12 are reevant to this discussion. It might be a good time to spin 2.4.27-12 and get that into unstable. And linux-2.6 2.6.12-6, which was released earleier this week, should be up to date. If there are new security issues in SVN, definately spin out a new 2.4.27-12, but this brings up a question -- We haven't being doing DTSAs for every security hole that is fixed in unstable and naturally migrates to testing, at this point we are only doing them for those packages which can't enter testing on their own because they are blocked by something. The reason I was suggesting doing one for 2.4.27-11 was because there are a significant number of holes fixed in that release compared to previous, but since it migrates fine from unstable to testing, perhaps we shouldn't do a DTSA on it at all? Notifying testing users of security holes in all packages that enter testing from unstable is useful, but it may be too much of a burden on the team to issue advisories on them all. Do we want to be doing DTSAs for every new kernel version that comes out with security holes? If we do, we need to make a policy decision. Either we: 1. make it our policy to always do DTSAs for kernel security issues regardless if they enter testing naturally or not; or 2. make it our policy to do a DTSA for all packages that fix a significant number[1] of security issues because the significance of the threat is large enough to draw attention to the fix. Thoughts? I'm not sure, but almost every, if not every, kernel release will have security fixes given the current rate that they are being found and fixed - more than one a week, perhaps more than one a day. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
