Bug#259886: /boot/vmlinuz-2.6.26-1-686: scsi tekram dc-390/lsi53c1010 no boot machine
Vivat! Sorry, ich bin dumb, problem closed. I attach SCSI terminators - and all work. But 2.6.18 work without terminators... -- Спасибо за внимание. Yoric. г. Новосибирск.
Bug#520379: linux-image-2.6.26-bpo.1-amd64: Lots of kernel messages about lockd and the number of nfsd threads
Package: linux-image-2.6.26-bpo.1-amd64 Version: 2.6.26-13~bpo40+1 Severity: normal Hi, I'm running the 2.6.26 kernel from backports on etch. The server in question is an NFS file server. During periods we're getting a lot of lockd: too many open connections, consider increasing the number of nfsd threads messages from the kernel. I've tried increasing the number of nfsd threads (from 128 to 256) but the messages still appear. The default number of nfsd threads is 8, so 128 (and 256) is a serious increase? When I googled for the string, I found a red hat bug report [1] that seems similar. It seems to conclude that the number of socket connections to lockd is capped at 80. I've tried to decrease the number of nfsd threads to 64 (to get below 80) but it doesn't help. Is the nfsd process talking to lockd or are the network clients directly talking to lockd? When I look at /proc/net/rpc/nfsd, the th line currently says: th 64 2 8262.856 627.240 81.384 21.208 6.680 4.968 3.188 0.476 31.744 0.000 which I believe means the number of nfsd threads were never used 100% (31.744 seconds at 80-90% capacity)? I tried to determine the number of active connections by looking for the port used by the lock manager using rpcinfo and then using netstat -an to see the connections to/from that port, but the number of connections is zero right now (but there are no messages being logged right now). Any ideas on how to further debug this? The server in question is one of our most loaded NFS servers and I haven't been able to reproduce this on a test server. I noticed that a snapshot kernel (2.6.26-14) on kernel-archive.buildserver.net mentions Backport upstream patches to fix NFS task blocked for more than 120 seconds issue in the changelog. Any chance this will also fix the lockd problem? Rebooting the server to try a bunch of kernels is not really an option, but one reboot should be possible in about a week. Regards, Rik [1] https://bugzilla.redhat.com/show_bug.cgi?id=457405 -- Package-specific info: ** Version: Linux version 2.6.26-bpo.1-amd64 (Debian 2.6.26-13~bpo40+1) (no...@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Mon Jan 12 12:26:02 UTC 2009 ** Command line: root=/dev/mapper/vglocal-root ro ** Not tainted ** Kernel log: [2582760.434812] lockd: too many open connections, consider increasing the number of nfsd threads [2582768.449568] lockd: too many open connections, consider increasing the number of nfsd threads [2582769.459376] lockd: too many open connections, consider increasing the number of nfsd threads [2582877.051217] lockd: too many open connections, consider increasing the number of nfsd threads [2582878.588940] lockd: too many open connections, consider increasing the number of nfsd threads [2582882.333982] lockd: too many open connections, consider increasing the number of nfsd threads [2582890.236297] lockd: too many open connections, consider increasing the number of nfsd threads [2582900.004939] lockd: too many open connections, consider increasing the number of nfsd threads [2582904.024497] lockd: too many open connections, consider increasing the number of nfsd threads [2582906.807805] lockd: too many open connections, consider increasing the number of nfsd threads [2582932.014436] lockd: too many open connections, consider increasing the number of nfsd threads [2582938.092144] lockd: too many open connections, consider increasing the number of nfsd threads [2582939.113474] lockd: too many open connections, consider increasing the number of nfsd threads [2582942.972879] lockd: too many open connections, consider increasing the number of nfsd threads [2582948.205182] lockd: too many open connections, consider increasing the number of nfsd threads [2582994.071922] lockd: too many open connections, consider increasing the number of nfsd threads [2583015.029338] lockd: too many open connections, consider increasing the number of nfsd threads [2583018.901170] lockd: too many open connections, consider increasing the number of nfsd threads [2583030.807122] lockd: too many open connections, consider increasing the number of nfsd threads [2583031.361386] lockd: too many open connections, consider increasing the number of nfsd threads [2583047.722268] lockd: too many open connections, consider increasing the number of nfsd threads [2583053.155262] lockd: too many open connections, consider increasing the number of nfsd threads [2583061.534054] lockd: too many open connections, consider increasing the number of nfsd threads [2583063.947798] lockd: too many open connections, consider increasing the number of nfsd threads [2583066.670525] lockd: too many open connections, consider increasing the number of nfsd threads [2583071.069884] lockd: too many open connections, consider increasing the number of nfsd threads [2583080.081877] lockd: too many open connections, consider increasing the number of nfsd
Processed: Re: Bug#511334: S390 boot fails on Flex-ES machine
Processing commands for cont...@bugs.debian.org: tags 511334 patch Bug#511334: debian-installer: S390 boot fails on Flex-ES machine There were no tags set. Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519800: Acknowledgement (FSTYPE=ext3 but only ext2 in ramdisk possible with MODULES=dep)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Mar 15, 2009 at 11:35:55AM +0100, Martin Michlmayr wrote: Actually, how about running fstype when generating the ramdisk to find out which modules you need (either in addition or instead of looking at the output of mount/fstab). I dislike the idea of a ramdisk generator deliberately ignoring something I've explicitly expressed in /etc/fstab. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAknCHCsACgkQn7DbMsAkQLiMPACUCS87zevdyT0Y8iIPMNnc6LXB VwCfdzBU9RBPepw6wB7WZ90DpQQAWVo= =RA4P -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#520379: linux-image-2.6.26-bpo.1-amd64: Lots of kernel messages about lockd and the number of nfsd threads
Processing commands for cont...@bugs.debian.org: reassign 520379 linux-2.6 Bug#520379: linux-image-2.6.26-bpo.1-amd64: Lots of kernel messages about lockd and the number of nfsd threads Warning: Unknown package 'linux-image-2.6.26-bpo.1-amd64' Bug reassigned from package `linux-image-2.6.26-bpo.1-amd64' to `linux-2.6'. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519800: Acknowledgement (FSTYPE=ext3 but only ext2 in ramdisk possible with MODULES=dep)
* Jonas Smedegaard d...@jones.dk [2009-03-19 11:19]: Actually, how about running fstype when generating the ramdisk to find out which modules you need (either in addition or instead of looking at the output of mount/fstab). I dislike the idea of a ramdisk generator deliberately ignoring something I've explicitly expressed in /etc/fstab. Well, then look at fstype in addition to the output of mount/fstab. The point is that the system won't boot if you only look at the output of mount/fstab. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503097: Fix for #503097
Hy Ola I had a similar problem; when a container ran out of memory the host crashed: [ 5030.259197] Fatal resource shortage: privvmpages, UB 1211. [ 5030.286759] Fatal resource shortage: privvmpages, UB 1211. [ 5030.308249] Fatal resource shortage: privvmpages, UB 1211. [ 5030.324705] Fatal resource shortage: privvmpages, UB 1211. [ 7086.059121] BUG: unable to handle kernel paging request at 810010895000 [ 7086.079122] IP: [810010895000] [ 7086.079122] PGD 8063 PUD 9063 PMD 8000108001e3 [ 7086.079122] Oops: 0011 [1] SMP .. . I can reproduce this bug with the official debian-kernel (linux-image-2.6.26-1-openvz-amd64). The updated kernel http://people.debian.org/~dannf/bugs/500876/linux-headers-2.6.26-1-openvz-amd64_2.6.26-14~dannf.1_amd64.deb fixes the problem: Instead of a kernel panic processes inside the container get killed (expected behaviour) . Thanks a lot! Will this fix go into the official kernel? If you need additional testing, oder some more kernel-traces, please let me know. Nik Lutz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501326: (no subject)
It works with latest kernel version. You can close it, thank you. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511334: S390 boot fails on Flex-ES machine
tags 511334 patch thanks On Thursday 19 March 2009, Adam Thornton wrote: This appears to fix the problem, in that I get much farther and then get stuck in the init-premount scripts because it can't vary my root disk online. But *that* is probably because, on this host, I've been using by-path disk IDs, and I'd been changing various kernel build parameters to roll the DASD drivers into the kernel (that is, not use them as modules). So that is very likely my fault. I suspect this issue is resolved. Get me an official kernel image build with it (and with the requisite modules) and I'll be happy to test, or I can build another one tomorrow (which will, alas, take all day again). Thanks for testing. There's no way I can get you an official fixed kernel on short notice. You'll have to build your own for now. Dann: Can you please consider the patch I linked to in [1] for stable updates of both .24 and .26? AFAICT the patch should apply cleanly to both as the broken code was introduced in .19. The patch also fixed two very hard to trace hangs in .28 and .29 where bisection lead to unrelated changes which just happened to trigger this bug in such a way that it caused a hang. TIA. [1] http://bugs.debian.org/511334#65 signature.asc Description: This is a digitally signed message part.
Processed: power button stops working after suspend
Processing commands for cont...@bugs.debian.org: tags 500506 +fixed-upstream Bug#500506: linux-image-2.6.25-2-686: power button stops working after suspend (irq 9: nobody cared) There were no tags set. Tags added: fixed-upstream -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519800: Acknowledgement (FSTYPE=ext3 but only ext2 in ramdisk possible with MODULES=dep)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Mar 19, 2009 at 11:30:40AM +0100, Martin Michlmayr wrote: * Jonas Smedegaard d...@jones.dk [2009-03-19 11:19]: Actually, how about running fstype when generating the ramdisk to find out which modules you need (either in addition or instead of looking at the output of mount/fstab). I dislike the idea of a ramdisk generator deliberately ignoring something I've explicitly expressed in /etc/fstab. Well, then look at fstype in addition to the output of mount/fstab. The point is that the system won't boot if you only look at the output of mount/fstab. Fine with me. My comment was driven by your or instead of alone :-) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknCJ7oACgkQn7DbMsAkQLiX+ACcCiDTvGNXVQ/Lspd6yojhMT7Z CbAAnRDDw7u51JhDH2b00hKWW3f8AC41 =L0v5 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: power button stops working after suspend
Processing commands for cont...@bugs.debian.org: forwarded 500506 http://bugzilla.kernel.org/show_bug.cgi?id=11665 Bug#500506: linux-image-2.6.25-2-686: power button stops working after suspend (irq 9: nobody cared) Noted your statement that Bug has been forwarded to http://bugzilla.kernel.org/show_bug.cgi?id=11665. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: block 519040 with 518115
Processing commands for cont...@bugs.debian.org: block 519040 with 518115 Bug#518115: Version for kernel 2.6.28 available at Bug#519040: linux-headers-2.6.28-1-686: depends on linux-kbuild but not available Was not blocked by any bugs. Blocking bugs of 519040 added: 518115 End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518115: Version for kernel 2.6.28 available at ....
On Wed, Mar 04, 2009 at 02:31:15AM -0600, Adam Majer wrote: Please don't close this bug until a real upload of linux-kbuild-2.6 can be made to unstable. Thanks for providing this package, which helps workaround #519040. But maybe, you could have pointed also to the reason why this problem exists currently ? Thanks in advance. Best regards, -- Olivier BERGER (OpenPGP: 1024D/B4C5F37F) http://www.olivierberger.com/weblog/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520409: linux-image-2.6.28-1-686: hangs on via padlock RNG module initialization
Package: linux-image-2.6.28-1-686 Version: 2.6.28-1 Severity: normal Whenever booting the kernel on my VIA mainboard, it hangs, and I need to CTRL-C the VIA RNG module initialization. The same problem seems to have been reported here : http://bugs.archlinux.org/task/12823 but couldn't google anything else on the subject. Best regards, -- Package-specific info: ** Version: Linux version 2.6.28-1-686 (Debian 2.6.28-1) (m...@debian.org) (gcc version 4.3.3 (Debian 4.3.3-4) ) #1 SMP Mon Feb 23 03:13:24 UTC 2009 ** Command line: root=/dev/hdd3 ro single ** Tainted: P W (513) ** Kernel log: [6.643547] EXT3-fs: write access will be enabled during recovery. [7.525412] kjournald starting. Commit interval 5 seconds [7.525505] EXT3-fs: recovery complete. [7.604455] EXT3-fs: mounted filesystem with ordered data mode. [8.417375] udevd version 125 started [ 10.970601] Linux agpgart interface v0.103 [ 11.006927] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 11.137633] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 11.205763] agpgart: Detected VIA CX700 chipset [ 11.216614] agpgart-via :00:00.0: AGP aperture is 128M @ 0xf000 [ 12.617329] input: PC Speaker as /devices/platform/pcspkr/input/input1 [ 13.146745] input: Power Button (FF) as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [ 13.156025] ACPI: Power Button (FF) [PWRF] [ 13.156305] input: Sleep Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input3 [ 13.170305] ACPI: Sleep Button (CM) [SLPB] [ 13.170607] input: Power Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input4 [ 13.188049] ACPI: Power Button (CM) [PWRB] [ 13.928203] input: ImPS/2 Generic Wheel Mouse as /devices/platform/i8042/serio1/input/input5 [ 14.299027] parport_pc 00:07: reported by Plug and Play ACPI [ 14.299134] parport0: PC-style at 0x378, irq 7 [PCSPP] [ 14.431417] ndiswrapper version 1.54 loaded (smp=yes, preempt=no) [ 15.670558] ndiswrapper: driver vnwl (VIA,07/21/2008,2.17.00.3000) loaded [ 15.671089] ndiswrapper :03:06.0: PCI INT A - GSI 19 (level, low) - IRQ 19 [ 15.677492] ndiswrapper: using IRQ 19 [ 16.456809] wlan0: ethernet device 00:18:02:06:4c:f2 using NDIS driver: vnwl, version: 0x20011, NDIS version: 0x500, vendor: 'VIA Networking Technologies PCI-Cardbus Wireless LAN Adapter ', 1106:3253.5.conf [ 16.456962] wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK [ 16.457168] usbcore: registered new interface driver ndiswrapper [ 17.189181] HDA Intel :02:01.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 17.189433] HDA Intel :02:01.0: setting latency timer to 64 [ 17.189443] HDA Intel :02:01.0: PCI: Disallowing DAC for device [ 20.488059] Adding 393584k swap on /dev/hdd2. Priority:-1 extents:1 across:393584k [ 20.698084] EXT3 FS on hdd3, internal journal [ 21.692031] loop: module loaded [ 21.766046] VIA RNG detected [ 21.795556] padlock: Using VIA PadLock ACE for AES algorithm. [ 144.536596] [ cut here ] [ 144.536660] WARNING: at crypto/algapi.c:293 crypto_wait_for_test+0x4b/0x53() [ 144.536722] Modules linked in: sha1_generic padlock_sha(+) padlock_aes aes_generic via_rng rng_core loop snd_hda_intel snd_pcm snd_seq snd_timer snd_seq_device snd evdev soundcore snd_page_alloc ndiswrapper parport_pc parport psmouse button serio_raw pcspkr i2c_viapro i2c_core via_agp shpchp pci_hotplug agpgart ext3 jbd mbcache ide_gd_mod ata_generic libata scsi_mod 8139too 8139cp mii uhci_hcd ehci_hcd via82cxxx ide_pci_generic usbcore ide_core thermal processor fan thermal_sys [ 144.538877] Pid: 1649, comm: modprobe Tainted: P 2.6.28-1-686 #1 [ 144.538938] Call Trace: [ 144.539004] [c0126dd9] warn_on_slowpath+0x40/0x61 [ 144.539067] [c0120f20] check_preempt_wakeup+0x138/0x171 [ 144.539129] [c0121f16] try_to_wake_up+0x168/0x172 [ 144.539193] [c02e5c92] schedule_timeout+0x14/0xbb [ 144.539267] [c013a302] notifier_call_chain+0x2a/0x47 [ 144.539332] [c02e700f] _spin_lock_irq+0x13/0x15 [ 144.539392] [c02e5384] wait_for_common+0x111/0x12d [ 144.539453] [c0121f20] default_wake_function+0x0/0x8 [ 144.539514] [c01e5087] crypto_wait_for_test+0x4b/0x53 [ 144.539576] [c01e5158] crypto_register_alg+0x3f/0x44 [ 144.539644] [dc995000] padlock_init+0x0/0x68 [padlock_sha] [ 144.539707] [dc995032] padlock_init+0x32/0x68 [padlock_sha] [ 144.539770] [dc995000] padlock_init+0x0/0x68 [padlock_sha] [ 144.539832] [c0101138] _stext+0x50/0x17a [ 144.539897] [c01461d0] load_module+0x15ef/0x177b [ 144.539979] [c0176238] vma_link+0x51/0x75 [ 144.540050] [c0176253] vma_link+0x6c/0x75 [ 144.540127] [c013a56a] blocking_notifier_call_chain+0x9/0xc [ 144.540193] [c0146499] sys_init_module+0x87/0x174 [ 144.540256] [c01038e3] sysenter_do_call+0x12/0x2f [ 144.540315] ---[ end trace 2d77b5519b6ee597 ]--- [ 144.540536] [ cut
Bug#520409: linux-image-2.6.28-1-686: hangs on via padlock RNG module initialization
On Thu, Mar 19, 2009 at 02:25:37PM +0100, Olivier Berger wrote: Whenever booting the kernel on my VIA mainboard, it hangs, and I need to CTRL-C the VIA RNG module initialization. The same problem seems to have been reported here : http://bugs.archlinux.org/task/12823 but couldn't google anything else on the subject. Best regards, FYI, commenting padlock_aes and padlock_sha in /etc/modules (and leaving via_rng) worked around the issue (also this worked fine with 2.6.26 from stable). Best regards, -- Olivier BERGER (OpenPGP: 1024D/B4C5F37F) http://www.olivierberger.com/weblog/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: tagging 497717
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.9.26etch2 tags 497717 + pending Bug#497717: firmware-iwlwifi: Please include the ucode for the new 5000-series cards Tags were: patch Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
firmware-nonfree 0.15 upload
hello, announcing upload for tommorrow lunch time. there are enough new goodies waiting in repo, won't reproduce changelog here. known blocker: * bnx2 update for 2.6.29 by dannf kind regards -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: initramfs-tools: must support relative paths in modules.dep
Recently kernels I built from upstream kernel source failed to boot after unpacking them because no modules got included in the initramfs initrd (and thus no root file system). This problem was solved after downgrading to m-i-t 3.4.1. how can i reproduce this? upgraded to latest m-i-t 3.7-pre9-1 and run depmod + mkinitramfs. the generated initramfs had all modules i expect it to have. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: initramfs-tools: must support relative paths in modules.dep
On Thursday 19 March 2009, maximilian attems wrote: Recently kernels I built from upstream kernel source failed to boot after unpacking them because no modules got included in the initramfs initrd (and thus no root file system). This problem was solved after downgrading to m-i-t 3.4.1. how can i reproduce this? upgraded to latest m-i-t 3.7-pre9-1 and run depmod + mkinitramfs. the generated initramfs had all modules i expect it to have. You have to build a kernel from source while having the new m-i-t installed. And then install that kernel *without* running depmod (which is currently also not done by i-t). If you do run an extra depmod manually before calling i-t the problem will have fixed itself because depmod is then called differently than during the kernel build. I saw this issue after installing a kernel built from upstream source using 'fakeroot make deb-pkg' (i.e. without using kernel-package or anything). With the stable version of m-i-t kernels built that way install perfectly (using custom hook scripts to create the initrd and update grub etc.). You can probably also reproduce it by running the following sequence of commands, which should emulate the way the upstream kernel Makefile calls depmod (using any kernel version you have installed for kvers): # kvers=kvers # mkdir -p /tmp/lib/modules # cp -r /lib/modules/$kvers /tmp/lib/modules/ # rm /tmp/lib/modules/$kvers/modules.* # depmod -ae -F /boot/System.map-$kvers -b /tmp/ -r $kvers The file /tmp/lib/modules/kvers/modules.dep should then show the problem. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[Fwd: Firmware package]
This just showed up in my inbox from David Woodhouse, and he's given me permission to forward it to the list. I invited him to show up on #debian-kernel on IRC and he's there now. Would be very cool if Fedora and Debian can agree on a consistent way of packaging and delivering kernel firmware... Bdale ---BeginMessage--- Fedora is currently shipping a 'kernel-firmware' package built from the kernel itself, with only the firmware which has been _extracted_ from older drivers which used to build it in. The git repository at http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git has a bunch of extra stuff; we've just got permission from Conexant to include their firmware, for example, and we've been collecting a few other things from people who didn't want to include their firmware in the GPL'd kernel, but _are_ happy to include it in a separate package with just 'redistributable' licence. So that we can ship this extra firmware, I've submitted a new package for Fedora review, called 'kernel-firmware', which is intended to replace the existing kernel-firmware which is built as a sub-package of the kernel itself. https://bugzilla.redhat.com/show_bug.cgi?id=491090 What's the situation with Debian? Can/should we do something similar there? -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ---End Message---
Bug#518412: initramfs-tools: must support relative paths in modules.dep
On Thursday 19 March 2009, maximilian attems wrote: thanks for quick feedback. On Thu, Mar 19, 2009 at 05:15:06PM +0100, Frans Pop wrote: You have to build a kernel from source while having the new m-i-t installed. And then install that kernel *without* running depmod (which is currently also not done by i-t). well linux-2.6 images postinst and even k-p do this, so this quite arguiably a bug in make deb-pkg. No. deb-pkg CANNOT do this because it is executed on the system building the kernel and the extra depmod would need to be run on the system where the kernel is installed. So *at most* my custom hook scripts that get executed when the kernel is installed would be at fault for not doing the extra depmod (and I could easily change them to do that, but that would be only solving the problem for me and not for everybody else). However, IMO a modules.dep file created by the upstream kernel Makefile using an official version of m-i-t should be assumed to be valid and should thus be supported by i-t. If the file is not valid, then there would be a bug in m-i-t, but Marco has argued that it is not. You can probably also reproduce it by running the following sequence of commands, which should emulate the way the upstream kernel Makefile calls depmod (using any kernel version you have installed for kvers): # kvers=kvers # mkdir -p /tmp/lib/modules # cp -r /lib/modules/$kvers /tmp/lib/modules/ # rm /tmp/lib/modules/$kvers/modules.* # depmod -ae -F /boot/System.map-$kvers -b /tmp/ -r $kvers The file /tmp/lib/modules/kvers/modules.dep should then show the problem. copied over that file and saw still no sign of a trouble: mkinitramfs -v -o /tmp/foo | head -n 12 Are you sure you have the new version of m-i-t installed? Did you check the contents of the generated modules.dep file? Maybe my command was broken though. I did not check it as I've put m-i-t on hold on all my machines. I'll check the actual command executed by the kernel later. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: initramfs-tools: must support relative paths in modules.dep
thanks for quick feedback. On Thu, Mar 19, 2009 at 05:15:06PM +0100, Frans Pop wrote: You have to build a kernel from source while having the new m-i-t installed. And then install that kernel *without* running depmod (which is currently also not done by i-t). well linux-2.6 images postinst and even k-p do this, so this quite arguiably a bug in make deb-pkg. If you do run an extra depmod manually before calling i-t the problem will have fixed itself because depmod is then called differently than during the kernel build. I saw this issue after installing a kernel built from upstream source using 'fakeroot make deb-pkg' (i.e. without using kernel-package or anything). With the stable version of m-i-t kernels built that way install perfectly (using custom hook scripts to create the initrd and update grub etc.). You can probably also reproduce it by running the following sequence of commands, which should emulate the way the upstream kernel Makefile calls depmod (using any kernel version you have installed for kvers): # kvers=kvers # mkdir -p /tmp/lib/modules # cp -r /lib/modules/$kvers /tmp/lib/modules/ # rm /tmp/lib/modules/$kvers/modules.* # depmod -ae -F /boot/System.map-$kvers -b /tmp/ -r $kvers The file /tmp/lib/modules/kvers/modules.dep should then show the problem. copied over that file and saw still no sign of a trouble: mkinitramfs -v -o /tmp/foo | head -n 12 Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/usb/host/ehci-hcd.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/usb/host/ohci-hcd.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/usb/host/uhci-hcd.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/hid/hid.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/hid/usbhid/usbhid.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/hid/hid-a4tech.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/hid/hid-apple.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/hid/hid-belkin.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/hid/hid-cherry.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/hid/hid-chicony.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/hid/hid-cypress.ko Adding module /lib/modules/2.6.29-rc8-amd64/kernel/drivers/hid/hid-ezkey.ko testbooted fine in qemu. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: initramfs-tools: must support relative paths in modules.dep
On Thursday 19 March 2009, maximilian attems wrote: copied over that file and saw still no sign of a trouble: mkinitramfs -v -o /tmp/foo | head -n 12 Here's the actual depmod command executed during a kernel build: /sbin/depmod -ae -F System.map -b /home/fjp/projects/kernel/builds/amd64/debian/tmp 2.6.29-rc8-rjw So, the (undocumented?) -r option is not there. But even with the -r the commands I gave work for me to reproduce the broken modules.dep file: f...@thorin:~$ apt-cache show module-init-tools | grep Version Version: 3.7-pre9-1 f...@thorin:~$ kvers=2.6.26.3 f...@thorin:~$ mkdir -p /tmp/lib/modules f...@thorin:~$ cp -r /lib/modules/$kvers /tmp/lib/modules/ f...@thorin:~$ rm /tmp/lib/modules/$kvers/modules.* f...@thorin:~$ sudo depmod -ae -F /boot/System.map-$kvers -b /tmp/ -r $kvers f...@thorin:~$ less /tmp/lib/modules/2.6.26.3/modules.dep f...@thorin:~$ grep : .\+ /tmp/lib/modules/2.6.26.3/modules.dep | head -n3 kernel/fs/cramfs/cramfs.ko: kernel/lib/zlib_inflate/zlib_inflate.ko kernel/fs/hfs/hfs.ko: kernel/fs/nls/nls_base.ko kernel/fs/nfs_common/nfs_acl.ko: kernel/net/sunrpc/sunrpc.ko While for the original (correct) modules.dep: f...@thorin:~$ grep : .\+ /lib/modules/2.6.26.3/modules.dep | head -n3 /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/rpcsec_gss_spkm3.ko: /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/rpcsec_gss_krb5.ko: /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko: /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko My hookscript does: if [ -f /boot/initrd.img-$version ]; then update-initramfs -u -k $version else update-initramfs -c -k $version fi Does 'update-initramfs -c' behave differently from mkinitramfs? If I run update-initramfs (0.92o) with a broken modules.dep I get: # update-initramfs -v -c -k 2.6.26.3 | head update-initramfs: Generating /boot/initrd.img-2.6.26.3 Copying module directory kernel/drivers/ide Copying module directory kernel/drivers/scsi Copying module directory kernel/drivers/block Copying module directory kernel/drivers/ata Copying module directory kernel/drivers/mmc Adding binary /usr/share/initramfs-tools/init Adding binary /etc/initramfs-tools/initramfs.conf Adding binary /usr/share/initramfs-tools/conf.d/uswsusp Adding binary /etc/initramfs-tools/conf.d/resume Adding binary /bin/busybox # ls -l /boot/initrd.img-2.6.26.3* -rw-r--r-- 1 root root 4139731 2009-03-19 18:42 /boot/initrd.img-2.6.26.3 -rw-r--r-- 1 root root 5537135 2008-08-22 02:58 /boot/initrd.img-2.6.26.3.sv -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: initramfs-tools: must support relative paths in modules.dep
On Thu, Mar 19, 2009 at 06:43:27PM +0100, Frans Pop wrote: f...@thorin:~$ grep : .\+ /tmp/lib/modules/2.6.26.3/modules.dep | head -n3 kernel/fs/cramfs/cramfs.ko: kernel/lib/zlib_inflate/zlib_inflate.ko kernel/fs/hfs/hfs.ko: kernel/fs/nls/nls_base.ko kernel/fs/nfs_common/nfs_acl.ko: kernel/net/sunrpc/sunrpc.ko While for the original (correct) modules.dep: f...@thorin:~$ grep : .\+ /lib/modules/2.6.26.3/modules.dep | head -n3 /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/rpcsec_gss_spkm3.ko: /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/rpcsec_gss_krb5.ko: /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko /lib/modules/2.6.26.3/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko: /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko yep i see that difference too. My hookscript does: if [ -f /boot/initrd.img-$version ]; then update-initramfs -u -k $version else update-initramfs -c -k $version fi Does 'update-initramfs -c' behave differently from mkinitramfs? no it is just the upperlayer call to mkinitramfs. If I run update-initramfs (0.92o) with a broken modules.dep I get: # update-initramfs -v -c -k 2.6.26.3 | head update-initramfs: Generating /boot/initrd.img-2.6.26.3 Copying module directory kernel/drivers/ide Copying module directory kernel/drivers/scsi Copying module directory kernel/drivers/block Copying module directory kernel/drivers/ata Copying module directory kernel/drivers/mmc Adding binary /usr/share/initramfs-tools/init Adding binary /etc/initramfs-tools/initramfs.conf Adding binary /usr/share/initramfs-tools/conf.d/uswsusp Adding binary /etc/initramfs-tools/conf.d/resume Adding binary /bin/busybox could you send the ouput of sh -x mkinitramfs -o /tmp/foo 2.6.26.3 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520433: linux-image-2.6.26-1-ixp4xx: Please build joydev.ko
Package: linux-image-2.6.26-1-ixp4xx Version: 2.6.26-13 Severity: wishlist It would be very helpful to have a version of the kernel with /drivers/input/joydev available. I'm trying to use joypads to interface with an NSLU2. Thanks, Tom -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 2.6.26-1-ixp4xx Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-ixp4xx depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii initramfs-tools [linux-initra 0.92o tools for generating an initramfs ii module-init-tools 3.4-1 tools for managing Linux kernel mo linux-image-2.6.26-1-ixp4xx recommends no packages. Versions of packages linux-image-2.6.26-1-ixp4xx suggests: pn fdutils none (no description available) pn linux-doc-2.6.26 none (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509646: bnx2x firmware licensing
Hi Eilon, In bnx2x_init_values.h, there appear to be several sourceless firmware blobs (init_data_*, *_int_table_data_*, and arguably init_ops). So far, Debian has removed this file from our distribution of linux-2.6 and disabled the driver. In order to allow Debian users to use bnx2x, I have written a patch [1] to the driver to use request_firmware (using the result of a firmware cutter here [2]), but the current licensing is ambiguous. (The whole bnx2x driver seems to be licensed under the GPL, but it has no exception for the sourceless parts, which can't be covered by the GPL. In any case, it doesn't give us the right to redistribute the contents of bnx2x_init_values.h in binary-equivalent form.) Can you clarify the license for us? For example, the bnx2_fw.h header has the following notice: /* bnx2_fw.h: Broadcom NX2 network driver. * * Copyright (c) 2004, 2005, 2006, 2007 Broadcom Corporation * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, except as noted below. * * This file contains firmware data derived from proprietary unpublished * source code, Copyright (c) 2004, 2005, 2006, 2007 Broadcom Corporation. * * Permission is hereby granted for the distribution of this firmware data * in hexadecimal or equivalent format, provided this copyright notice is * accompanying it. */ Thanks for your time! [1]: http://bugs.debian.org/509647 [2]: http://bugs.debian.org/509646 -- John Wright j...@debian.org -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
[ adding jcm and lkml to Cc: ]
On Thu, Mar 19, 2009 at 07:40:46PM +0100, Frans Pop wrote:
Hmmm. I wonder if it is the old m-i-t's modprobe that is the problem when
you do:
modprobe --set-version=2.6.26.3 --ignore-install --show-depends module
Looks like that's it:
# modprobe -V
module-init-tools version 3.4
# modprobe --set-version=2.6.26.3 --ignore-install --show-depends nfs
WARNING: Could not open 'kernel/net/sunrpc/sunrpc.ko': No such file or
directory
WARNING: Could not open 'kernel/fs/nfs_common/nfs_acl.ko': No such file or
directory
WARNING: Could not open 'kernel/fs/lockd/lockd.ko': No such file or
directory
FATAL: Could not open 'kernel/fs/nfs/nfs.ko': No such file or directory
# modprobe -V
module-init-tools version 3.7-pre9
# modprobe --set-version=2.6.26.3 --ignore-install --show-depends nfs
WARNING: All config files need .conf: /etc/modprobe.d/pnp-hotplug, it will
be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/display_class, it
will be ignored in a future release.
WARNING: All config files need .conf: /etc/modprobe.d/blacklist, it will
be ignored in a future release.
insmod /lib/modules/2.6.26.3/kernel/net/sunrpc/sunrpc.ko
insmod /lib/modules/2.6.26.3/kernel/fs/nfs_common/nfs_acl.ko
insmod /lib/modules/2.6.26.3/kernel/fs/lockd/lockd.ko
insmod /lib/modules/2.6.26.3/kernel/fs/nfs/nfs.ko
That would mean that m-i-t has created a backwards incompatibility problem
_with itself_ and that the problem actually is installing a kernel, that
was built on a system with new m-i-t, on a system with old m-i-t.
Or, installing a kernel, built on a system running unstable or testing, on
a system running oldstable or stable. That sucks.
argh indeed.
arguably it is also a bug by initramfs-tools to suppress the error of above
modprobe calls see manual_add_modules() in hook-functions:
for mam_x in $(modprobe --set-version=${version} --ignore-install \
--show-depends ${1} 2/dev/null | awk '/^insmod/ { print $2 }'); do
git history tells that jbailey added it from the start on,
so it must have been because modprobe was/is too chatty.
suse mkinitrd seems also only to have lost that suppression lately.
thanks for finding out fjp.
kind regards
--
maks
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thu, 2009-03-19 at 21:13 +0100, maximilian attems wrote: [ adding jcm and lkml to Cc: ] [ You want linux-modu...@vger.kernel.org rather than LKML. I've added the former to the CC list, we can kill LKML off the CC shortly. ] That would mean that m-i-t has created a backwards incompatibility problem _with itself_ and that the problem actually is installing a kernel, that was built on a system with new m-i-t, on a system with old m-i-t. Looks like the problem is actually that depmod was run under the newer version and then you tried to use the generated files with an older modprobe. I'm not sure that's actually an error - it was noted that the slight format change was unideal for such unlikely cases and in fact we won't do that again in the future. But if you were just moving forwards from one release to the next you would have been fine - you're talking lack of forward compatibility actually. Unless I'm missing something, in which case please clarify. I would like it also if you'd send me the generated files, distro info, etc. Jon. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
(lkml dropped) On Thursday 19 March 2009, Jon Masters wrote: On Thu, 2009-03-19 at 21:13 +0100, maximilian attems wrote: That would mean that m-i-t has created a backwards incompatibility problem _with itself_ and that the problem actually is installing a kernel, that was built on a system with new m-i-t, on a system with old m-i-t. Looks like the problem is actually that depmod was run under the newer version and then you tried to use the generated files with an older modprobe. I'm not sure that's actually an error - it was noted that the slight format change was unideal for such unlikely cases and in fact we won't do that again in the future. But if you were just moving forwards from one release to the next you would have been fine - you're talking lack of forward compatibility actually. The use case here, which I suspect is not all that uncommon, is that I built a kernel from upstream source on a (Debian unstable) system with the new version of depmod and then installed that kernel on a (Debian stable) system that has an older version of modprobe [1]. The kernel Makefile of course does: /sbin/depmod -ae -F System.map -b $(INSTALL_MOD_PATH) $(KERNELRELEASE) Because the old modprobe does not understand the new relative (or rather rootless) paths, aggravated by the fact that initramfs-tools does not error out or display errors from modprobe (probably for good historic reasons), I suddenly had an initramfs that contained no modules and thus a system that failed to reboot with the new kernel. It took me quite a lot of time to trace it back to the upgrade of module-init-tools. Needless to say that this had always worked without any problems before. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thu, 2009-03-19 at 21:57 +0100, Frans Pop wrote: Because the old modprobe does not understand the new relative (or rather rootless) paths, aggravated by the fact that initramfs-tools does not error out or display errors from modprobe (probably for good historic reasons), I suddenly had an initramfs that contained no modules and thus a system that failed to reboot with the new kernel. Well, that lack of understanding the difference between relative/explict paths was fixed but of course we can't go back in time and fix what's already out there and in use. Yes, it was a bad idea of mine (perhaps) to change the existing file format and I've learned something, but it should only have affected for example that 3.4 release you're using. Jon. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thursday 19 March 2009, Jon Masters wrote: Yes, it was a bad idea of mine (perhaps) to change the existing file format and I've learned something, but it should only have affected for example that 3.4 release you're using. Do you mean that earlier versions are not affected? Hasn't depmod generated full paths basically any version up to 3.6? But even if it is only 3.4, that still makes it every Debian stable user (and unknown other distros) who runs the risk of ending up with an unbootable system for hard to trace reasons... Potentially painful for example for NAS devices where the kernel and initrd get installed in flash, replacing the previous version. As the kernel Makefile does run depmod during a build, I don't think it's strange to assume users rely on that modules.dep being valid, even for older versions of modprobe. What exactly are the resons behind the change in file format that're so strong that depmod cannot continue to generate the old format for the next 5 years or so as a transition period, until the risk is much lower that users run into problems because their current version of modprobe does not understand the new format? Are they really worth the potential consequences? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520433: linux-image-2.6.26-1-ixp4xx: Please build joydev.ko
* Tom Harris deb...@tomharris.me.uk [2009-03-19 18:38]: It would be very helpful to have a version of the kernel with /drivers/input/joydev available. I'm trying to use joypads to interface with an NSLU2. I'll enable the module and build a kernel for you on the weekend. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520256: Fwd: Bug#520256: linux-image-2.6.26-1-686: I lost the sound after each reboot, after etch to lenny dist-upgrade and krnel
On Wed, 18 Mar 2009, yellow protoss wrote: [ I added the bug to cc ] thx cool, so i guess you found the 2.6.28 sid snapshots, how are they working? kind regards -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thu, 2009-03-19 at 23:09 +0100, Frans Pop wrote: On Thursday 19 March 2009, Jon Masters wrote: Yes, it was a bad idea of mine (perhaps) to change the existing file format and I've learned something, but it should only have affected for example that 3.4 release you're using. Do you mean that earlier versions are not affected? Hasn't depmod generated full paths basically any version up to 3.6? Yes, it was 3.6 where it changed, not 3.4. However, there was a backward compatibility issue during development that I was referring to. That isn't the problem here anyway. The problem is that you want to use a newly generated .dep file on an old install. I know that would be nice, and I'm sorry that it bothers you, but at the same time you don't expect newly built binaries to run against an older version of glibc they weren't built against, etc. But even if it is only 3.4, that still makes it every Debian stable user (and unknown other distros) who runs the risk of ending up with an unbootable system for hard to trace reasons... No, it really doesn't. If you upgrade to a new module-init-tools and run depmod, then everything works. If you use the old .dep files then it still works. If you force downgrade and don't rebuild your .dep files then there certainly is the risk of being out of sync - but there are other times where such things can happen too. I'm sure other utilities have similar. Potentially painful for example for NAS devices where the kernel and initrd get installed in flash, replacing the previous version. Yes, and in that case there's no problem. If you do a forward upgrade everything works just fine. It's only if you try to mix versions and go backwards that you get a problem. I can see this in a cross-build setup being a slight annoyance, but even there most people would use the same version of the tools or expect to have problems building on a newer box for an older release. As the kernel Makefile does run depmod during a build, I don't think it's strange to assume users rely on that modules.dep being valid, even for older versions of modprobe. It works fine as long as your box is self-consistent. What is the actual problem other than that mixing versions and trying to go backward without quickly re-running depmod might cause module load problems? What exactly are the resons behind the change in file format that're so strong that depmod cannot continue to generate the old format for the next 5 years or so as a transition period I guess it's called progress ;) Sarcasm aside, if you can give me an example of an actual real life set of users who are adversely affected then I'll try to do something to help out. But if you're asking for old versions of software to be compatible with newer releases in every case I think you're not being terribly realistic. The kernel changes to make progress, and so do other utilities. Jon. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520009: ext3 'data=foo' on root fs is broken
On Wed, 18 Mar 2009, Peter Samuelson wrote: So, if I understand you correctly, the reason you can't fix this is because you have no desire to support a configuration that was not produced by debian-installer? well your usage falls under advanced messing with your box, so i'd expect such a user to be able to read man initramfs-tools to find the corresponding bootflag. By this same logic, it seems to me that debian-installer should also set 'rootfstype' on the kernel command line, so that the initramfs does not have to detect that either. no the logic is not the same. the fstype can be probed in a generic way whereas you are asking for a hardcoding for a special box. the fstype can be probed as the corresponding root bootarg is passed to initramfs and yes d-i takes care of that one. kind regards -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509646: bnx2x firmware licensing
On Thu, 2009-03-19 at 13:05 -0600, John Wright wrote: Hi Eilon, In bnx2x_init_values.h, there appear to be several sourceless firmware blobs (init_data_*, *_int_table_data_*, and arguably init_ops). [...] init_ops looks like a plausible preferred form for modification to me. It's not very meaningful without reference to the Programmers' Reference Manual, but then neither is most of the other hardware setup code in the driver. Regarding the other tables, I'll reiterate John's request. Unless you can make a good case that these really are the preferred form for modification, or apply a licence that does not require source, then Debian can't distribute them at all. Ben. signature.asc Description: This is a digitally signed message part
Bug#520198: mkinitramfs: cannot build initrd with rootfs on mmcblk
On Wed, 18 Mar 2009, afunix wrote:
Wednesday 18 March 2009 19:51:19 maximilian attems писал:
btw how did you install your box?
I've installed system on qemu-arm emulator with standard lenny kernel,
than I've used custom kernel 2.6.21-hh9 for that hardware to boot
already installed system. it's not debian kernel, because standard
kernel just doesn't starts and custom kernel, compiled with debian tools
can't mount root.
ok thanks for the info. interesting box :D
# ls /sys/block
mmcblk0
i see this confuses me right now, will need more info, see below
I found that there wasn't /lib/modules/2.6.21-hh9 directory. I've copied
modules, but mkinitramfs-kpkg still failes:
Setting up linux-image-2.6.26-1-versatile (2.6.26-13) ...
Running depmod.
Finding valid ramdisk creators.
Using mkinitramfs-kpkg to build the ramdisk.
Depreciation WARNING: use update-initramfs(8)
mkinitramfs-kpkg failed to create initrd image.
Failed to create initrd image.
dpkg: error processing linux-image-2.6.26-1-versatile (--configure):
hmmm what does this output give:
cat /etc/kernel-img.conf
++ modprobe --set-version=2.6.21-hh9 --ignore-install --show-depends ext3
++ awk '/^insmod/ { print $2 }'
+ '[' /dev/mmcblk0p3 '!=' /dev/mmcblk0p3 ']'
+ '[' /dev/mmcblk0p3 '!=' /dev/mmcblk0p3 ']'
+ '[' /dev/mmcblk0p3 '!=' /dev/mmcblk0p3 ']'
+ '[' /dev/mmcblk0p3 '!=' /dev/mmcblk0p3 ']'
+ '[' /dev/mmcblk0p3 '!=' /dev/mmcblk0p3 ']'
+ '[' /dev/mmcblk0p3 '!=' /dev/mmcblk0p3 ']'
+ '[' /dev/mmcblk0p3 '!=' /dev/mmcblk0p3 ']'
+ '[' /dev/mmcblk0p3 '!=' /dev/mmcblk0p3 ']'
+ block=mmcblk0p3
+ block=mmcblk
+ '[' -z mmcblk ']'
+ '[' '!' -e /sys/block/mmcblk ']'
+ echo 'mkinitramfs: missing mmcblk root /dev/mmcblk0p3 /sys entry'
i see, could you test with MODULES=dep belows patch:
(you might need to apply it to /usr/share/initramfs-tools/hook-functions
diff --git a/hook-functions b/hook-functions
index 353495f..82ffbef 100644
--- a/hook-functions
+++ b/hook-functions
@@ -292,6 +292,10 @@ dep_add_modules()
if [ ! -e /sys/block/${block} ] ; then
block=${block%%[0-9]*}
fi
+ # /dev/mmcblkXpX
+ elif [ ${root#/dev/mmcblk} != ${root} ]; then
+ block=${root#/dev/}
+ block=${block%%p[0-9]*}
# classical root device
else
block=${root#/dev/}
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thursday 19 March 2009, Jon Masters wrote: [...] I understand how and why and when it works now. I can also easily avoid the problem now that I know about it. The question here is if the breakage is really necessary. I ran into the problem within days of installing the new m-i-t. I don't think I'm very special, so my guess is it's going to affect others too. I guess it's called progress ;) Sarcasm aside, if you can give me an example of an actual real life set of users who are adversely affected then I'll try to do something to help out. But if you're asking for old versions of software to be compatible with newer releases in every case I think you're not being terribly realistic. The kernel changes to make progress, and so do other utilities. No, sorry. That isn't, at least AIUI, how kernel (related) development is supposed to be done: http://lkml.org/lkml/2005/12/29/173 and similar discussions later. Sure, if there are very strong reasons to break things, fine. But whenever possible the kernel has ensured backwards compatibility, mostly only _after_ someone complained. Think of the i386 and x86_64 symlinks after the x86 integration, think of the COMPAT_SYSFS flags, think of optional support for old /proc files, think feature-removal-schedule.txt. So far you seem to be avoiding to give the reasons for the change. What would be so wrong with ensuring the compatibility for some transition period and avoiding the problem? P.S. Thanks a lot for your prompt replies. I do appreciate the discussion. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lenny updates
On Mon, 16 Mar 2009, Ola Lundqvist wrote: Hi Did you get it in the other mail I sent? Best regards, // Ola none with a tarball. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Thu, 2009-03-19 at 23:58 +0100, Frans Pop wrote: I guess it's called progress ;) Sarcasm aside, if you can give me an example of an actual real life set of users who are adversely affected then I'll try to do something to help out. But if you're asking for old versions of software to be compatible with newer releases in every case I think you're not being terribly realistic. The kernel changes to make progress, and so do other utilities. Sure, if there are very strong reasons to break things, fine. But whenever possible the kernel has ensured backwards compatibility, mostly only _after_ someone complained. Think of the i386 and x86_64 symlinks after the x86 integration, think of the COMPAT_SYSFS flags, think of optional support for old /proc files, think feature-removal-schedule.txt. All of these examples refer to the future. The *future*. Things that will change, preserving backward compatibility, keeping symlinks around for those who are used to the old location. *Backward* compatibility. But the issue you raised was about *Forward* compatibility. This is nice but isn't the same. That would be like guaranteeing that all future kernel features will work with a kernel from 6 months ago, or that modules will, or other similar stuff. So far you seem to be avoiding to give the reasons for the change. What would be so wrong with ensuring the compatibility for some transition period and avoiding the problem? There is compatibility. From the past, to the present, into the future. But you want to use *future* generated files with a *past* version. That is not backward compatibility and it is not the kind of thing where you can preserve for 5 years, etc. How does the old version know something is going to change? It doesn't and it can't. v3.4 will always be the same, and it won't change. The files changed slightly in v3.6, but v3.4 can never know about that. P.S. Thanks a lot for your prompt replies. I do appreciate the discussion. Sure. Hopefully you see that this is not a regular compatibility issue. Jon. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]
On Friday 20 March 2009, Jon Masters wrote: Sure, if there are very strong reasons to break things, fine. But whenever possible the kernel has ensured backwards compatibility, mostly only _after_ someone complained. Think of the i386 and x86_64 symlinks after the x86 integration, think of the COMPAT_SYSFS flags, think of optional support for old /proc files, think feature-removal-schedule.txt. All of these examples refer to the future. The *future*. Things that will change, preserving backward compatibility, keeping symlinks around for those who are used to the old location. *Backward* compatibility. Exactly: making sure that tools in older userspace environments (old version of modprobe) continue to work with new kernels (or built in an environment that happens to have the latest and greatest depmod). But the issue you raised was about *Forward* compatibility. This is nice but isn't the same. That would be like guaranteeing that all future kernel features will work with a kernel from 6 months ago, or that modules will, or other similar stuff. I really don't see the huge difference. IMO you are comparing apples with oranges. I'm really don't think I'm trying to use modules from a 2.4 kernel with a 2.6 kernel here. m-i-t is _not_ an integral part of the kernel. It's just another tool, and one that's used in two different environments: a kernel build environment and a kernel user environment. And the format of the files generated by one and read by the other is the glue that keeps things together. Changing that format should IMO be done with due consideration for relevant use cases, and only if there are very strong arguments to do so. So far you seem to be avoiding to give the reasons for the change. What would be so wrong with ensuring the compatibility for some transition period and avoiding the problem? [...] Hopefully you see that this is not a regular compatibility issue. What I mainly see is that you seem to be avoiding answering this question and are apparently unwilling to consider to repair the situation. I think my 2 cents are played out by now, so I'll drop things here. Maybe someone else will be willing to take up the batton. At least the issue is somewhat documented now. I'll inform others in Debian that the issue exists and fix things locally for my own use case. Thanks again for your replies. Cheers, FJP -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520256: Fwd: Bug#520256: linux-image-2.6.26-1-686: I lost the sound after each reboot, after etch to lenny dist-upgrade and krnel
HI Max I returned to the 2.26 kernel So I added at teh boot of teh machine: /etc/init.d/alsa reload ons$ uptime 01:09:52 up 1 day, 4:59, 3 users, load average: 0.14, 0.18, 0.12 I didnt reboot yet the box. We'll see at the reboot (dont know when already, since it runs no X) Prob: i cant install my webcam with it. since its not perfectly compiled, this default debian kernel :( Best regards and x1 thans On Thu, Mar 19, 2009 at 11:16 PM, maximilian attems m...@stro.at wrote: On Wed, 18 Mar 2009, yellow protoss wrote: [ I added the bug to cc ] thx cool, so i guess you found the 2.6.28 sid snapshots, how are they working? kind regards -- maks
Re: lenny updates
Hi Interesting I sent it about 15 seconds after the other one. Maybe it was too big. In any case I have uploaded the patches to http://apt.inguza.org/vzkernel/ Best regards, // Ola On Thu, Mar 19, 2009 at 11:37:05PM +0100, maximilian attems wrote: On Mon, 16 Mar 2009, Ola Lundqvist wrote: Hi Did you get it in the other mail I sent? Best regards, // Ola none with a tarball. -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comAnnebergsslingan 37\ | o...@debian.org 654 65 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
