Bug#857039: linux-latest: xen-linux-system packages
Source: linux-latest Version: 79 The changelog says: linux-latest (77) unstable; urgency=medium * Re-introduce xen-linux-system packages, accidentally dropped in version 75 But as of version 79, no xen-linux-system seems to be available, in particular xen-linux-system-amd64 The changelog entries of version 78 and 79 don't mention any removal. Were they accidentally dropped or was this on purpose? -- System Information: Debian Release: 8.7 APT prefers stable-updates APT policy: (600, 'stable-updates'), (600, 'stable'), (400, 'testing'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#628462: linux-2.6: reports impossible swap statistics for a process
Source: linux-2.6
Version: 2.6.32-26
Severity: normal
I'm not sure if the bug is in top or in linux. top reports that galeon
(my web browser) uses 195GB of swap; that's far more swap than I have,
so not possible.
The only out of the ordinary thing I remember doing is hibernating and
resuming several times.
I attach just about every info from /proc/${PID}/ which I thought
might be useful.
-- System Information:
Debian Release: squeeze/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'oldstable'), (500, 'stable'),
(400, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529074738.ga29...@doggy.mamane.lu
Bug#602418: Debian Squeeze Xen with Nouveau or Radeon: Test packages
On Thu, Dec 23, 2010 at 02:14:13PM +, Ian Campbell wrote: I have put some test packages with the patches discussed further up the bug (less the pte_flags one as mentioned) at: http://xenbits.xen.org/people/ianc/2.6.32-29+xen0/ Please could you test and let me know how you get on. In particular if you use Nouveau, since I only have Radeon cards to hand. This combination works for me: ii firmware-linux-free 2.6.32-29+xen0 Binary firmware for various drivers in the Linux kernel ii linux-base 2.6.32-29+xen0 Linux image base package ii linux-image-2.6.32-5-xen-amd64 2.6.32-29+xen0 Linux 2.6.32 for 64-bit PCs, Xen dom0 support ii linux-libc-dev 2.6.32-26 Linux support headers for userspace development ii linux-support-2.6.32-5 2.6.32-29+xen0 Support files for Linux 2.6.32 ii xen-linux-system-2.6.32-5-xen-amd64 2.6.32-29+xen0 Xen system with Linux 2.6.32 on 64-bit PCs (meta-package) ii libdrm-nouveau1 2.4.21-1~squeeze3 Userspace interface to nouveau-specific kernel DRM services -- runtime ii xserver-xorg-video-nouveau 1:0.0.15+git20100329+7858345-5 X.Org X server -- Nouveau display driver (experimental) ii xorg 1:7.5+8 X.Org X Window System ii xserver-xorg 1:7.5+8 the X.Org X server ii xserver-xorg-core2:1.7.7-8 Xorg X server - core server ii libxenstore3.0 4.0.1-1 Xenstore communications library for Xen ii xen-hypervisor-4.0-amd64 4.0.1-1 The Xen Hypervisor on AMD64 ii xen-qemu-dm-4.0 4.0.1-1 Xen Qemu Device Model virtual machine hardware emulator ii xen-utils-4.04.0.1-1 XEN administrative tools ii xen-utils-common 4.0.0-1 XEN administrative tools - common files 01:00.0 VGA compatible controller: nVidia Corporation G84 [Quadro FX 370] (rev a1) (prog-if 00 [VGA controller]) Subsystem: nVidia Corporation Device 0491 -- Lionel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110103145101.ga26...@capsaicin.mamane.lu
Bug#602418: Debian Squeeze Xen with Nouveau or Radeon: Test packages
On Thu, Dec 23, 2010 at 02:14:13PM +, Ian Campbell wrote: I have put some test packages with the patches discussed further up the bug (...) Please could you test and let me know how you get on. In particular if you use Nouveau, since I only have Radeon cards to hand. I use nouveau, but this will have to wait until 2011. Lionel, one of your reports is regarding the nv driver. I'm assuming you were just running that because Nouveau didn't work for you (per the other bug). I don't know if these patches will help with nv or not but my advice would be to switch back to Nouveau in any case. I don't particularly care which one works. I was using nv before (with kernel 2.6.26-2-xen-amd64 and Xen 3.2.1); when I started to upgrade to kernel 2.6.32 and Xen 4.0, nv refused to load with a recent kernel (modesetting in effect), so I tried switching to nouveau, but hit this bug. I'm now using nouveau with kernel version 2.6.32-26+xen0, and that works nicely. -- Lionel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101223145239.ga32...@capsaicin.mamane.lu
Bug#602418: #601341, #602418 and #604096 seem to be duplicates
On Tue, Nov 23, 2010 at 10:41:57AM +0100, Alexander Kurtz wrote: The following bugs seem to be identical: #601341 #602418 #604096 They all seem to be fixed by this kernel: http://xenbits.xen.org/people/ianc/ I think it would be a good idea to *) merge them all *) assign to linux-2.6 *) mark as affecting xserver-xorg *) mark as patched *) possibly mark them as RC That's all fine by me (as reporter of #601341 and #602418). Possibly the patch tag is not adequate as the exact read-to-apply-to-the-Debian-package patch is not there, just one of the differences between the Debian package and http://xenbits.xen.org/people/ianc/ fixes this. -- Lionel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101123115651.ga15...@capsaicin.mamane.lu
Bug#602418: linux-image-2.6.32-5-xen-amd64: with xen 4.0, fork()/clone() fails with ENOMEM during X startup with nv driver
reassign 601341 linux-2.6 found 601341 2.6.32-27 thanks On Thu, Nov 18, 2010 at 09:33:11AM +, Ian Campbell wrote: On Thu, 2010-11-18 at 09:19 +0100, Lionel Elie Mamane wrote: On Thu, Nov 18, 2010 at 09:40:43AM +0200, Timo Juhani Lindfors wrote: Hmm. So you are running an X server in the dom0 or in a domU? In the dom0. Please could you try the kernel at http://xenbits.xen.org/people/ianc/ and see if it resolves your issue. It resolves my issue (bug #602418) and it _also_ resolves bug #601341 (X with nouveau driver). This seems to confirm that #601341 is a kernel bug, possibly the same as #602418. Leaving to maintainers the decision on whether to merge them or not. -- Lionel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101119211428.ga6...@capsaicin.mamane.lu
Bug#602418: linux-image-2.6.32-5-xen-amd64: with xen 4.0, fork()/clone() fails with ENOMEM during X startup with nv driver
On Thu, Nov 18, 2010 at 09:40:43AM +0200, Timo Juhani Lindfors wrote: Hmm. So you are running an X server in the dom0 or in a domU? In the dom0. -- Lionel -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101118081905.gc24...@capsaicin.mamane.lu
Bug#530376: linux-image-2.6.26-1-amd64: concurrent MD devices recovery = message flood in dmesg
Package: linux-image-2.6.26-1-amd64 Version: 2.6.26-13 Severity: normal Starting situation (all RAID arrays are Linux Software RAID, from the CONFIG_MD driver): /dev/md1, a (degraded) raid5 array made of /dev/sdb6 /dev/sdc6 /dev/md0, a (degraded) raid1 array made of /dev/sdb5 /dev/sdc5 The situation comes from a user (admin) error that removed /dev/sda, while I wanted to remove /dev/sdd (unused). I run mdadm --re-add /dev/md1 /dev/sda6 mdadm --re-add /dev/md0 /dev/sda5 Here's the dmesg: [ 287.696348] md: bindsda6 [ 287.708557] RAID5 conf printout: [ 287.708579] --- rd:3 wd:2 [ 287.708597] disk 0, o:1, dev:sda6 [ 287.708617] disk 1, o:1, dev:sdb6 [ 287.708639] disk 2, o:1, dev:sdc6 [ 287.712049] md: recovery of RAID array md1 [ 287.712049] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [ 287.712049] md: using maximum available idle IO bandwidth (but not more than 20 KB/sec) for recovery. [ 287.712049] md: using 128k window, over a total of 67376512 blocks. [ 333.778593] md: bindsda5 [ 333.816375] RAID1 conf printout: [ 333.816375] --- wd:2 rd:3 [ 333.816375] disk 0, wo:1, o:1, dev:sda5 [ 333.816375] disk 1, wo:0, o:1, dev:sdb5 [ 333.816375] disk 2, wo:0, o:1, dev:sdc5 [ 333.816375] md: delaying recovery of md0 until md1 has finished (they share one or more physical units) So far, so good. That's a good decision. Then, I start getting messages in my dmesg: [ 520.767789] INFO: task md0_resync:4960 blocked for more than 120 seconds. [ 520.767797] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 520.767800] md0_resyncD 8101c5545e70 0 4960 2 [ 520.767805] 8101c5545db0 0046 8101fe0ccad0 8101fe0ccad0 [ 520.767809] 8101fcf50b50 81037d09ec10 8101fcf50dd8 c5545d78 [ 520.767813] 81020561e880 8101c5545d98 80231a39 8101c5545d98 [ 520.767816] Call Trace: [ 520.767844] [80231a39] check_preempt_wakeup+0xbd/0xe9 [ 520.767864] [a01629ad] :md_mod:md_do_sync+0x224/0x908 [ 520.767872] [80248410] enqueue_hrtimer+0xd7/0xe4 [ 520.767878] [80248b86] hrtimer_start+0x112/0x134 [ 520.767882] [802290ba] hrtick_start_fair+0xfb/0x144 [ 520.767889] [8022f095] hrtick_set+0x9e/0xf7 [ 520.767895] [802461a9] autoremove_wake_function+0x0/0x2e [ 520.767912] [a01654b1] :md_mod:md_thread+0xd7/0xed [ 520.767927] [a01653da] :md_mod:md_thread+0x0/0xed [ 520.767931] [80246083] kthread+0x47/0x74 [ 520.767934] [80230196] schedule_tail+0x27/0x5c [ 520.767939] [8020cf28] child_rip+0xa/0x12 [ 520.767952] [8024603c] kthread+0x0/0x74 [ 520.767955] [8020cf1e] child_rip+0x0/0x12 [ 520.767959] [ 654.984546] INFO: task md0_resync:4960 blocked for more than 120 seconds. [ 654.984553] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 654.984556] md0_resyncD 8101c5545e70 0 4960 2 [ 654.984560] 8101c5545db0 0046 8101fe0ccad0 8101fe0ccad0 [ 654.984565] 8101fcf50b50 81037d09ec10 8101fcf50dd8 c5545d78 [ 654.984569] 81020561e880 8101c5545d98 80231a39 8101c5545d98 [ 654.984572] Call Trace: [ 654.984597] [80231a39] check_preempt_wakeup+0xbd/0xe9 [ 654.984616] [a01629ad] :md_mod:md_do_sync+0x224/0x908 [ 654.984624] [80248410] enqueue_hrtimer+0xd7/0xe4 [ 654.984630] [80248b86] hrtimer_start+0x112/0x134 [ 654.984634] [802290ba] hrtick_start_fair+0xfb/0x144 [ 654.984641] [8022f095] hrtick_set+0x9e/0xf7 [ 654.984647] [802461a9] autoremove_wake_function+0x0/0x2e [ 654.984664] [a01654b1] :md_mod:md_thread+0xd7/0xed [ 654.984679] [a01653da] :md_mod:md_thread+0x0/0xed [ 654.984683] [80246083] kthread+0x47/0x74 [ 654.984686] [80230196] schedule_tail+0x27/0x5c [ 654.984691] [8020cf28] child_rip+0xa/0x12 [ 654.984704] [8024603c] kthread+0x0/0x74 [ 654.984707] [8020cf1e] child_rip+0x0/0x12 [ 654.984711] [ 925.567403] INFO: task md0_resync:4960 blocked for more than 120 seconds. [ 925.567413] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 925.567416] md0_resyncD 8101c5545e70 0 4960 2 [ 925.567421] 8101c5545db0 0046 8101fe0ccad0 8101fe0ccad0 [ 925.567425] 8101fcf50b50 81037d09ec10 8101fcf50dd8 c5545d78 [ 925.567429] 81020561e880 8101c5545d98 80231a39 8101c5545d98 [ 925.567433] Call Trace: [ 925.567473] [80231a39] check_preempt_wakeup+0xbd/0xe9 [ 925.567496] [a01629ad] :md_mod:md_do_sync+0x224/0x908 [ 925.567504] [80248410] enqueue_hrtimer+0xd7/0xe4 [ 925.567511] [80248b86] hrtimer_start+0x112/0x134 [ 925.567515] [802290ba] hrtick_start_fair+0xfb/0x144 [
Bug#515125: general: cpu frequency scaling crashes my system
Forwarding information sent to me personally about this bug. ---BeginMessage--- On Sat, 14 Feb 2009 07:10:36 +0100, Lionel Elie Mamane lio...@mamane.lu wrote: reassign 515125 linux-2.6 thanks Hi, Thank you for your bug report. On Fri, Feb 13, 2009 at 08:13:45PM +0100, Mark Poks wrote: i am not sure what exacly causes the problem. it maight be cpufreq, or kernel or maybe something else (or CPU Frequency Scalling Monitor applet in GNOME which is rather in doubt). when enabled AMD Quiet'n'cool in BIOS (the CPU frequency scalling) and have installed CPUFreq package, it very often happens that system crashes totally. Well, the most likely is either the kernel, or a bug in your BIOS. I'm reassigning this bug to the kernel package so that the experts on this can take a look at this. What CPU, motherboard and BIOS version do you have exactly? Please send us the contents of the files /proc/cpuinfo, /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor and /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver, as well as the output of the command lsmod (all this taken when AMD Quiet'n'cool is enabled in the kernel). The BIOS version is shown on the boot screen, before grub (or lilo), usually on the third / fourth line or something like that. You may also try to see if there is a BIOS update available for your motherboard; it may solve the problem. -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686-bigmem (SMP w/2 CPU cores) Hi, my mainboard is: ASUS M2N32 WS Professional AwardBIOS v6.00PG, 05/05/2008-C51XEMCP55PXE-M2N32-WS-00. cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor userspace userspace (this is default, but last time my machine crashed i have changed manually to 'ondemand') cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver powernow-k8 cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ stepping: 3 cpu MHz : 2800.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 5630.14 clflush size: 64 power management: ts fid vid ttp tm stc processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 67 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ stepping: 3 cpu MHz : 2800.000 cache size : 1024 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 5630.14 clflush size: 64 power management: ts fid vid ttp tm stc cpufreq-info cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to cpuf...@lists.linux.org.uk, please. analyzing CPU 0: driver: powernow-k8 CPUs which need to switch frequency at the same time: 0 1 hardware limits: 1000 MHz - 3.00 GHz available frequency steps: 3.00 GHz, 2.80 GHz, 2.60 GHz, 2.40 GHz, 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz available cpufreq governors: conservative, powersave, ondemand, userspace, performance current policy: frequency should be within 1000 MHz and 3.00 GHz. The governor userspace may decide which speed to use within this range. current CPU frequency is 2.80 GHz. cpufreq stats: 3.00 GHz:1.52%, 2.80 GHz:0.94%, 2.60 GHz:0.75%, 2.40 GHz:0.92%, 2.20 GHz:0.84%, 2.00 GHz:0.79%, 1.80 GHz:0.79%, 1000 MHz:93.45% (410) analyzing CPU 1: driver: powernow-k8 CPUs which need to switch frequency at the same time: 0 1 hardware limits: 1000 MHz - 3.00 GHz available frequency steps: 3.00 GHz, 2.80 GHz, 2.60 GHz, 2.40 GHz, 2.20 GHz, 2.00 GHz, 1.80 GHz, 1000 MHz available cpufreq governors: conservative, powersave, ondemand, userspace, performance current policy: frequency should be within 1000 MHz and 3.00 GHz. The governor userspace may decide which speed to use within this range. current CPU frequency is 2.80 GHz
Bug#472263: Bug #472263: probably linked to mISDN
On Sun, Dec 21, 2008 at 12:37:27AM +0100, Moritz Muehlenhoff wrote: On Mon, Mar 24, 2008 at 03:59:51PM +0100, Lionel Elie Mamane wrote: Further experience shows that the errors / lockups come only after using the mISDN ports; it may not be a bug in the kernel proper, only mISDN somehow corrupting an internal data structure which leads to the lockup later. It may also be a problem of the sort that mISDN calls some kernel interface incorrectly, which corrupts said data structure. Frankly, I don't know. Does this error still occur with the Lenny kernel? Yes. syslog entries attached. If so, you could try 2.6.28, since misdn has been merged into mainline since 2.6.27. The mISDN merged into 2.6.27 is mISDN v2, while the problem appears with mISDN v1.1.8~git.20081226 (and previous versions of mISDN). And the userspace application that triggers the problem (asterisk with chan_misdn) does not yet support mISDN v2. It is not really a big problem for me anyway, because I can just use zaptel/dahdi instead of mISDN to do what I need to do with the hardware... -- Lionel [7745018.127033] kobject (81007c8b59a8): tried to init an initialized object, something is seriously wrong. [7745018.138150] Pid: 11304, comm: mISDNd Not tainted 2.6.26-1-amd64 #1 [7745018.145374] [7745018.145375] Call Trace: [7745018.149690] [8031acea] kobject_init+0x39/0x69 [7745018.155183] [803829d2] device_initialize+0x25/0xb5 [7745018.161107] [8038322e] device_register+0x9/0x12 [7745018.169119] [a02c15bb] :mISDN_core:mISDN_register_sysfs_inst+0x3b/0x8c [7745018.176784] [a02bbda3] :mISDN_core:register_layer+0x202/0x22f [7745018.183767] [a02ba345] :mISDN_core:mISDN_ctrl+0x12c/0x5e4 [7745018.189446] [a02bb4ca] :mISDN_core:set_stack+0x104/0x214 [7745018.195986] [a02ba502] :mISDN_core:mISDN_ctrl+0x2e9/0x5e4 [7745018.202426] [a02baf8f] :mISDN_core:mISDNd+0x15d/0x26e [7745018.210418] [80246021] autoremove_wake_function+0x0/0x2e [7745018.216869] [8020cef8] child_rip+0xa/0x12 [7745018.222027] [a02bae32] :mISDN_core:mISDNd+0x0/0x26e [7745018.226755] [8020ceee] child_rip+0x0/0x12 [7745018.234757] [7745064.275911] DSS1 1 Restart 80 [7745064.275911] DSS1 1 Resetting channel [7745064.275911] [7745145.303899] kobject (81007c8b59a8): tried to init an initialized object, something is seriously wrong. [7745145.311905] Pid: 11304, comm: mISDNd Not tainted 2.6.26-1-amd64 #1 [7745145.321928] [7745145.321929] Call Trace: [7745145.327784] [8031acea] kobject_init+0x39/0x69 [7745145.333272] [803829d2] device_initialize+0x25/0xb5 [7745145.339190] [8038322e] device_register+0x9/0x12 [7745145.345575] [a02c15bb] :mISDN_core:mISDN_register_sysfs_inst+0x3b/0x8c [7745145.353630] [a02bbda3] :mISDN_core:register_layer+0x202/0x22f [7745145.361861] [a02ba345] :mISDN_core:mISDN_ctrl+0x12c/0x5e4 [7745145.368310] [a02bb4ca] :mISDN_core:set_stack+0x104/0x214 [7745145.374850] [a02ba502] :mISDN_core:mISDN_ctrl+0x2e9/0x5e4 [7745145.381307] [a02baf8f] :mISDN_core:mISDNd+0x15d/0x26e [7745145.387838] [80246021] autoremove_wake_function+0x0/0x2e [7745145.395221] [8020cef8] child_rip+0xa/0x12 [7745145.400686] [a02bae32] :mISDN_core:mISDNd+0x0/0x26e [7745145.406690] [8020ceee] child_rip+0x0/0x12 [7745145.412908] [7745375.304808] kobject (81007c8b59a8): tried to init an initialized object, something is seriously wrong. [7745375.312814] Pid: 11304, comm: mISDNd Not tainted 2.6.26-1-amd64 #1 [7745375.322870] [7745375.322871] Call Trace: [7745375.328691] [8031acea] kobject_init+0x39/0x69 [7745375.334181] [803829d2] device_initialize+0x25/0xb5 [7745375.338474] [8038322e] device_register+0x9/0x12 [7745375.344150] [a02c15bb] :mISDN_core:mISDN_register_sysfs_inst+0x3b/0x8c [7745375.352916] [a02bbda3] :mISDN_core:register_layer+0x202/0x22f [7745375.361147] [a02ba345] :mISDN_core:mISDN_ctrl+0x12c/0x5e4 [7745375.367683] [a02bb4ca] :mISDN_core:set_stack+0x104/0x214 [7745375.374573] [a02ba502] :mISDN_core:mISDN_ctrl+0x2e9/0x5e4 [7745375.381030] [a02baf8f] :mISDN_core:mISDNd+0x15d/0x26e [7745375.387563] [80246021] autoremove_wake_function+0x0/0x2e [7745375.394921] [8020cef8] child_rip+0xa/0x12 [7745375.400388] [a02bae32] :mISDN_core:mISDNd+0x0/0x26e [7745375.406392] [8020ceee] child_rip+0x0/0x12 [7745375.412606] [7745389.630812] kobject (81007c8b59a8): tried to init an initialized object, something is seriously wrong. [7745389.645530] Pid: 11304, comm: mISDNd Not tainted 2.6.26-1-amd64 #1 [7745389.653530] [7745389.653531] Call Trace: [7745389.656584] [8031acea] kobject_init+0x39/0x69 [7745389.662079] [803829d2] device_initialize+0x25/0xb5 [7745389.668003] [8038322e] device_register+0x9/0x12
Bug#507725: squashfs-modules-2.6-686: please enable SquashFS 1.0 support
Package: squashfs-modules-2.6-686 Version: 2:2.6.26-4 Severity: wishlist [EMAIL PROTECTED]:~/EMINENT$ sudo mount -t squashfs -o loop 0 /mnt/ mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so [EMAIL PROTECTED]:~/EMINENT$ dmesg |tail -n2 [43287.986603] SQUASHFS error: Major/Minor mismatch, Squashfs 1.0 filesystems are unsupported [43287.986619] SQUASHFS error: Please recompile with Squashfs 1.0 support enabled Would it be possible to do so by default? Thanks in advance. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages squashfs-modules-2.6-686 depends on: ii linux-image-2.6-686 [linux- 2.6.26+16Linux 2.6 image on PPro/Celeron/PI ii squashfs-modules-2.6.26-1-6 2.6.26+3.3-4 Compression filesystem for Linux 2 squashfs-modules-2.6-686 recommends no packages. squashfs-modules-2.6-686 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411839: linux-2.6: IPv6 PMTU table not garbage collected?
On Fri, Jul 04, 2008 at 10:54:03PM +0200, maximilian attems wrote: can you still reproduce that with an uptodate kernel at best 2.6.25? it has newer ipv6 with more features and fixes? I haven't encountered the problem in a long time. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472263: Bug #472263: probably linked to mISDN
Further experience shows that the errors / lockups come only after using the mISDN ports; it may not be a bug in the kernel proper, only mISDN somehow corrupting an internal data structure which leads to the lockup later. It may also be a problem of the sort that mISDN calls some kernel interface incorrectly, which corrupts said data structure. Frankly, I don't know. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472263: linux-image-2.6.24-1-amd64: kernel BUG at mm/slab.c:3008; invalid opcode: 0000 [1] SMP
Package: linux-image-2.6.24-1-amd64 Version: 2.6.24-4 Got the following error at a seemingly random point in time. Then, one of my SSH sessions froze, but IP routing and the other SSH session on the machine were still working OK. A sudo reboot froze the remaining session. [ cut here ] kernel BUG at mm/slab.c:3008! invalid opcode: [1] SMP CPU 0 Modules linked in: ztdummy zaptel crc_ccitt mISDN_dsp_kb1ec mISDN_dsp_mg2ec mISDN_dsp_mec2 mISDN_dsp hfcmulti mISDN_capi l3udss1 mISDN_l2 mISDN_l1 mISDN_core ca pi capifs kernelcapi tcp_diag inet_diag ip6table_filter ip6_tables ppdev parport_pc lp parport tun sit tunnel4 ac battery ipv6 xt_state ipt_MASQUERADE ipt_LOG x t_tcpudp iptable_mangle iptable_filter iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack deflate zlib_deflate zlib_inflate twofish twofish_co mmon camellia serpent blowfish des_generic cbc ecb blkcipher aes_generic aes_x86_64 xcbc sha256_generic sha1_generic crypto_null af_key ext2 eeprom 8021q snd_hd a_intel floppy snd_pcm snd_timer snd k8temp pcspkr soundcore snd_page_alloc i2c_nforce2 button i2c_core sg sr_mod evdev cdrom ext3 jbd mbcache dm_mirror dm_snap shot dm_mod ide_generic sd_mod ata_generic sata_nv libata scsi_mod firewire_ohci firewire_core crc_itu_t forcedeth generic amd74xx ehci_hcd ide_core ohci_hcd th ermal processor fan Pid: 24196, comm: sshd Not tainted 2.6.24-1-amd64 #1 RIP: 0010:[80292ee8] [80292ee8] cache_alloc_refill+0xc4/0x1db RSP: 0018:8100229addc8 EFLAGS: 00010046 RAX: 0070 RBX: 0012 RCX: 0007 RDX: 81002404c000 RSI: 8100229a RDI: 81007dc00080 RBP: 8100229a R08: 81007dc12000 R09: 81007dc16000 R10: 8100229ade28 R11: 1bc67b9a6138 R12: 81007dc06340 R13: 81007dc12000 R14: 002a R15: 81007dc00080 FS: 2b023a580800() GS:80513000() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2b023a13005b CR3: 03499000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process sshd (pid: 24196, threadinfo 8100229ac000, task 8100229d2800) Stack: 80d0 0282 81007dc00080 80d0 fffe 81007b9a6138 8029309d 0011 804eafe0 81007b9a6138 8030f45a Call Trace: [8029309d] __kmalloc+0x9e/0xe2 [8030f45a] kobject_get_path+0x42/0x99 [8030fc89] kobject_uevent_env+0xc2/0x3ca [802da379] sysfs_add_file+0x5b/0x81 [8023e55c] user_kobject_create+0xa0/0xa7 [8023e97c] alloc_uid+0xe1/0x185 [80241f3a] set_user+0x25/0xa8 [8024384c] sys_setreuid+0xc5/0x17c [8020be2e] system_call+0x7e/0x83 Code: 0f 0b eb fe 41 8b 5d 00 8b 54 24 04 48 89 ee 4c 89 ff e8 e2 RIP [80292ee8] cache_alloc_refill+0xc4/0x1db RSP 8100229addc8 ---[ end trace 8d4c214ed8a249b9 ]--- The following information has been collected after a reboot: [EMAIL PROTECTED]:~$ cat /proc/version Linux version 2.6.24-1-amd64 (Debian 2.6.24-4) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080114 (prerelease) (Debian 4.1.2-19)) #1 SMP Mon Feb 11 13:47:43 UTC 2008 [EMAIL PROTECTED]:~$ cat /proc/cmdline root=/dev/mapper/tikva-root ro console=ttyS0,115200n8 console=tty1 [EMAIL PROTECTED]:~$ cat /proc/sys/kernel/tainted 0 [EMAIL PROTECTED]:~$ lsmod Module Size Used by ppdev 13832 0 parport_pc 42408 0 lp 17476 0 parport44812 3 ppdev,parport_pc,lp tun16512 0 sit16424 0 tunnel4 8592 1 sit ac 11400 0 battery19976 0 ztdummy 9344 0 zaptel201032 3 ztdummy crc_ccitt 6656 1 zaptel ipv6 286248 61 sit xt_state7040 1 ipt_MASQUERADE 8448 2 ipt_LOG10880 19 xt_tcpudp 7936 10 iptable_mangle 7424 0 iptable_filter 7680 1 iptable_nat12036 1 ip_tables 25576 3 iptable_mangle,iptable_filter,iptable_nat nf_nat 25644 2 ipt_MASQUERADE,iptable_nat x_tables 24712 6 xt_state,ipt_MASQUERADE,ipt_LOG,xt_tcpudp,iptable_nat,ip_tables nf_conntrack_ipv4 24208 3 iptable_nat nf_conntrack 77936 5 xt_state,ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 deflate 8448 0 zlib_deflate 24088 1 deflate zlib_inflate 19328 1 deflate twofish11392 0 twofish_common 42240 1 twofish camellia 34432 0 serpent23040 0 blowfish 13184 0 des_generic21376 0 cbc
Bug#463223: initramfs-tools: missing dependency on mktemp? Fails to configure without it
Package: initramfs-tools Version: 0.91d Severity: serious Justification: Policy 3.5 On update/upgrade of a sid machine today, initramfs-tools failed to configure, because it tries to use mktemp, while it was not installed on that machine. If it needs it, it must depend on it. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381171: Not all Sound/Alsa devices are created properly under /dev/snd
reassign 408506 udev retitle 408506 /etc/udev/rules.dev/udev.rules symlink not always automatically created. thanks On Mon, Jan 07, 2008 at 01:11:35AM +0100, maximilian attems wrote: I get what seems to be similar problems with linux-image-2.6.18-4-686 as well as self-compiled kernels from Debian sources. can you try newer 2.6.22 from backports.org or 2.6.23 from unstable they install just fine in stable? they all have newer alsa. Did you intend to write that to me or to the original reporter of #381171, Eric Lavarde [EMAIL PROTECTED] ? Anyway, I still get the problem with a self-compiled kernel from 2.6.22-3 sources. Hmm... I have now found the source of the problem (in bug #408506). On machines where it works well, /etc/udev/rules.dev/udev.rules is symlinked to ../udev.rules, on machines where it doesn't, it is not the case. Adding the symlink solves the problem. So the bug is that the udev package did not add that symlink automatically in some install/upgrade scenario or removed it during an upgrade or ... -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381171: Bug#408506: Not all Sound/Alsa devices are created properly under /dev/snd
On Wed, Jan 16, 2008 at 04:30:52PM +0100, Marco d'Itri wrote: On Jan 16, Lionel Elie Mamane [EMAIL PROTECTED] wrote: Hmm... I have now found the source of the problem (in bug #408506). On machines where it works well, /etc/udev/rules.dev/udev.rules is symlinked to ../udev.rules, on machines where it doesn't, it is not the case. Adding the symlink solves the problem. So the bug is that the udev package did not add that symlink automatically in some install/upgrade scenario or removed it during an upgrade or ... I just do not believe this. Well, the situation is that on the machine where I was having the problem, there was no /etc/udev/rules.dev/udev.rules . Whether udev didn't put it (e.g. because the postinst script is not idempotent if interrupted at an arbitrary point), or whether it disappeared through disc corruption that did not break anything else, I cannot be sure. I symlinked it to ../udev.rules on that machine, and now udevtest /class/sound/controlC0 says: udev_rules_get_name: rule applied, 'controlC0' becomes 'snd/controlC0' which I understand as the problem is fixed. I haven't been in situation to reboot that machine yet to really test it. What is it that you just do not believe? That adding the symlink solves the problem or that the symlink was not there? The /dev/controlC0 bug is caused by broken rules shipped by another package which I cannot remember. Why does symlinking /etc/udev/rules.dev/udev.rules to ../udev.rules fix the problem then? -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438717: linux-2.6: net scheduling: filter attached to prio qdisc breaks priomap handling of packets it does _not_ match
Package: linux-2.6
Version: 2.6.22-3
Severity: normal
Attach: /home/master/prio_filter_map_fallback_test.sh
Subject area: network, packet schedulers (qdisc), filters for
classifying packets in classful qdiscs
When I attach a filter to a prio qdisc, the packets that it does _not_
match are not correctly handled (enqueued) according to the priomap
anymore, that is the same way than when there is no filter attached to
the qdisc.
For a concrete example, run the attached script (as root), trying to
ensure no other traffic happens over the interface: it installs qdiscs
on interface ${TIF} (defaults to eth0), pings host ${PHOST} (defaults
to master.debian.org - numerical IP hardcoded) with various IP TOS
bits set, installs a filter that matches TCP (_not_ ICMP) and does the
pings again.
Notice how the first pings (before filters get installed) get in the
right queue according to their TOS bits, but after the filter gets
installed, they all end up in the best effort queue.
The output I get (non-relevant bits snipped out) is:
Running test on interface eth0
by pinging host 70.103.162.29
Pinging with normal service 1 times
Pinging with minimise delay 2 times
Pinging with minimise cost 4 times
qdisc pfifo 22: parent 20:2 limit 1000p
Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 23: parent 20:3 limit 1000p
Sent 98 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 24: parent 20:4 limit 1000p
Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
Adding a filter that does _not_ match ICMP
Pinging with normal service 8 times
qdisc pfifo 22: parent 20:2 limit 1000p
Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 23: parent 20:3 limit 1000p
Sent 924 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 24: parent 20:4 limit 1000p
Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
Pinging with minimise delay 16 times
qdisc pfifo 22: parent 20:2 limit 1000p
Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 23: parent 20:3 limit 1000p
Sent 2492 bytes 26 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 24: parent 20:4 limit 1000p
Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
Pinging with minimise cost 32 times
qdisc pfifo 22: parent 20:2 limit 1000p
Sent 196 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 23: parent 20:3 limit 1000p
Sent 5628 bytes 58 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 24: parent 20:4 limit 1000p
Sent 392 bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
The output I would expect is:
(... snip ...)
Adding a filter that does _not_ match ICMP
Pinging with normal service 8 times
qdisc pfifo 22: parent 20:2 limit 1000p
Sent XXX bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 23: parent 20:3 limit 1000p
Sent XXX bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 24: parent 20:4 limit 1000p
Sent XXX bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
Pinging with minimise delay 16 times
qdisc pfifo 22: parent 20:2 limit 1000p
Sent XXX bytes 18 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 23: parent 20:3 limit 1000p
Sent XXX bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 24: parent 20:4 limit 1000p
Sent XXX bytes 4 pkt (dropped 0, overlimits 0 requeues 0)
Pinging with minimise cost 32 times
qdisc pfifo 22: parent 20:2 limit 1000p
Sent XXX bytes 18 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 23: parent 20:3 limit 1000p
Sent XXX bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
qdisc pfifo 24: parent 20:4 limit 1000p
Sent XXX bytes 36 pkt (dropped 0, overlimits 0 requeues 0)
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438717: bug 438717: test script
Looks like the attachment didn't make it through. Here it is. prio_filter_map_fallback_test.sh Description: Bourne shell script
Bug#381171: Similar problem with 2.6.18
I get what seems to be similar problems with linux-image-2.6.18-4-686 as well as self-compiled kernels from Debian sources. See bug#408506. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411839: linux-2.6: IPv6 PMTU table not garbage collected?
Package: linux-2.6 Version: 2.6.18-8 Severity: normal Symptoms: After a few weeks/months of uptime, my IPv6 machines whose IPv6 first hop link MTU is more than the minimum (1280) stop reacting to ICMPv6 too big packets and keep sending TCP packets above the MTU of the path to other hosts. Expected behaviour: After getting an ICMPv6 too big packet, send only packets smaller than the MTU in given in that ICMPv6 packet to this host. Analysis: I get the impression that the table where the kernel keeps the PMTU to the IPv6 hosts it communicates with overflows over time, after a few weeks or months of uptime. It looks like entries in that table expire (because I do get the too big packets problem with hosts my hosts communicate with a lot, they certainly were in the table in the past), but that the place taken by expired entries is not freed up. Thus the table doesn't get new entries added when the ICMPv6 too big packet comes in and the TCP stack doesn't go back to smaller packets. The symptoms seen by the users is that e.g. a SSH or SMTP connection gets established OK, but once they start doing something big with it (like the DATA phase of the SMTP dialogue or doing an ls of a big directory in a ssh session), the connexion freezes. Once that effect kicks in, it affects all new IPv6 connections/hosts. A tcpdump shows that ICMPv6 too big packets come in, but that my host keeps sending too big packets. A reboot cures it. I vaguely remember that the first time this happened, I found some statistics file in /proc/ or /sys/ where one line said some table had 4095 entries, which led me to this analysis. Alas, when it happened again I could not remember what file that was and can't find it again now. I didn't report it at the time because the kernel run by this machine is rather old. But now it happened on a machine running 2.6.18-3-amd64, and echo 8192 /proc/sys/net/ipv6/route/max_size seems to have helped the problem. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-amd64 Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402552: initramfs-tools: Invalid option to readlink: missing depends on newer version?
Package: initramfs-tools Version: 0.85b Severity: normal Setting up linux-image-2.6.18-3-686 (2.6.18-7) ... Hmm. The package shipped with a symbolic link /lib/modules/2.6.18-3-686/source However, I can not read the target: No such file or directory Therefore, I am deleting /lib/modules/2.6.18-3-686/source Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. readlink: invalid option -- m Try `readlink --help' for more information. readlink: invalid option -- m Try `readlink --help' for more information. initrd.img() points to (/boot/initrd.img-2.6.17-2-686) -- doing nothing at /var /lib/dpkg/info/linux-image-2.6.18-3-686.postinst line 585. readlink: invalid option -- m Try `readlink --help' for more information. readlink: invalid option -- m Try `readlink --help' for more information. vmlinuz() points to (/boot/vmlinuz-2.6.17-2-686) -- doing nothing at /var/lib/d pkg/info/linux-image-2.6.18-3-686.postinst line 585. Running postinst hook script /sbin/update-grub. -- Package-specific info: -- /proc/cmdline root=/dev/mapper/diskvg-rootlv ro console=ttyS1,115200n8 console=tty0 -- /proc/filesystems cramfs ext3 -- lsmod Module Size Used by ipv6 222304 20 ppdev 8516 0 lp 10852 0 smbfs 57176 3 tcp_diag1824 0 inet_diag 11048 5 tcp_diag dummy 2948 0 mousedev 10788 1 tsdev 7392 0 i2c_i8018236 0 i2c_core 19552 1 i2c_i801 parport_pc 32132 1 parport33160 3 ppdev,lp,parport_pc floppy 54276 0 i82875p_edac6244 0 edac_mc12964 1 i82875p_edac sg 30972 0 psmouse34600 0 serio_raw 6596 0 8250_pnp8704 0 evdev 9088 0 intel_agp 21116 1 agpgart29864 1 intel_agp shpchp 34272 0 pci_hotplug27196 1 shpchp pcspkr 3040 0 rtc12340 1 ext3 118568 2 jbd50292 1 ext3 mbcache 8324 1 ext3 dm_mirror 18928 0 dm_snapshot16032 0 dm_mod 50424 5 dm_mirror,dm_snapshot raid10 20928 0 raid6 102416 0 raid5 29824 1 xor14184 2 raid6,raid5 raid1 20416 1 raid0 7712 0 multipath 8224 0 linear 5504 0 md_mod 68916 9 raid10,raid6,raid5,raid1,raid0,multipath,linear ide_generic 1376 0 [permanent] sd_mod 18592 12 ide_cd 35680 0 cdrom 32448 1 ide_cd uhci_hcd 20424 0 ehci_hcd 28040 0 mptspi 16236 9 mptscsih 21504 1 mptspi e1000 100248 0 usbcore 111616 3 uhci_hcd,ehci_hcd mptbase46208 2 mptspi,mptscsih scsi_transport_spi 22176 1 mptspi scsi_mod 123080 5 sg,sd_mod,mptspi,mptscsih,scsi_transport_spi piix9476 0 [permanent] generic 4420 0 [permanent] ide_core 111016 4 ide_generic,ide_cd,piix,generic 3c59x 40232 0 mii 5312 1 3c59x thermal12904 0 processor 25512 1 thermal fan 4516 0 -- kernel-img.conf do_symlinks = yes relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = no postinst_hook = /sbin/update-grub postrm_hook = /sbin/update-grub -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (400, 'testing'), (300, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.17-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox-cvs-static20040623-1 Standalone rescue shell with tons ii cpio 2.5-1.3GNU cpio -- a program to manage ar ii klibc-utils 1.4.30-1 small statically-linked utilities ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo ii udev 0.103-1/dev/ and hotplug management daemo -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335505: Bug #335505 fixed in 0.44 (initramfs-tools: initramfs/conf/modules contains the list of current directory)
close 335505 0.44 thanks Reading the buglog, and the following entry in the changelog of the package: initramfs-tools (0.44) unstable; urgency=high O partigiano portami via * hooks/kernelextras: Really fix #335505. it seems that the bug was fixed in 0.44, but the maintainer used notfound instead of the close command to [EMAIL PROTECTED]; the notfound command just removes the information that the bug was found in 0.44, if such information was present. It does not record that the bug is fixed (not present) in 0.44. Hence, properly closing bug. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381677: initramfs-tools: Temporary files and initramfs world-readable
On Tue, Sep 12, 2006 at 04:06:20PM +0200, maximilian attems wrote: On Tue, 12 Sep 2006, Lionel Elie Mamane wrote: On Mon, Aug 14, 2006 at 03:11:39PM +0200, maximilian attems wrote: I've removed the patch tag, as the proposed patch is nacked, Except as outlined in [EMAIL PROTECTED], what's wrong with the patch proposed in [EMAIL PROTECTED] ? it adds an config option that has only a small scope to an existing conffile. OK, I understand now. so we need for your loop-aes pleasure a specific config dir for mkinitramfs UMASK setting, other packages may want to set BUSYBOX=yes there or whatever. Aren't /usr/share/initramfs-tools/conf.d/ and/or /etc/initramfs-tools/conf.d/ already such specific config dir? no they got source inside the initramfs on boot time, Ah yeah, right. what you want is a conf dir for build specific package specific settings. Actually, if we look at the details, I'm not sure the loopaes-utils package should unconditionally set the umask of initramfs-tools, as a significant portion of the users may have the package installed, but not an encrypted _root_ filesystem. So in the best case, we would want the loopaes hooks to be able to decide whether they touch the umask or not at runtime (runtime = building the initramfs), but this seems difficult at best. So, I suppose that the next best thing would be to give the _administrator_ a way to change the umask. But that's up to the maintainer of loopaes-utils, naturally. Max Vozeler? An opinion on that? -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381677: initramfs-tools: Temporary files and initramfs world-readable
On Mon, Aug 14, 2006 at 03:11:39PM +0200, maximilian attems wrote: I've removed the patch tag, as the proposed patch is nacked, Except as outlined in [EMAIL PROTECTED], what's wrong with the patch proposed in [EMAIL PROTECTED] ? so we need for your loop-aes pleasure a specific config dir for mkinitramfs UMASK setting, other packages may want to set BUSYBOX=yes there or whatever. Aren't /usr/share/initramfs-tools/conf.d/ and/or /etc/initramfs-tools/conf.d/ already such specific config dir? i'll prepare something that way for the next release, once 0.73e has hit testing. Thanks; waiting for it. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381677: initramfs-tools: Temporary files and initramfs world-readable
On Mon, Aug 14, 2006 at 01:26:50PM +0200, Max Vozeler wrote:
On Mon, Aug 14, 2006 at 09:26:04AM +0200, Lionel Elie Mamane wrote:
On Sat, Aug 12, 2006 at 10:43:16AM +0200, maximilian attems wrote:
also loop-aes is quite a specific use case, so i'm not in big
favour of setting the umask in general to the proposed value as in
general there is no gpg key in the initramfs.
Let's do it optionally then. New patch attached.
There is touch $2 in getopt parsing of the -o file option, which
can create the file before the umask setting takes effect. I think
we'd need to move the touch/readlink out of getopt to after the
umask setting, like attached (untested).
--- mkinitramfs.orig 2006-08-14 13:21:20.0 +0200
+++ mkinitramfs 2006-08-14 13:22:58.0 +0200
@@ -28,8 +28,7 @@
fi
;;
-o)
- touch $2
- outfile=$(readlink -f $2)
+ outfile=$2
shift 2
;;
-k)
@@ -95,6 +94,13 @@
fi
done
+if [ -n ${UMASK} ]; then
+ umask ${UMASK}
+fi
+
+touch $outfile
+outfile=$(readlink -f $outfile)
+
if [ -z ${outfile} ]; then
usage
fi
The added code block needs to be _after_ the
if [ -z ${outfile} ]; then
usage
fi
--
Lionel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381677: initramfs-tools: Temporary files and initramfs world-readable
On Sat, Aug 12, 2006 at 10:43:16AM +0200, maximilian attems wrote:
On Sun, 06 Aug 2006, Lionel Elie Mamane wrote:
The generated initramfs is world-readable (as well as the temporary
files); this leaks cryptographic keys (in password-protected form) to
all users on the system when the root fs is encrypted (because these
keys then get copied to the initramfs, at least in the loop-aes
case).
i like the initramfs-tools initrd.img to be debuggable as
user (quick check of their contents).
also loop-aes is quite a specific use case,
so i'm not in big favour of setting the umask in general
to the proposed value as in general there is no gpg key
in the initramfs.
Let's do it optionally then. New patch attached.
--
Lionel
diff --recursive -u initramfs-tools-0.73e/conf/initramfs.conf
initramfs-tools-0.73e.lionel/conf/initramfs.conf
--- initramfs-tools-0.73e/conf/initramfs.conf 2006-07-20 20:49:22.0
+0200
+++ initramfs-tools-0.73e.lionel/conf/initramfs.conf2006-08-14
09:23:23.904512135 +0200
@@ -52,3 +52,12 @@
NFSROOT=auto
+#
+# UMASK: 0nnn
+#
+# umask applied for temporary files and initramfs; you will probably
+# want to tighten it if the initramfs contains secrets such as
+# cryptographic keys (e.g. encrypted root).
+#
+UMASK=0022
+
diff --recursive -u initramfs-tools-0.73e/mkinitramfs
initramfs-tools-0.73e.lionel/mkinitramfs
--- initramfs-tools-0.73e/mkinitramfs 2006-08-13 10:03:36.0 +0200
+++ initramfs-tools-0.73e.lionel/mkinitramfs2006-08-14 09:20:01.766430453
+0200
@@ -98,6 +98,10 @@
usage
fi
+if [ -n ${UMASK} ]; then
+ umask ${UMASK}
+fi
+
# And by version we really mean path to kernel modules
# This is braindead, and exists to preserve the interface with mkinitrd
if [ ${#} -ne 1 ]; then
Bug#381677: initramfs-tools: Temporary files and initramfs world-readable
Package: initramfs-tools Version: 0.73b Tags: patch The generated initramfs is world-readable (as well as the temporary files); this leaks cryptographic keys (in password-protected form) to all users on the system when the root fs is encrypted (because these keys then get copied to the initramfs, at least in the loop-aes case). See bug #378488 for a discussion of this in the context of loop-aes. This patch fixes that. As making these files running user only readable does not, as far as I can see, hurt even when not strictly necessary, the patch just does it unconditionnaly. Please apply (or comment). Thanks. -- Lionel diff -uN --recursive initramfs-tools-0.73b/mkinitramfs initramfs-tools-0.73b.lionel/mkinitramfs --- initramfs-tools-0.73b/mkinitramfs 2006-07-29 13:05:20.0 +0200 +++ initramfs-tools-0.73b.lionel/mkinitramfs2006-08-06 14:44:51.0 +0200 @@ -1,6 +1,6 @@ #!/bin/sh -umask 0022 +umask 0077 # Defaults keep=n
Bug#378455: initramfs-tools: Option to disable fallback to shell on panic
Package: initramfs-tools
Severity: wishlist
Tags: patch
Here is a patch that adds a new configuration variable PANIC_SHELL
that, when set to no (not the default), disables the fallback to a
shell on panic. (Instead it makes init exit, and thus generates a
kernel panic.)
This is meant to be one link in a chain to secure a system as much as
convenient:
- Configure the BIOS to boot only from the hard drive
- Configure the boot loader not to let the user change boot
parameters
- This step: The boot process does not give a root shell to the
user, ever.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-amd64-k8-smp
Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
diff -Nru /tmp/uXrcEIMF0w/initramfs-tools-0.69b/conf/initramfs.conf
/tmp/dG2YS5smkE/initramfs-tools-0.69b.0/conf/initramfs.conf
--- /tmp/uXrcEIMF0w/initramfs-tools-0.69b/conf/initramfs.conf 2006-07-07
10:15:42.0 +0200
+++ /tmp/dG2YS5smkE/initramfs-tools-0.69b.0/conf/initramfs.conf 2006-07-16
14:30:43.0 +0200
@@ -45,3 +45,10 @@
NFSROOT=auto
+#
+# PANIC_SHELL: [ yes | no ]
+# Should init give the user a shell on panic?
+#
+
+PANIC_SHELL=yes
+
diff -Nru /tmp/uXrcEIMF0w/initramfs-tools-0.69b/debian/changelog
/tmp/dG2YS5smkE/initramfs-tools-0.69b.0/debian/changelog
--- /tmp/uXrcEIMF0w/initramfs-tools-0.69b/debian/changelog 2006-07-14
00:31:39.0 +0200
+++ /tmp/dG2YS5smkE/initramfs-tools-0.69b.0/debian/changelog2006-07-16
14:36:14.0 +0200
@@ -1,3 +1,9 @@
+initramfs-tools (0.69b.0) unstable; urgency=low
+
+ * Created an option to disable shell invocation on panic.
+
+ -- Lionel Elie Mamane [EMAIL PROTECTED] Sun, 16 Jul 2006 14:32:51 +0200
+
initramfs-tools (0.69b) unstable; urgency=high
* debian/initramfs-tools.preinst: Don't depend upon shipped directories
diff -Nru /tmp/uXrcEIMF0w/initramfs-tools-0.69b/scripts/functions
/tmp/dG2YS5smkE/initramfs-tools-0.69b.0/scripts/functions
--- /tmp/uXrcEIMF0w/initramfs-tools-0.69b/scripts/functions 2006-07-02
19:05:12.0 +0200
+++ /tmp/dG2YS5smkE/initramfs-tools-0.69b.0/scripts/functions 2006-07-16
14:27:33.0 +0200
@@ -59,10 +59,15 @@
if [ -x /sbin/usplash_write ]; then
/sbin/usplash_write QUIT
fi
- modprobe -q i8042
- modprobe -q atkbd
- echo $@
- PS1='(initramfs) ' /bin/sh /dev/console /dev/console 21
+if [ ${PANIC_SHELL} != no ]; then
+ modprobe -q i8042
+ modprobe -q atkbd
+ echo $@
+ PS1='(initramfs) ' /bin/sh /dev/console /dev/console 21
+ else
+ echo $@
+ exit 0
+ fi
}
maybe_break()
Bug#325704: Comments from AVM on Bug#325704
noowner 325704 thanks - Forwarded message from [EMAIL PROTECTED] - Subject: Re[2]: capi4hylafax: latest drivers? To: Lionel Elie Mamane [EMAIL PROTECTED] From: [EMAIL PROTECTED] Hi Lionel, this problem has another origin. While reconstructing kernel 2.6. the call of capilib_release_appl() was build into the _release_appl function of the active controllers (b1dma_release_appl(), b1_release_appl() and c4_release_appl()). The function capilib_release_appl() is executed in the response function of the controller. At this point the call is not only unnecessary, moreover it is dangerous since the calls of capilib.c are not secured against interrupt breaks. In short: Delete Calls to capilib_release_appl() in: drivers/isdn/harware/avm/b1.c:b1_release_appl() drivers/isdn/harware/avm/b1dma.c:b1dma_release_appl() drivers/isdn/harware/avm/c4.c:c4_release_appl() Regards Sven - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271315: kernel-image-2.6.8-2-sparc64: Breaks Type5c keyboard, too
Package: kernel-image-2.6.8-2-sparc64 Version: 2.6.8-6 Followup-For: Bug #271315 I confirm hitting this bug with a Type 5c keyboard, on an UltraSparc 5, too. Keymap is completely baroque, e.g. the delete key acts as enter, some Fn keys act as normal characters like u or n and $DEITY knows what key activated caps lock. 2.4.27-2-sparc64 kernel works OK. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268622: mkinitrd: Fails on modprobe warnings
On Sun, Aug 29, 2004 at 08:09:35PM +0100, Martin Michlmayr wrote: * Lionel Elie Mamane [EMAIL PROTECTED] [2004-08-28 15:04]: If modprobe issues warnings, mkinitrd thinks it has failed: Well, I guess it could ignore warnings... but why don't you just fix them? That's what I did to solve my immediate problem. It is still a bug, however, to fail in the face of warnings. That's why they are called warnings: not a failure. -- Lionel
Bug#268622: mkinitrd: Fails on modprobe warnings
Package: initrd-tools Version: 0.1.73 Severity: normal If modprobe issues warnings, mkinitrd thinks it has failed: /usr/sbin/mkinitrd: add_modules_dep_2_5: modprobe failed WARNING: Failed to open config file /etc/modprobe.d/alsa: No such file or directory WARNING: Failed to open config file /etc/modprobe.d/alsa: No such file or directory WARNING: Failed to open config file /etc/modprobe.d/alsa: No such file or directory Failed to create initrd image. The modprobe.err file says: WARNING: Failed to open config file /etc/modprobe.d/alsa: No such file or directory WARNING: Failed to open config file /etc/modprobe.d/alsa: No such file or directory WARNING: Failed to open config file /etc/modprobe.d/alsa: No such file or directory -- System Information: Debian Release: 3.0 APT prefers testing APT policy: (300, 'testing'), (200, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii cpio 2.4.2-39 GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.1-2The Debian Almquist Shell ii fileutils 4.1-10 GNU file management utilities ii util-linux2.11n-7Miscellaneous system utilities. -- no debconf information
