Bug#580616: debconf: Unknown template field '_description'
Package: linux-2.6 Version: 2.6.33-1~experimental.5 Severity: wishlist See many: debconf: Unknown template field '_description', in stanza #1 of /var/lib/dpkg/info/linux-image-2.6.33-2-686.templates -- 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/871vdo2l92@jidanni.org
Bug#580638: realtek r8192s_usb new_id
Package: linux-2.6 Version: 2.6.33-1~experimental.5 X-debbugs-Cc: Ben Hutchings b...@decadent.org.uk, Stefan Lippers-Hollmann s@gmx.de, 579...@bugs.debian.org File: /lib/modules/2.6.33-2-686/kernel/drivers/staging/rtl8192su/r8192s_usb.ko In contrast with the steps noted at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579694#47 I find I need to do the odd combination of # modprobe r8192s_usb # echo 0bda 8171 | /sys/bus/usb/drivers/rtl819xU/new_id as there is no other /sys/bus/usb/drivers/r* (not that I know what I'm talking about.) Nothing I put in /etc/udev/rules.d/70-persistent-net.rules helps. Please make it so that it works upon plugging it in. (The firmware is already in firmware-realtek.) Please also add it to /lib/modules/2.6.32 . -- 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/87k4rg3qh9@jidanni.org
Bug#563551: usb-modeswitch: Disconnect the Huawei E220 3G USB modem
Hi Please check out https://bugzilla.kernel.org/show_bug.cgi?id=14499 especially comment https://bugzilla.kernel.org/show_bug.cgi?id=14499#c26 and report whether the suggestions there help. It may be the same problem. Thank you Damjan -- 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/u2t9e89675b1005070649qb46dda84vad0fe7ba089dc...@mail.gmail.com
Bug#580652: linux-libc-dev 2.6.32-12 breaks KVM and QEMU
Package: linux-libc-dev Version: 2.6.32-12 Severity: important linux-libc-dev version 2.6.32-12 has a backport of KVM: x86: Add KVM_GET/SET_VCPU_EVENTS, without the corresponding KVM: x86: Extend KVM_SET_VCPU_EVENTS with selective updates backport. This breaks KVM and KVM support in QEMU. It should either be reverted or the second should also be backported. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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/20100507140544.19262.23115.report...@volta.aurel32.net
Processed: tagging 580652
Processing commands for cont...@bugs.debian.org: # Automatically generated email from bts, devscripts version 2.10.35lenny7 tags 580652 + pending Bug #580652 [linux-libc-dev] linux-libc-dev 2.6.32-12 breaks KVM and QEMU Added tag(s) pending. End of message, stopping processing here. Please contact me if you need assistance. -- 580652: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580652 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.12732432612437.transcr...@bugs.debian.org
Bug#580602: linux-2.6: mips FPU emulation broken
* Clint Adams sch...@debian.org [2010-05-07 02:57]: The patch in this thread allegedly allows eglibc to be built on an FPU-less (though single-cpu) system: http://www.linux-mips.org/archives/linux-mips/2010-05/msg5.html The patch is in the MIPS/Linux tree now, so hopefully it will show up in the next -stable release. http://www.linux-mips.org/git?p=linux.git;a=commitdiff;h=2c8fb481214e608f6b9a71aa85651d9ddf7fd6e4 -- 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 Archive: http://lists.debian.org/20100507142045.gc1...@jirafa.cyrius.com
Bug#580652: linux-libc-dev 2.6.32-12 breaks KVM and QEMU
On Fri, May 07, 2010 at 04:05:44PM +0200, Aurelien Jarno wrote: Package: linux-libc-dev Version: 2.6.32-12 Severity: important linux-libc-dev version 2.6.32-12 has a backport of KVM: x86: Add KVM_GET/SET_VCPU_EVENTS, without the corresponding KVM: x86: Extend KVM_SET_VCPU_EVENTS with selective updates backport. This breaks KVM and KVM support in QEMU. It should either be reverted or the second should also be backported. dab4b911a5327859bb8f969249c6978c26cd4853 applies cleanly to 12, will add. thanks for report. -- 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/20100507142626.gz19...@baikonur.stro.at
Bug#580661: linux-image-2.6.32-5-686: 2.6.32-5-686 makes VGA compatible controller sick
Package: linux-2.6 Version: 2.6.32-12 Severity: important Running linux-image-2.6.32-5-686 garbles the screen of this laptop, both inside and outside of X. It makes the kernel unusable. Unfortunately, I see nothing in dmesg, /var/log/Xorg.0.log, syslog or messages that points to the cause ... This is on a VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400 I've made two photos using a mobile phone camera to show what happens to the screen. http://www.flickr.com/photos/21252...@n06/4586093229/ http://www.flickr.com/photos/21252...@n06/4586093385/ -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information not available ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub [8086:27a0] (rev 03) Subsystem: Lenovo ThinkPad T60 [17aa:2015] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Capabilities: access denied 00:01.0 PCI bridge [0604]: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port [8086:27a1] (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 2000-2fff Memory behind bridge: ee00-ee0f Prefetchable memory behind bridge: d800-dfff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High Definition Audio Controller [8086:27d8] (rev 02) Subsystem: Lenovo ThinkPad T60/R60 series [17aa:2010] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin B routed to IRQ 17 Region 0: Memory at ee40 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: HDA Intel 00:1c.0 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 1 [8086:27d0] (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: ee10-ee1f Prefetchable memory behind bridge: 6000-601f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:1c.1 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 2 [8086:27d2] (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 3000-4fff Memory behind bridge: ec00-edff Prefetchable memory behind bridge: e400-e40f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:1c.2 PCI bridge [0604]: Intel Corporation N10/ICH 7 Family PCI Express Port 3 [8086:27d4] (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort-
Bug#580661: linux-image-2.6.32-5-686: 2.6.32-5-686 makes VGA compatible controller sick
On Fri, May 7, 2010 at 15:47:15 +0200, Gijs Hillenius wrote: Package: linux-2.6 Version: 2.6.32-12 Severity: important Running linux-image-2.6.32-5-686 garbles the screen of this laptop, both inside and outside of X. It makes the kernel unusable. What version were you using before? Unfortunately, I see nothing in dmesg, /var/log/Xorg.0.log, syslog or messages that points to the cause ... please attach the X log and dmesg anyway. Cheers, Julien signature.asc Description: Digital signature
Bug#580660: linux-image-2.6.32-5-amd64: LVM volumes fail to detect on newer kernels
On Fri, May 07, 2010 at 03:44:04PM +0100, Mark Brown wrote: Package: linux-2.6 Version: 2.6.32-12 Severity: important Since version 2.6.33-2-amd64 I have been unable to boot this system. The system uses an encrypted filesystem but on boot the kernel fails to locate the volume group containing the filesystem and therefore halts. asking the obvious questions up front: dpkg -l cryptsetup lvm2 -- 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/20100507170040.ga19...@baikonur.stro.at
RC bug #548434 seems kernel related
Hello kernel people! I'm currently adopting the fdutils package, and looking at the bug list, I found that it has a RC bug (#548434) that seems not related to him but to the kernel (this problem exist with several programs when trying to access floppy drives). It is forwarded to https://patchwork.kernel.org/patch/69588/ and it seems that a patch has been developed and fixes the bug, but they don't say if this patch is integrated nor even give a pointer to it. Could someone have a look on that bug (lng page!) and on the patchwork page and tell me if I can reassign the bug (and to which package exactly)? Regards, Matteo P.S.: please CC me as I'm not subscribed to the list. -- Ma clef GPG est disponible sur keyserver.veridis.com My GPG key is available on keyserver.veridis.com signature.asc Description: This is a digitally signed message part.
Re: Bug#561099: initramfs-tools: determination of newest kernel in update-initramfs -u uses improper sorting
Allow me this little statement since opening a new bug appears to be fruitless. Let me try: The program's behaviour differs from the description in the manpage. Doesn't sound like a bug to you? Of course, the issue can be fixed a) in the program or b) in the man page, but in my opinion, it definitely should be fixed. Cheers! Thiemo It has been a somewhat prolonged irritant for me, mainly due to lack of time in tracking down each and every oddity that comes along. Testing (squeeze) at some point put out a 2.6.32-trunk kernel that sorts after any 2.6.32-n kernel and consequently always is the newest if it still is around. Mind you, the user didn't build and install or even install outside normal update procedures. Therefore, the point that these kernel tangents are due to expert-level user actions is wrong in this case. The argument that the onus is on the user may apply in unstable however not for testing since that codename refers to testing the potential release and not to testing the potential user. (Obciously, that argument implies the naming problem should have been caught in unstable...oh well.) Even so, the confusion caused by the unusually numbered kernel would have been lessened considerably if the manpage had actually defined the term newest kernel so that at least the user could understand what was happening with the update-initramfs -u action. I might be overstepping here but I would think that most people would consider the word newest to refer to a temporal order and not a lexical. As it was with the confusion of thinking that it should be updating the newest but for some reason just isn't, I, and possibly others, had to go along behind updates and redo that command with a -k option in order to get the proper initrd.img updated, or find some other less tedious workaround. In the end, I agree with Thiemo in that the manpage and the program's behaviour are at odds. regards, -jeff -- 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/4be436cf.7040...@kikisoso.org
Re: Bug#561099: initramfs-tools: determination of newest kernel in update-initramfs -u uses improper sorting
On Fri, May 07, 2010 at 11:50:39AM -0400, Jeffrey B. Green wrote: Allow me this little statement since opening a new bug appears to be fruitless. Let me try: The program's behaviour differs from the description in the manpage. Doesn't sound like a bug to you? Of course, the issue can be fixed a) in the program or b) in the man page, but in my opinion, it definitely should be fixed. Cheers! Thiemo It has been a somewhat prolonged irritant for me, mainly due to lack of time in tracking down each and every oddity that comes along. Testing (squeeze) at some point put out a 2.6.32-trunk kernel that sorts after any 2.6.32-n kernel and consequently always is the newest if it still is around. Mind you, the user didn't build and install or even install outside normal update procedures. Therefore, the point that these kernel tangents are due to expert-level user actions is wrong in this case. The argument that the onus is on the user may apply in unstable however not for testing since that codename refers to testing the potential release and not to testing the potential user. (Obciously, that argument implies the naming problem should have been caught in unstable...oh well.) Even so, the confusion caused by the unusually numbered kernel would have been lessened considerably if the manpage had actually defined the term newest kernel so that at least the user could understand what was happening with the update-initramfs -u action. I might be overstepping here but I would think that most people would consider the word newest to refer to a temporal order and not a lexical. As it was with the confusion of thinking that it should be updating the newest but for some reason just isn't, I, and possibly others, had to go along behind updates and redo that command with a -k option in order to get the proper initrd.img updated, or find some other less tedious workaround. In the end, I agree with Thiemo in that the manpage and the program's behaviour are at odds. just nuke the trunk linux-image, it is severely outdated. kind regards -- 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/20100507185317.gb19...@baikonur.stro.at
Bug#580705: linux-image-2.6.32-5-686: crash while playing movie
Package: linux-2.6 Version: 2.6.32-12 Severity: normal Tags: sid While playing movie in VLC my ThingPad freeze. There was short beep after which screen freeze. I still have sound (I can continue movie, but only listening it) and working keyboard. So switch to tty1 and emergency reboot was only solution. I'm not so shure that this is kernel related or something else, but in /var/log/syslog there is folowing messages: May 7 23:25:35 tao kernel: [13983.076040] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung May 7 23:25:35 tao kernel: [13983.076059] render error detected, EIR: 0x May 7 23:25:35 tao kernel: [13983.076082] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1680426 at 1680423) May 7 23:25:35 tao kernel: [13983.236265] [ cut here ] May 7 23:25:35 tao kernel: [13983.236280] kernel BUG at /tmp/buildd/linux-2.6-2.6.32/debian/build/source_i386_none/drivers/gpu/drm/i915/intel_display.c:1917! May 7 23:25:35 tao kernel: [13983.236293] invalid opcode: [#1] SMP May 7 23:25:35 tao kernel: [13983.236303] last sysfs file: /sys/devices/pci:00/:00:1e.0/:02:02.0/net/wlan0/statistics/collisions May 7 23:25:35 tao kernel: [13983.236313] Modules linked in: aes_i586 aes_generic lib80211_crypt_ccmp ppdev lp iTCO_wdt iTCO_vendor_support cpufreq_conservative cpufreq_powersave cpufreq_userspace binfmt_misc uinput i915 drm_kms_helper i2c_algo_bit drm tp_smapi thinkpad_ec aiptek microcode cpuid acpi_cpufreq fuse cifs pktcdvd msr cpufreq_stats snd_seq_dummy ide_generic ide_gd_mod ide_cd_mod ide_core dm_crypt snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi pcmcia snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device yenta_socket snd usbhid ipw2200 rsrc_nonstatic hid pcmcia_core soundcore i2c_i801 thinkpad_acpi libipw i2c_core rfkill lib80211 snd_page_alloc parport_pc shpchp led_class parport video psmouse tpm_tis rng_core tpm serio_raw evdev tpm_bios nvram output pci_hotplug battery button processor ac pcspkr ext3 jbd mbcache dm_mod sg sr_mod sd_mod crc_t10dif cdrom ata_generic uhci_hcd ata_piix libata thermal e100 ehci_hcd mii th ermal_sys scsi_mod usbcore nls_ba May 7 23:25:35 tao kernel: e [last unloaded: scsi_wait_scan] May 7 23:25:35 tao kernel: [13983.236560] May 7 23:25:35 tao kernel: [13983.236570] Pid: 4084, comm: Xorg Not tainted (2.6.32-5-686 #1) 1834JAG May 7 23:25:35 tao kernel: [13983.236580] EIP: 0060:[f881214f] EFLAGS: 00213282 CPU: 0 May 7 23:25:35 tao kernel: [13983.236618] EIP is at intel_crtc_dpms_overlay+0x31/0x42 [i915] May 7 23:25:35 tao kernel: [13983.236628] EAX: fffb EBX: f67ca540 ECX: EDX: 0019a42a May 7 23:25:35 tao kernel: [13983.236637] ESI: f66bd000 EDI: 6018 EBP: 00071180 ESP: f6ffbc5c May 7 23:25:35 tao kernel: [13983.236646] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 May 7 23:25:35 tao kernel: [13983.236658] Process Xorg (pid: 4084, ti=f6ffa000 task=f6fe9dc0 task.ti=f6ffa000) May 7 23:25:35 tao kernel: [13983.236665] Stack: May 7 23:25:35 tao kernel: [13983.236670] 0001 f8813de4 f600c000 f658c000 0001 00071184 00071008 f658c000 May 7 23:25:35 tao kernel: [13983.236690] 0 f600c000 0003 0001 f88113f9 f600c000 f8822a6c f658c2ec f8823e10 May 7 23:25:35 tao kernel: [13983.236710] 0 f87a672f f658c2e0 f6ffbd74 f6255240 f658c1ac f87a7a50 0002 May 7 23:25:35 tao kernel: [13983.236732] Call Trace: May 7 23:25:35 tao kernel: [13983.236766] [f8813de4] ? i9xx_crtc_dpms+0x181/0x264 [i915] May 7 23:25:35 tao kernel: [13983.236799] [f88113f9] ? intel_crtc_dpms+0x1c/0xb5 [i915] May 7 23:25:35 tao kernel: [13983.236818] [f87a672f] ? drm_helper_disable_unused_functions+0x104/0x130 [drm_kms_helper] May 7 23:25:35 tao kernel: [13983.236835] [f87a7a50] ? drm_crtc_helper_set_config+0x544/0x6b5 [drm_kms_helper] May 7 23:25:35 tao kernel: [13983.236856] [c108ba71] ? __free_pages_ok+0xf5/0x11b May 7 23:25:35 tao kernel: [13983.236872] [c10bfabf] ? d_kill+0x3e/0x43 May 7 23:25:35 tao kernel: [13983.236884] [c10bfabf] ? d_kill+0x3e/0x43 May 7 23:25:35 tao kernel: [13983.236896] [c10ae5c8] ? kmem_cache_free+0x78/0xaf May 7 23:25:35 tao kernel: [13983.236912] [c11324be] ? kref_put+0x36/0x40 May 7 23:25:35 tao kernel: [13983.236923] [c11324be] ? kref_put+0x36/0x40 May 7 23:25:35 tao kernel: [13983.236933] [c10ae833] ? kfree+0xcc/0xde May 7 23:25:35 tao kernel: [13983.236944] [c11324be] ? kref_put+0x36/0x40 May 7 23:25:35 tao kernel: [13983.236975] [f876d8ca] ? drm_framebuffer_cleanup+0x4a/0xa7 [drm] May 7 23:25:35 tao kernel: [13983.237010] [f8813407] ? intel_user_framebuffer_destroy+0x1f/0x4a [i915] May 7 23:25:35 tao kernel: [13983.237038] [f876d33c] ? drm_fb_release+0x4c/0x65 [drm] May 7 23:25:35 tao kernel: [13983.237062] [f8766dcf] ? drm_release+0x2c2/0x4c5 [drm] May 7 23:25:35 tao kernel: [13983.237076] [c10b41ef] ?
Re: Bug#561099: initramfs-tools: determination of newest kernel in update-initramfs -u uses improper sorting
maximilian attems wrote: On Fri, May 07, 2010 at 11:50:39AM -0400, Jeffrey B. Green wrote: [...snip...] In the end, I agree with Thiemo in that the manpage and the program's behaviour are at odds. just nuke the trunk linux-image, it is severely outdated. That's sidestepping the issue. Solving the immediate problem of getting the correct initrd to update is not really the problem at the moment. (However, I'd need to find a backup kernel to put in its stead if I did simply purge the trunk kernel, and then deal with that kernel later on when obsolescence descends on it.) The point that I believe Thiemo was raising and that I agree with is that the manpage says the software does something that it actually doesn't. Admittedly the phrase is in the context of an example, however it does say that it is to Update the initramfs of the newest kernel which it logically isn't configured to do. One could be humorous about this example and say that it could be said to Update the initramfs of hopefully the newest kernel which is in some way what is actually happening. But a more useable statement might be Update the initramfs of the newest kernel as lexically determined with its name or Update the initramfs of the newest kernel as determined from the name sort order. People at that point might complain about the choice of a lexically determined kernel but at least they'll know what is going on with the update-initramfs tool. regards, -jeff -- 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/4be48846.4080...@kikisoso.org
Bug#580710: linux-base: elilo needs simpler assignments
Source: linux-2.6
Version: 2.6.32-12
Severity: serious
Tags: patch
/usr/sbin/elilo didn't like the converted elilo.conf because it
doesn't support quoted strings, or spaces around '='.
Instead of:
boot = /dev/disk/by-uuid/9C73-E0C3
it needs:
boot=/dev/disk/by-uuid/9C73-E0C3
The following patch fixes it, but it is pretty ugly. I would've
preferred to use the line that is commented out, but when I do I get
an extraneous newline both before and after the newly inserted line.
I assume this is due to how things are tokenized (I'm not enough of a
perl guy to grok it).
Also, it has a cosmetic issue where we lose the tab indention in stanzas.
We go from this:
image=/vmlinuz.old
label=LinuxOLD
root=/dev/sda2
read-only
initrd=/initrd.img.old
To this:
image=/vmlinuz.old
label=LinuxOLD
# root=/dev/sda2
root=UUID=170d52c1-c568-4bad-aass-be4248ad1af4
read-only
initrd=/initrd.img.old
(Now to reboot, to make sure it actually works...)
--
dann frazier
Index: debian/linux-base.postinst
===
--- debian/linux-base.postinst (revision 15638)
+++ debian/linux-base.postinst (working copy)
@@ -499,8 +499,8 @@
return @bdevs;
}
-sub lilo_update {
-my ($old, $new, $map) = @_;
+sub do_lilo_update {
+my ($old, $new, $map, $simple_assign) = @_;
my @tokens = lilo_tokenize($old);
my $i = 0;
my $in_generic = 1; # global or image=/vmlinuz or image=/vmlinuz.old
@@ -533,7 +533,12 @@
}
if (defined($new_value)) {
$new_value =~ s/\\//g;
- $text = \n# $name = $value\n$name = \$new_value\\n;
+ if ($simple_assign) {
+ $text = \n# $name = $value\n$name = \$new_value\\n;
+ } else {
+# $text = \n# $name=$value\n$name=$new_value\n;
+ $text = # $name=$value\n$name=$new_value;
+ }
} else {
$text .= $tokens[$i + 1][0] . $tokens[$i + 2][0];
}
@@ -546,6 +551,13 @@
}
}
+sub lilo_update {
+my ($old, $new, $map) = @_;
+my $simple_assign = 1;
+
+do_lilo_update($old, $new, $map, $simple_assign);
+}
+
sub lilo_post {
_system('lilo');
}
@@ -558,6 +570,13 @@
### ELILO
+sub elilo_update {
+my ($old, $new, $map) = @_;
+my $simple_assign = 0;
+
+do_lilo_update($old, $new, $map, $simple_assign);
+}
+
sub elilo_post {
_system('elilo');
}
@@ -970,7 +989,7 @@
{packages = 'elilo',
path = '/etc/elilo.conf',
list = \lilo_list,
- update = \lilo_update,
+ update = \elilo_update,
post_update = \elilo_post,
is_boot_loader = 1},
{packages = 'extlinux',
Bug#578129: [stable] please apply skip sense logging for some ATA PASS-THROUGH cdbs from 2.6.33
On Sat, May 01, 2010 at 11:27:56PM +0200, Moritz Muehlenhoff wrote: Robert Edmonds wrote: Package: linux-2.6 Version: 2.6.32-11 Severity: normal Tags: patch hi, when SATA drives are attached to SAS controllers and used in ATA pass-through mode, many operations cause alarming but harmless messages (though it may not be immediately obvious to the user that they are harmless) to be written to the kernel log, e.g.: [1381579.095459] sd 8:0:23:0: [sdx] Sense Key : Recovered Error [current] [descriptor] [1381579.095518] Descriptor sense data with sense descriptors (in hex): [1381579.095549] 72 01 00 1d 00 00 00 0e 09 0c 00 00 00 00 00 00 [1381579.095614] 00 4f 00 c2 00 50 [1381579.095654] sd 8:0:23:0: [sdx] Add. Sense: ATA pass through information available i see these types of messages at boot as well as periodically due to the use of smartmontools. if you have a lot of disks your kernel log will be spammed. can you apply commit e7efe5932b1d3916c79326a4221693ea90a900e2 from 2.6.33 to suppress these messages? Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578129 Greg, please consider for the next 2.6.32.x stable kernel, it applies cleanly against 2.6.32.12. And against the .33-stable tree as well. Queued up for both now. thanks, greg k-h -- 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/20100507222328.gd26...@kroah.com
Re: Bug#561099: initramfs-tools: determination of newest kernel in update-initramfs -u uses improper sorting
On Fri, May 07, 2010 at 05:38:14PM -0400, Jeffrey B. Green wrote: maximilian attems wrote: On Fri, May 07, 2010 at 11:50:39AM -0400, Jeffrey B. Green wrote: [...snip...] In the end, I agree with Thiemo in that the manpage and the program's behaviour are at odds. just nuke the trunk linux-image, it is severely outdated. That's sidestepping the issue. stop cycling around it, just shoot the issue. snipped away strange reasons to stay on outdated and unmaintained linux-2.6 have a nice weekend. -- 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/20100508030203.ga29...@baikonur.stro.at
