Bug#588782: same bug as 586369
same bug as 586369
Bug#594156: modules=most does not add virtio_net
Package: initramfs-tools Version: 0.97 Severity: normal Hi, I'm using initramfs-tools in the context of an FAI nfsroot, read, I want to have it booted in a KVM guest with both virtio hard drives and virtio_net. It turns out despite having 'MODULES=most' in /srv/fai/nfsroot/live/filesystem.dir/etc/initramfs-tools/initramfs.conf, the modules 'virtio_pci', 'virtio_blk' and 'virtio_ring' are included, but 'virtio_net' is missing. I'm still looking for a good workaround to get an virtio-net enabled guest installed via an FAI nfsroot. -- 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/20100824064311.16257.51356.report...@localhost.localdomain
Bug#594165: linux-image-2.6-686: Kernel panics while transferring data through ethernet on compaq dx2000 ST/CT
Package: linux-image-2.6-686 Version: 2.6.32+28 Severity: normal If I don't use network, it doesn't panic at all. But as soon as I transfer a lot of data by cifs or use netperf to stress eth0, it panics. Information about eth0 by lshal: udi = '/org/freedesktop/Hal/devices/pci_14e4_1696' info.linux.driver = 'tg3' (string) info.parent = '/org/freedesktop/Hal/devices/pci_8086_244e' (string) info.product = 'NetXtreme BCM5782 Gigabit Ethernet' (string) panic message through serial console: HARDWARE ERROR CPU 0: Machine Check Exception:4 Bank 0: b2001040080f RIP !INEXACT! 00:c1206f17 TSC 1412c9d8df3 PROCESSOR 0:f33 TIME 1282627487 SOCKET 0 APIC 0 No human readable MCE decoding support on this CPU type. Run the message through 'mcelog --ascii' to decode. This is not a software problem! Machine check: Processor context corrupt Kernel panic - not syncing: Fatal Machine check Pid: 2173, comm: smbd Tainted: G M 2.6.32-5-686 #1 Call Trace: [c126ab04] ? panic+0x38/0xe4 [c100e11e] ? mce_panic+0x124/0x139 [c100e810] ? do_machine_check+0x543/0x6e3 [c1206f17] ? tcp_rcv_established+0x303/0x626 [c100e2cd] ? do_machine_check+0x0/0x6e3 [c126c803] ? error_code+0x73/0x78 [c1206f17] ? tcp_rcv_established+0x303/0x626 [c120d430] ? tcp_v4_do_rcv+0x15f/0x2cf [c11fff2c] ? tcp_recvmsg+0x641/0x8b6 [c11ce005] ? sk_wait_data+0x90/0x99 [c11fed4c] ? tcp_prequeue_process+0x57/0x6b [c11ffd11] ? tcp_recvmsg+0x426/0x8b6 [c11cd1bb] ? sock_common_recvmsg+0x2f/0x45 [c11cb5a0] ? __sock_recvmsg+0x50/0x58 [c11cb645] ? sock_aio_read+0x9d/0xab [c10b2615] ? do_sync_read+0xc0/0x107 [c1041f20] ? param_set_invbool+0x22/0x35 [c10b21f9] ? fsnotify_access+0x5a/0x61 [c1101814] ? security_file_permission+0xc/0xd [c10b] ? pcpu_alloc+0x470/0x77c [c10b30bc] ? sys_read+0x3c/0x63 [c10030fb] ? sysenter_do_call+0x12/0x28 [drm:drm_fb_helper_panic] *ERROR* panic occurred, switching back to text console panic message with nomce boot option through serial console: [ 159.129796] BUG: unable to handle kernel paging request at 670592c8 [ 159.133751] IP: [c120383d] tcp_event_data_recv+0x4/0x343 [ 159.133751] *pde = [ 159.133751] Oops: 0002 [#1] SMP [ 159.133751] last sysfs file: /sys/devices/pci:00/:00:1f.1/host0/target0:0:0/0:0:0:0/block/sda/uevent [ 159.133751] Modules linked in: speedstep_lib cpufreq_stats cpufreq_conservative cpufreq_userspace cpufreq_powersave ppdev lp sco bridge stp bnep l2cap crc16 bluetooth rfkill binfmt_misc fuse snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq i915 drm_kms_helper snd_timer drm shpchp snd_seq_device pci_hotplug snd i2c_algo_bit i2c_i801 soundcore i2c_core video rng_core output parport_pc evdev psmouse serio_raw parport snd_page_alloc pcspkr button processor usbhid hid ext3 jbd mbcache sd_mod crc_t10dif ata_generic uhci_hcd ata_piix tg3 libata thermal libphy ehci_hcd floppy usbcore thermal_sys scsi_mod nls_base [last unloaded: scsi_wait_scan] [ 159.133751] [ 159.133751] Pid: 2369, comm: smbd Not tainted (2.6.32-5-686 #1) HP dx2000 ST(PE677AV) [ 159.133751] EIP: 0060:[c120383d] EFLAGS: 00010202 CPU: 0 [ 159.133751] EIP is at tcp_event_data_recv+0x4/0x343 [ 159.133751] EAX: ddf0a680 EBX: ddf0a680 ECX: ddf0a680 EDX: dea61d00 [ 159.133751] ESI: 0001 EDI: dea61d00 EBP: 05b4 ESP: de217d58 [ 159.133751] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 159.133751] Process smbd (pid: 2369, ti=de216000 task=dea4f740 task.ti=de216000) [ 159.133751] Stack: [ 159.133751] ddf0a680 0001 dea61d00 05b4 c120708b dde18044 0014 0001 [ 159.133751] 0 dea61d20 ddf0a680 dea61d00 c120d430 05c8 [ 159.133751] 0 c11fff2c dde18030 dde18044 ddf0a680 ddf0a680 de217e18 c11ce005 [ 159.133751] Call Trace: [ 159.133751] [c120708b] ? tcp_rcv_established+0x477/0x626 [ 159.133751] [c120d430] ? tcp_v4_do_rcv+0x15f/0x2cf [ 159.133751] [c11fff2c] ? tcp_recvmsg+0x641/0x8b6 [ 159.133751] [c11ce005] ? sk_wait_data+0x90/0x99 [ 159.133751] [c11fed4c] ? tcp_prequeue_process+0x57/0x6b [ 159.133751] [c11ffd11] ? tcp_recvmsg+0x426/0x8b6 [ 159.133751] [c11cd1bb] ? sock_common_recvmsg+0x2f/0x45 [ 159.133751] [c11cb5a0] ? __sock_recvmsg+0x50/0x58 [ 159.133751] [c11cb645] ? sock_aio_read+0x9d/0xab [ 159.133751] [e02d61e5] ? tg3_poll+0x14f/0x820 [tg3] [ 159.133751] [c10b2615] ? do_sync_read+0xc0/0x107 [ 159.133751] [c10437d6] ? autoremove_wake_function+0x0/0x2d [ 159.133751] [c10b21f9] ? fsnotify_access+0x5a/0x61 [ 159.133751] [c1101814] ? security_file_permission+0xc/0xd [ 159.133751] [c10b2fdd] ? vfs_read+0x8c/0xd3 [ 159.133751] [c10b30bc] ? sys_read+0x3c/0x63 [ 159.133751] [c10030fb] ? sysenter_do_call+0x12/0x28 [ 159.133751] Code: d2 80 cc 01 66 89 83 90 03 00 00 89 d8 e8 86 e5 ff ff 85 c0 75 0a 31 d2 89 d8 ff 93 68 01 00 00 58 5a 5b 5e 5f 5d c3 55 57 56 53 89 c3 83 ec 14 89 54 24 0c 8b b0 a8 02
Processed: bug 594125 is forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=29406
Processing commands for cont...@bugs.debian.org: forwarded 594125 https://bugs.freedesktop.org/show_bug.cgi?id=29406 Bug #594125 [linux-image-2.6.35-trunk-amd64] [linux-image-2.6.35-trunk-amd64] BSD ring buffer implementation makes suspend to ram unreliable Set Bug forwarded-to-address to 'https://bugs.freedesktop.org/show_bug.cgi?id=29406'. thanks Stopping processing here. Please contact me if you need assistance. -- 594125: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594125 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.128263878121366.transcr...@bugs.debian.org
Bug#594125: [linux-image-2.6.35-trunk-amd64] BSD ring buffer implementation makes suspend to ram unreliable
severity 594125 important stop On Mon, Aug 23, 2010 at 10:28:31PM +0200, Florian Kriener wrote: Package: linux-image-2.6.35-trunk-amd64 Version: 1~experimental.2 Severity: grave Tags: patch important is enough. --- Please enter the report below this line. --- There is a bug in the linux kernel 2.6.35, that makes suspend to ram unusable (it seems to be fixed in 2.6.36-rc2) [1]. The symptoms are: - Suspend to ram from X hangs the computer, the only option is to press the power button for ~5 sec and thus forcefully turning off the computer (SysRq does not work for me). After a while (when not turning off the computer of cause) the fan goes to full power. - However, suspend to ram from console works. - The hang does happen every time on my laptop. However, on some computers that seems to happen only sporadically. experienced similar stuff here on a X201 Thinkpad. The link [1] contains two possible solutions for this problem. 1. Turn off BSD completely by replacing the corresponding define in i915_drv.h with #define HAS_BSD(dev)(0) 2. 2.6.36-rc2 seems to fix the problem (according to a comment on [1]). [1] https://bugs.freedesktop.org/show_bug.cgi?id=29406 ok marking as forwarded. once a specific patch emerges out of that report, we can add it, otherwise it should go through stable. -- 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/20100824082611.gg1...@baikonur.stro.at
Bug#594118: initramfs-tools: Generating image error. Unexpected operator
On Mon, Aug 23, 2010 at 09:50:34PM +0200, Rodolfo Garcia wrote: Package: initramfs-tools Version: 0.98 Severity: important Hi! I have a problem trying to generate a new initram: debian:~# update-initramfs -u -k all update-initramfs: Generating /boot/initrd.img-2.6.32-5-686 [: 33: #: unexpected operator /boot/initrd.img-2.6.18-6-686 does not exist. Cannot update. debian:~# please post the output of: ls -l /var/lib/initramfs-tools/ and of sh -x /usr/sbin/update-initramfs -u thanks. -- 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/20100824083414.gh1...@baikonur.stro.at
Processed: Bug#594125: [linux-image-2.6.35-trunk-amd64] BSD ring buffer implementation makes suspend to ram unreliable
Processing commands for cont...@bugs.debian.org: severity 594125 important Bug #594125 [linux-image-2.6.35-trunk-amd64] [linux-image-2.6.35-trunk-amd64] BSD ring buffer implementation makes suspend to ram unreliable Severity set to 'important' from 'grave' stop Stopping processing here. Please contact me if you need assistance. -- 594125: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594125 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.128263945927665.transcr...@bugs.debian.org
Bug#594156: modules=most does not add virtio_net
tags 594156 unreproducible moreinfo stop On Tue, Aug 24, 2010 at 08:43:11AM +0200, Reinhard Tartler wrote: Package: initramfs-tools Version: 0.97 Severity: normal Hi, I'm using initramfs-tools in the context of an FAI nfsroot, read, I want to have it booted in a KVM guest with both virtio hard drives and virtio_net. It turns out despite having 'MODULES=most' in /srv/fai/nfsroot/live/filesystem.dir/etc/initramfs-tools/initramfs.conf, the modules 'virtio_pci', 'virtio_blk' and 'virtio_ring' are included, but 'virtio_net' is missing. I'm still looking for a good workaround to get an virtio-net enabled guest installed via an FAI nfsroot. lsinitramfs /boot/initrd.img-2.6.32-5-amd64 | grep virtio_net lib/modules/2.6.32-5-amd64/kernel/drivers/net/virtio_net.ko I can only guess that you are using an outdated version of initramfs-tools. please upgrade and retry. -- 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/20100824083643.gj1...@baikonur.stro.at
Bug#594156: modules=most does not add virtio_net
reassign 594156 fai-server found 594156 3.3.5 stop On Tue, Aug 24, 2010 at 10:36:43 (CEST), maximilian attems wrote: I'm using initramfs-tools in the context of an FAI nfsroot, read, I want to have it booted in a KVM guest with both virtio hard drives and virtio_net. It turns out despite having 'MODULES=most' in /srv/fai/nfsroot/live/filesystem.dir/etc/initramfs-tools/initramfs.conf, the modules 'virtio_pci', 'virtio_blk' and 'virtio_ring' are included, but 'virtio_net' is missing. I'm still looking for a good workaround to get an virtio-net enabled guest installed via an FAI nfsroot. lsinitramfs /boot/initrd.img-2.6.32-5-amd64 | grep virtio_net lib/modules/2.6.32-5-amd64/kernel/drivers/net/virtio_net.ko I can only guess that you are using an outdated version of initramfs-tools. please upgrade and retry. You're right, the problem does not seem to be in initramfs-tools. In fact, reinstalling initramfs-tools_0.97 in the generated fai chroot fixes this problem as well. It seems to me that make-fai-nfsroot is installing and/or calling update-initramfs in a bad order that leads to the module 'virtio_net' ending up in the initramfs. I'm CC'ing mikap with this email. Mikap, perhaps you have some idea what might go wrong here? I'm using a more or less basic lenny installation (in an openvz container, but that shouldn't matter) with the packages downloaded from the fai source: deb http://www.informatik.uni-koeln.de/fai/download lenny koeln -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- 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/87pqx8s4gz@faui44a.informatik.uni-erlangen.de
Processed: Re: Bug#594156: modules=most does not add virtio_net
Processing commands for cont...@bugs.debian.org: reassign 594156 fai-server Bug #594156 [initramfs-tools] modules=most does not add virtio_net Bug reassigned from package 'initramfs-tools' to 'fai-server'. Bug No longer marked as found in versions initramfs-tools/0.97. found 594156 3.3.5 Bug #594156 [fai-server] modules=most does not add virtio_net Bug Marked as found in versions fai/3.3.5. stop Stopping processing here. Please contact me if you need assistance. -- 594156: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594156 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.128264484412767.transcr...@bugs.debian.org
Bug#566574: linux-2.6: Yet another acpi_enforce_resources=lax victim
Package: linux-2.6 Severity: normal I believe this is another case of a user needing acpi_enforce_resources=lax in their kernel boot parameters. Ferry, can you try the advice provided here, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568126#44 and see if it helps. HTH, Dave W. -- 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/20100824104955.11052.87652.report...@localhost.localdomain
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
Package: initramfs-tools Version: 0.98 Severity: wishlist User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu maverick In the case where one is building an image and part of the image build involves running update-initramfs, it would be useful to have a single guaranteed way to disable installing any bootloader. Individual bootloader hooks in /etc/initramfs-tools/post-update.d/ can do this, but it would be better to have something central. Should this be an environment variable or perhaps a configuration file entry? (This was originally filed by Loïc Minier as https://bugs.launchpad.net/bugs/623375.) Thanks, -- Colin Watson [cjwat...@ubuntu.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/20100824132505.gc21...@riva.ucam.org
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 2010-08-24 at 14:25 +0100, Colin Watson wrote: Package: initramfs-tools Version: 0.98 Severity: wishlist User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu maverick In the case where one is building an image and part of the image build involves running update-initramfs, it would be useful to have a single guaranteed way to disable installing any bootloader. Individual bootloader hooks in /etc/initramfs-tools/post-update.d/ can do this, Minus the -tools; it's supposed to be shared with any other initramfs builders. but it would be better to have something central. Should this be an environment variable or perhaps a configuration file entry? So far as I can see, the only reason to override post-update hooks is that one is cross-building an initramfs. In that case update-initramfs is still used for updating the host's initramfs and should continue to invoke the hooks when doing that. So this should be a command-line option and not a configuration option. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, Aug 24, 2010 at 02:45:44PM +0100, Ben Hutchings wrote: On Tue, 2010-08-24 at 14:25 +0100, Colin Watson wrote: In the case where one is building an image and part of the image build involves running update-initramfs, it would be useful to have a single guaranteed way to disable installing any bootloader. Individual bootloader hooks in /etc/initramfs-tools/post-update.d/ can do this, Minus the -tools; it's supposed to be shared with any other initramfs builders. Oops, yes. but it would be better to have something central. Should this be an environment variable or perhaps a configuration file entry? So far as I can see, the only reason to override post-update hooks is that one is cross-building an initramfs. In that case update-initramfs is still used for updating the host's initramfs and should continue to invoke the hooks when doing that. So this should be a command-line option and not a configuration option. Consider building a filesystem image inside a chroot which one is about to build into a live filesystem image with mksquashfs or something. In the event that it contains flash-kernel, then the flash-kernel hook (once such a thing exists; in the meantime, the hardcoded flash-kernel code in run_bootloader) will write to the host system's flash memory. (Take another similar example if you disagree with the precise details of this one; LILO may well have similar properties.) In this case, changing update-initramfs' command line is likely to be most inconvenient, as it will be called from postinst scripts and the like. -- Colin Watson [cjwat...@debian.org] -- 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/20100824135404.gd21...@riva.ucam.org
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 2010-08-24 at 14:54 +0100, Colin Watson wrote: [...] Consider building a filesystem image inside a chroot which one is about to build into a live filesystem image with mksquashfs or something. In the event that it contains flash-kernel, then the flash-kernel hook (once such a thing exists; in the meantime, the hardcoded flash-kernel code in run_bootloader) will write to the host system's flash memory. (Take another similar example if you disagree with the precise details of this one; LILO may well have similar properties.) [...] If the live filesystem image includes a boot loader package with a kernel or initramfs hook, you're already running the risk of breaking the user's machine by installing a boot loader they never wanted. Protecting the build machine only hides the problem. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
* Ben Hutchings b...@decadent.org.uk [Tue Aug 24, 2010 at 03:09:06PM +0100]: On Tue, 2010-08-24 at 14:54 +0100, Colin Watson wrote: Consider building a filesystem image inside a chroot which one is about to build into a live filesystem image with mksquashfs or something. In the event that it contains flash-kernel, then the flash-kernel hook (once such a thing exists; in the meantime, the hardcoded flash-kernel code in run_bootloader) will write to the host system's flash memory. (Take another similar example if you disagree with the precise details of this one; LILO may well have similar properties.) If the live filesystem image includes a boot loader package with a kernel or initramfs hook, you're already running the risk of breaking the user's machine by installing a boot loader they never wanted. Protecting the build machine only hides the problem. So what's the proper way to disable the kernel or initramfs hook in your opinion? I explore the same problem Colin is talking about and deploying kernel and bootloader packages is something people building live systems have to deal with, so I'm interested in getting this situation fixed as well. regards, -mika- signature.asc Description: Digital signature
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 2010-08-24 at 16:24 +0200, Michael Prokop wrote: * Ben Hutchings b...@decadent.org.uk [Tue Aug 24, 2010 at 03:09:06PM +0100]: On Tue, 2010-08-24 at 14:54 +0100, Colin Watson wrote: Consider building a filesystem image inside a chroot which one is about to build into a live filesystem image with mksquashfs or something. In the event that it contains flash-kernel, then the flash-kernel hook (once such a thing exists; in the meantime, the hardcoded flash-kernel code in run_bootloader) will write to the host system's flash memory. (Take another similar example if you disagree with the precise details of this one; LILO may well have similar properties.) If the live filesystem image includes a boot loader package with a kernel or initramfs hook, you're already running the risk of breaking the user's machine by installing a boot loader they never wanted. Protecting the build machine only hides the problem. So what's the proper way to disable the kernel or initramfs hook in your opinion? [...] You're asking the wrong question here. What I think you want to know is 'how do I make sure that the boot loader is not installed where it's not wanted'. The obvious answer is 'don't install the package'. The user needs to configure it, in any case, and why not let them do that through the usual package configuration mechanism i.e. debconf? If you insist on installing such a package in the live system then it needs to support a safe configuration where it won't do anything until the user configures it to. It doesn't matter whether it's invoked by the kernel, initramfs-tools, or anything else. It *must* require user configuration. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
* Ben Hutchings b...@decadent.org.uk [Tue Aug 24, 2010 at 03:45:36PM +0100]: On Tue, 2010-08-24 at 16:24 +0200, Michael Prokop wrote: * Ben Hutchings b...@decadent.org.uk [Tue Aug 24, 2010 at 03:09:06PM +0100]: On Tue, 2010-08-24 at 14:54 +0100, Colin Watson wrote: Consider building a filesystem image inside a chroot which one is about to build into a live filesystem image with mksquashfs or something. In the event that it contains flash-kernel, then the flash-kernel hook (once such a thing exists; in the meantime, the hardcoded flash-kernel code in run_bootloader) will write to the host system's flash memory. (Take another similar example if you disagree with the precise details of this one; LILO may well have similar properties.) If the live filesystem image includes a boot loader package with a kernel or initramfs hook, you're already running the risk of breaking the user's machine by installing a boot loader they never wanted. Protecting the build machine only hides the problem. So what's the proper way to disable the kernel or initramfs hook in your opinion? You're asking the wrong question here. What I think you want to know is 'how do I make sure that the boot loader is not installed where it's not wanted'. The obvious answer is 'don't install the package'. The user needs to configure it, in any case, and why not let them do that through the usual package configuration mechanism i.e. debconf? If you insist on installing such a package in the live system then it needs to support a safe configuration where it won't do anything until the user configures it to. It doesn't matter whether it's invoked by the kernel, initramfs-tools, or anything else. It *must* require user configuration. Jepp. But isn't this (possibility for user configuration) exactly what Colin is requesting? I'm for example shipping lilo and grub with the live system (so the binaries as well as its documentation is available to the user), but nowadays the build process fails due to errors like: run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1 [...] run-parts: /etc/kernel/postinst.d/zz-lilo exited with return code 1 So the IMHO open question is what's a proper way to disable such stuff on request? regards, -mika- signature.asc Description: Digital signature
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 2010-08-24 at 16:55 +0200, Michael Prokop wrote: * Ben Hutchings b...@decadent.org.uk [Tue Aug 24, 2010 at 03:45:36PM +0100]: [...] If you insist on installing such a package in the live system then it needs to support a safe configuration where it won't do anything until the user configures it to. It doesn't matter whether it's invoked by the kernel, initramfs-tools, or anything else. It *must* require user configuration. Jepp. But isn't this (possibility for user configuration) exactly what Colin is requesting? No, he was asking for a way to disable hook invocation (which is something of a blunt tool). I'm for example shipping lilo and grub with the live system (so the binaries as well as its documentation is available to the user), but nowadays the build process fails due to errors like: run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1 [...] run-parts: /etc/kernel/postinst.d/zz-lilo exited with return code 1 So the IMHO open question is what's a proper way to disable such stuff on request? Report a bug on lilo; I suppose it should warn but still 'succeed' if /etc/lilo.conf is missing. elilo should do the same. This is my bug and I can fix it. :-) No idea about zipl but I doubt you care about s390 live media. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 24 Aug 2010 10:55:43 -0400 (EDT), Michael Prokop m...@debian.org wrote: Jepp. But isn't this (possibility for user configuration) exactly what Colin is requesting? I'm for example shipping lilo and grub with the live system (so the binaries as well as its documentation is available to the user), but nowadays the build process fails due to errors like: run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1 [...] run-parts: /etc/kernel/postinst.d/zz-lilo exited with return code 1 So the IMHO open question is what's a proper way to disable such stuff on request? I am not a member of the kernel team. I'm just an ordinary user. So I speak with zero authority. And Ben may have his own ideas that he wishes to share. But one way to prevent a hook script from executing is to remove its executable attribute. For example, chmod -x /etc/kernel/postinst.d/zz-lilo chmod -x /etc/kernel/postrm.d/zz-lilo chmod -x /etc/initramfs/post-update.d/lilo This is not supported, of course, nor is it recommended. But it will work. As a general rule I agree with Ben. If you don't want the hook scripts to run, don't install the package. But in special situations, such as where you want the man page installed for reference purposes but don't want the package to be used, this is one solution. I have used this technique to run my own hook scripts instead of the package hook scripts without changing the package hook scripts when the package hook scripts are buggy or incomplete. (But of course I open a bug report against the package too.) -- .''`. Stephen Powell : :' : `. `'` `- -- 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/2024030366.328076.1282663119633.javamail.r...@md01.wow.synacor.com
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
* Stephen Powell zlinux...@wowway.com [Tue Aug 24, 2010 at 11:18:39AM -0400]: On Tue, 24 Aug 2010 10:55:43 -0400 (EDT), Michael Prokop m...@debian.org wrote: Jepp. But isn't this (possibility for user configuration) exactly what Colin is requesting? I'm for example shipping lilo and grub with the live system (so the binaries as well as its documentation is available to the user), but nowadays the build process fails due to errors like: run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1 [...] run-parts: /etc/kernel/postinst.d/zz-lilo exited with return code 1 So the IMHO open question is what's a proper way to disable such stuff on request? I am not a member of the kernel team. I'm just an ordinary user. So I speak with zero authority. And Ben may have his own ideas that he wishes to share. But one way to prevent a hook script from executing is to remove its executable attribute. For example, chmod -x /etc/kernel/postinst.d/zz-lilo chmod -x /etc/kernel/postrm.d/zz-lilo chmod -x /etc/initramfs/post-update.d/lilo I'm aware of this, though I'd prefer a clean interface and not hacks. :) Especially since I'm not aware of a way how to chmod -x the files before installing the packages that fail during installation then. ;) regards, -mika- signature.asc Description: Digital signature
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 24 Aug 2010 11:08:47 -0400 (EDT), Ben Hutchings wrote: Report a bug on lilo; I suppose it should warn but still 'succeed' if /etc/lilo.conf is missing. elilo should do the same. This is my bug and I can fix it. :-) No idea about zipl but I doubt you care about s390 live media. The last time I checked, the official version of lilo in both squeeze and sid still did not include any hook scripts. Joachim Wiedorn's latest upstream version, 23.0, does include hook scripts; but Joachim is not the Debian package maintainer for lilo, William Pitcock still is. And William's official version does not include the hook scripts. Therefore, opening a Debian bug report against Joachim's unofficial Debian package is not appropriate. I do hope that the Technical Committee eventually gives control of the package to Joachim, but as far as I know, no decision has yet been made. (See bug number 587886.) -- .''`. Stephen Powell : :' : `. `'` `- -- 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/398211408.328559.1282663787782.javamail.r...@md01.wow.synacor.com
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
* Stephen Powell zlinux...@wowway.com [Tue Aug 24, 2010 at 11:29:47AM -0400]: On Tue, 24 Aug 2010 11:08:47 -0400 (EDT), Ben Hutchings wrote: Report a bug on lilo; I suppose it should warn but still 'succeed' if /etc/lilo.conf is missing. elilo should do the same. This is my bug and I can fix it. :-) No idea about zipl but I doubt you care about s390 live media. The last time I checked, the official version of lilo in both squeeze and sid still did not include any hook scripts. Joachim Wiedorn's latest upstream version, 23.0, does include hook scripts; but Joachim is not the Debian package maintainer for lilo, William Pitcock still is. And William's official version does not include the hook scripts. Therefore, opening a Debian bug report against Joachim's unofficial Debian package is not appropriate. I do hope that the Technical Committee eventually gives control of the package to Joachim, but as far as I know, no decision has yet been made. (See bug number 587886.) , [ aptitude changelog lilo/unstable | head ] | Get: Changelog of lilo | lilo (1:22.8-8.2) unstable; urgency=high | | * Non-maintainer upload. | * Add kernel and initramfs hook scripts to ensure lilo is reinstalled | whenever the kernel or initramfs is updated. (Closes: #590022) | | -- Ben Hutchings b...@decadent.org.uk Tue, 24 Aug 2010 04:25:24 +0100 | | lilo (1:22.8-8.1) unstable; urgency=low ` regards, -mika- signature.asc Description: Digital signature
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 24 Aug 2010 11:29:46 -0400 (EDT), Michael Prokop wrote: I'm aware of this, though I'd prefer a clean interface and not hacks. :) Especially since I'm not aware of a way how to chmod -x the files before installing the packages that fail during installation then. ;) I haven't been following the thread; so I don't know precisely what installation problem you are having. But Joachim's version of lilo does contain a bashism in it's initramfs hook which may be the cause of the installation failure. It uses substring expansion, which works with the Bourne Again Shell (bash), but not with the Bourne Shell or clones thereof (dash, ash, etc.). This is partly my fault, since his initramfs hook is based on a template which I provided which has the same problem. I have reported the problem to him, but so far I have not received a reply. If this is the cause of the installation failure, temporarily change the symlink /bin/sh to point to bash instead of dash. This will allow the package to install. Then, change #!/bin/sh on line 1 of /etc/initramfs/post-update.d/lilo to #!/bin/bash and change your symlink /bin/sh to point back to dash, or whatever it used to be pointing to. But maybe this is not why you are having installation problems. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/531310898.329182.1282664833095.javamail.r...@md01.wow.synacor.com
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 24 Aug 2010 11:37:29 -0400 (EDT), Michael Prokop wrote: , [ aptitude changelog lilo/unstable | head ] | Get: Changelog of lilo | lilo (1:22.8-8.2) unstable; urgency=high | | * Non-maintainer upload. | * Add kernel and initramfs hook scripts to ensure lilo is reinstalled | whenever the kernel or initramfs is updated. (Closes: #590022) | | -- Ben Hutchings b...@decadent.org.uk Tue, 24 Aug 2010 04:25:24 +0100 | | lilo (1:22.8-8.1) unstable; urgency=low ` Aha! Nice work, Ben. I didn't check far enough. I used this link http://packages.debian.org/search?keywords=lilosearchon=namessuite=unstablesection=all and saw that the current version was still 1:22.8-8.1. Either the package hasn't been uploaded yet or the web page is not in sync with the repository. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1917756674.329474.1282665282267.javamail.r...@md01.wow.synacor.com
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, Aug 24, 2010 at 04:08:47PM +0100, Ben Hutchings wrote: On Tue, 2010-08-24 at 16:55 +0200, Michael Prokop wrote: * Ben Hutchings b...@decadent.org.uk [Tue Aug 24, 2010 at 03:45:36PM +0100]: If you insist on installing such a package in the live system then it needs to support a safe configuration where it won't do anything until the user configures it to. It doesn't matter whether it's invoked by the kernel, initramfs-tools, or anything else. It *must* require user configuration. Jepp. But isn't this (possibility for user configuration) exactly what Colin is requesting? No, he was asking for a way to disable hook invocation (which is something of a blunt tool). Actually, what I want is a consistent way to disable bootloader invocation for all bootloaders, without necessarily requiring the bootloader package not to be installed (since that's sometimes extremely awkward to arrange). Exactly where this goes I can't say I mind. If the result is an extension to the bootloader/kernel policy that needs to be implemented in each bootloader package, that would be fine too. I'm for example shipping lilo and grub with the live system (so the binaries as well as its documentation is available to the user), but nowadays the build process fails due to errors like: run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1 [...] run-parts: /etc/kernel/postinst.d/zz-lilo exited with return code 1 So the IMHO open question is what's a proper way to disable such stuff on request? Report a bug on lilo; I suppose it should warn but still 'succeed' if /etc/lilo.conf is missing. elilo should do the same. This is my bug and I can fix it. :-) No idea about zipl but I doubt you care about s390 live media. What I specifically do not want is for top-level client programs to have to keep track of the different ways to ensure that each individual bootloader is disabled. -- Colin Watson [cjwat...@debian.org] -- 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/20100824155518.go12...@riva.ucam.org
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
* Stephen Powell zlinux...@wowway.com [Tue Aug 24, 2010 at 11:47:13AM -0400]: On Tue, 24 Aug 2010 11:29:46 -0400 (EDT), Michael Prokop wrote: I'm aware of this, though I'd prefer a clean interface and not hacks. :) Especially since I'm not aware of a way how to chmod -x the files before installing the packages that fail during installation then. ;) I haven't been following the thread; so I don't know precisely what installation problem you are having. But Joachim's version of lilo does contain a bashism in it's initramfs hook which may be the cause of the installation failure. It uses substring expansion, which works with the Bourne Again Shell (bash), but not with the Bourne Shell or clones thereof (dash, ash, etc.). This is partly my fault, since his initramfs hook is based on a template which I provided which has the same problem. I have reported the problem to him, but so far I have not received a reply. If this is the cause of the installation failure, temporarily change the symlink /bin/sh to point to bash instead of dash. This will allow the package to install. Then, change #!/bin/sh on line 1 of /etc/initramfs/post-update.d/lilo to #!/bin/bash and change your symlink /bin/sh to point back to dash, or whatever it used to be pointing to. But maybe this is not why you are having installation problems. No, it's not because of the bashism but because of: | Fatal: Cannot open: /etc/lilo.conf (I just verified that once more). See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594189#35 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594189#40 and my bugreport against the lilo package - #594213 regards, -mika- signature.asc Description: Digital signature
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
(Removed [e]l...@packages.debian.org from Cc) * Colin Watson cjwat...@debian.org [Tue Aug 24, 2010 at 04:55:28PM +0100]: On Tue, Aug 24, 2010 at 04:08:47PM +0100, Ben Hutchings wrote: On Tue, 2010-08-24 at 16:55 +0200, Michael Prokop wrote: * Ben Hutchings b...@decadent.org.uk [Tue Aug 24, 2010 at 03:45:36PM +0100]: If you insist on installing such a package in the live system then it needs to support a safe configuration where it won't do anything until the user configures it to. It doesn't matter whether it's invoked by the kernel, initramfs-tools, or anything else. It *must* require user configuration. Jepp. But isn't this (possibility for user configuration) exactly what Colin is requesting? No, he was asking for a way to disable hook invocation (which is something of a blunt tool). Actually, what I want is a consistent way to disable bootloader invocation for all bootloaders, without necessarily requiring the bootloader package not to be installed (since that's sometimes extremely awkward to arrange). Exactly where this goes I can't say I mind. If the result is an extension to the bootloader/kernel policy that needs to be implemented in each bootloader package, that would be fine too. ACK, I'd like something like that as well. I'm for example shipping lilo and grub with the live system (so the binaries as well as its documentation is available to the user), but nowadays the build process fails due to errors like: run-parts: /etc/initramfs/post-update.d//lilo exited with return code 1 [...] run-parts: /etc/kernel/postinst.d/zz-lilo exited with return code 1 So the IMHO open question is what's a proper way to disable such stuff on request? Report a bug on lilo; I suppose it should warn but still 'succeed' if /etc/lilo.conf is missing. elilo should do the same. This is my bug and I can fix it. :-) No idea about zipl but I doubt you care about s390 live media. What I specifically do not want is for top-level client programs to have to keep track of the different ways to ensure that each individual bootloader is disabled. FullACK. Sorry for the AOL style mail :) - I just want to express that I fully agree with Colin's wish. It's exactly what I consider interesting for live systems (and chroots) without having to work around any possible dangerous package. regards, -mika- signature.asc Description: Digital signature
Bug#582281: Bug fix confirmation
I see that this bug has already been marked resolved, but I just wanted to confirm that the backport of the upstream fix for this bug to kernel 2.6.32, which was originally written for a 2.6.35 kernel, does indeed fix the problem. I don't know if upstream backported the fix to 2.6.32 or if the Debian kernel team wrote their own patch, but package linux-source-2.6.32 version 2.6.32-20 does show the change to fs/partitions/ibm.c, and running a test case using stock kernel package linux-image-2.6.32-5-s390x version 2.6.32-20 shows that the problem has been fixed. Nice work, kernel team! Thanks! I can go back to running stock kernel images again instead of custom builds with custom patches. And thanks to upstream too! Peter, Moritz, Ben, thank you all. -- .''`. Stephen Powell : :' : `. `'` `- -- 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/1071420156.334874.1282675859457.javamail.r...@md01.wow.synacor.com
Bug#582826: Oops: 0002 unable to handle kernel paging request
The problem did not re-occur after upgrading to 2.6.26-24. Maybe fixed... Please close bug: I cannot reproduce anymore. Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- 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/201008242303.o7on3mrw017...@bari.maths.usyd.edu.au
Re: [Pkg-xen-devel] Graphics driver fixes for squeeze kernel-xen ?
On Mon, 2010-08-23 at 15:22 +0100, Ian Campbell wrote: On Mon, 2010-08-23 at 17:11 +0300, Pasi Kärkkäinen wrote: On Sun, Aug 22, 2010 at 01:16:20AM +0300, Pasi Kärkkäinen wrote: On Sat, Aug 21, 2010 at 10:27:16PM +0100, Ian Campbell wrote: On Sat, 2010-08-21 at 23:52 +0300, Pasi Kärkkäinen wrote: On Tue, Aug 17, 2010 at 09:28:32PM +0200, Bastian Blank wrote: Please send such mails to the maintainer of the package, not me. On Tue, Aug 17, 2010 at 08:55:33PM +0300, Pasi Kärkkäinen wrote: Is there a plan to update the dom0-capable kernel to the latest version from xen/stable-2.6.32.x branch? On the way. Oh, kernel update form xen/stable-2.6.32.x will bring Xen PV-on-HVM drivers aswell.. These drivers have also been backported to the regular 2.6.32 flavour for Squeeze so you won't need the Xen flavour to get this functionality. Oh nice! Thanks. Btw which kernel release in squeeze/testing adds these pv-on-hvm drivers? It will be in 2.6.32-21 which AIUI will be uploaded to Sid shortly. Sorry, it was misleading of me to suggest it was already in Squeeze. Sadly not. I have had to revert the addition of pvhvm because it causes an instant panic under KVM (at least in a 64-bit kernel). Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#582826: marked as done (Oops: 0002 unable to handle kernel paging request)
Your message dated Wed, 25 Aug 2010 02:51:38 +0100 with message-id 1282701098.22839.56.ca...@localhost and subject line Re: Bug#582826: Oops: 0002 unable to handle kernel paging request has caused the Debian Bug report #582826, regarding Oops: 0002 unable to handle kernel paging request to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 582826: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582826 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-source-2.6.26 Version: 2.6.26-21 Severity: normal My main file and login server machine crashed, with an Oops in the logs. I do not know whether this crash is reproducible: it crashed also a week earlier, but with nothing visible in the logs; it had been stable for months before these two crashes. Extract from /var/log/syslog at the crash: May 22 20:29:45 bari kernel: BUG: unable to handle kernel paging request at b14f6dc2 May 22 20:29:45 bari kernel: IP: [c014b326] find_get_pages+0x46/0x70 May 22 20:29:45 bari kernel: *pdpt = 31a75001 *pde = May 22 20:29:45 bari kernel: Oops: 0002 [#1] SMP May 22 20:29:45 bari kernel: Modules linked in: nfsd exportfs autofs4 quota_v2 fuse intel_agp agpgart usb_storage sg thermal 8250_pnp 8250 rtc_cmos rtc_core ehci_hcd parport_pc parport serial_core rtc_lib evdev i2c_i801 i2c_core processor thermal_sys May 22 20:29:45 bari kernel: May 22 20:29:45 bari kernel: Pid: 287, comm: kswapd0 Not tainted (2.6.26-pk03.17-svr #1) May 22 20:29:45 bari kernel: EIP: 0060:[c014b326] EFLAGS: 00010002 CPU: 5 May 22 20:29:45 bari kernel: EIP is at find_get_pages+0x46/0x70 May 22 20:29:45 bari kernel: EAX: b16f6cbe EBX: 0001 ECX: EDX: b14f6dbe May 22 20:29:45 bari kernel: ESI: EDI: e39c5dd8 EBP: f7e39e88 ESP: f7e39e40 May 22 20:29:45 bari kernel: DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 May 22 20:29:45 bari kernel: Process kswapd0 (pid: 287, ti=f7e39000 task=f7d7c6e0 task.ti=f7e39000) May 22 20:29:45 bari kernel: Stack: 000e e39c5de8 f7e39e80 f7e39e80 c01539c2 f7e39e88 May 22 20:29:45 bari kernel:e39c5d30 0080 c01545b4 000e 00155ca7 e39c5dd8 May 22 20:29:45 bari kernel: c520e340 c1edb9e0 c4f7bc60 c5278ae0 c39e7a60 c42deaa0 May 22 20:29:45 bari kernel: Call Trace: May 22 20:29:45 bari kernel: [c01539c2] pagevec_lookup+0x22/0x30 May 22 20:29:45 bari kernel: [c01545b4] __invalidate_mapping_pages+0x54/0x140 May 22 20:29:45 bari kernel: [c01546af] invalidate_mapping_pages+0xf/0x20 May 22 20:29:45 bari kernel: [c0186565] shrink_icache_memory+0x235/0x240 May 22 20:29:45 bari kernel: [c015609f] shrink_slab+0x12f/0x190 May 22 20:29:45 bari kernel: [c01564cd] kswapd+0x3cd/0x490 May 22 20:29:45 bari kernel: [c0154d70] isolate_pages_global+0x0/0x60 May 22 20:29:45 bari kernel: [c0136f80] autoremove_wake_function+0x0/0x50 May 22 20:29:45 bari kernel: [c0156100] kswapd+0x0/0x490 May 22 20:29:45 bari kernel: [c0136c99] kthread+0x39/0x70 May 22 20:29:45 bari kernel: [c0136c60] kthread+0x0/0x70 May 22 20:29:45 bari kernel: [c0103c83] kernel_thread_helper+0x7/0x14 May 22 20:29:45 bari kernel: === May 22 20:29:45 bari kernel: Code: 30 00 8d 47 04 89 f1 89 ea 89 1c 24 e8 84 63 10 00 85 c0 89 c3 74 1f 31 c9 8d 74 26 00 8b 54 8d 00 8b 02 f6 c4 40 74 03 8b 52 0c f0 ff 42 04 83 c1 01 39 cb 77 e7 8b 44 24 04 f0 ff 47 10 fb 83 May 22 20:29:45 bari kernel: EIP: [c014b326] find_get_pages+0x46/0x70 SS:ESP 0068:f7e39e40 May 22 20:29:45 bari kernel: ---[ end trace 34faad952d0fda3f ]--- At this last crash, I happened to be logged in via ssh, and in the ssh terminal window I had similar output, but curiously with a few lines interchanged in order (and I am not sure whether the terminal output or the syslog is correct; each line on the terminal was separately prefaced with Message from syslogd... and separated with blank lines): Message from sysl...@bari at Sat May 22 20:29:45 2010 ... bari kernel: Oops: 0002 [#1] SMP bari kernel: Process kswapd0 (pid: 287, ti=f7e39000 task=f7d7c6e0 task.ti=f7e39000) bari kernel: Stack: 000e e39c5de8 f7e39e80 f7e39e80 c01539c2 f7e39e88 bari kernel: c520e340 c1edb9e0 c4f7bc60 c5278ae0 c39e7a60 c42deaa0 bari kernel:e39c5d30 0080 c01545b4 000e 00155ca7 e39c5dd8 bari kernel: Call Trace: bari kernel: [c01539c2] pagevec_lookup+0x22/0x30 bari kernel: [c01545b4] __invalidate_mapping_pages+0x54/0x140 bari kernel: [c01546af]
linux-2.6_2.6.26-24lenny1_amd64.changes ACCEPTED
Notes: Mapping stable-security to proposed-updates. Accepted: linux-2.6_2.6.26-24lenny1.diff.gz to main/l/linux-2.6/linux-2.6_2.6.26-24lenny1.diff.gz linux-2.6_2.6.26-24lenny1.dsc to main/l/linux-2.6/linux-2.6_2.6.26-24lenny1.dsc linux-doc-2.6.26_2.6.26-24lenny1_all.deb to main/l/linux-2.6/linux-doc-2.6.26_2.6.26-24lenny1_all.deb linux-headers-2.6.26-2-all-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-all-amd64_2.6.26-24lenny1_amd64.deb linux-headers-2.6.26-2-all_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-all_2.6.26-24lenny1_amd64.deb linux-headers-2.6.26-2-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-amd64_2.6.26-24lenny1_amd64.deb linux-headers-2.6.26-2-common-openvz_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-common-openvz_2.6.26-24lenny1_amd64.deb linux-headers-2.6.26-2-common-vserver_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-common-vserver_2.6.26-24lenny1_amd64.deb linux-headers-2.6.26-2-common-xen_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-common-xen_2.6.26-24lenny1_amd64.deb linux-headers-2.6.26-2-common_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-common_2.6.26-24lenny1_amd64.deb linux-headers-2.6.26-2-openvz-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-openvz-amd64_2.6.26-24lenny1_amd64.deb linux-headers-2.6.26-2-vserver-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-vserver-amd64_2.6.26-24lenny1_amd64.deb linux-headers-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-headers-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb linux-image-2.6.26-2-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-image-2.6.26-2-amd64_2.6.26-24lenny1_amd64.deb linux-image-2.6.26-2-openvz-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-image-2.6.26-2-openvz-amd64_2.6.26-24lenny1_amd64.deb linux-image-2.6.26-2-vserver-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-image-2.6.26-2-vserver-amd64_2.6.26-24lenny1_amd64.deb linux-image-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-image-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb linux-libc-dev_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-libc-dev_2.6.26-24lenny1_amd64.deb linux-manual-2.6.26_2.6.26-24lenny1_all.deb to main/l/linux-2.6/linux-manual-2.6.26_2.6.26-24lenny1_all.deb linux-modules-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/linux-modules-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb linux-patch-debian-2.6.26_2.6.26-24lenny1_all.deb to main/l/linux-2.6/linux-patch-debian-2.6.26_2.6.26-24lenny1_all.deb linux-source-2.6.26_2.6.26-24lenny1_all.deb to main/l/linux-2.6/linux-source-2.6.26_2.6.26-24lenny1_all.deb linux-support-2.6.26-2_2.6.26-24lenny1_all.deb to main/l/linux-2.6/linux-support-2.6.26-2_2.6.26-24lenny1_all.deb linux-tree-2.6.26_2.6.26-24lenny1_all.deb to main/l/linux-2.6/linux-tree-2.6.26_2.6.26-24lenny1_all.deb xen-linux-system-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb to main/l/linux-2.6/xen-linux-system-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb Override entries for your package: linux-2.6_2.6.26-24lenny1.dsc - source devel linux-doc-2.6.26_2.6.26-24lenny1_all.deb - optional doc linux-headers-2.6.26-2-all-amd64_2.6.26-24lenny1_amd64.deb - optional devel linux-headers-2.6.26-2-all_2.6.26-24lenny1_amd64.deb - optional devel linux-headers-2.6.26-2-amd64_2.6.26-24lenny1_amd64.deb - optional devel linux-headers-2.6.26-2-common-openvz_2.6.26-24lenny1_amd64.deb - optional devel linux-headers-2.6.26-2-common-vserver_2.6.26-24lenny1_amd64.deb - optional devel linux-headers-2.6.26-2-common-xen_2.6.26-24lenny1_amd64.deb - optional devel linux-headers-2.6.26-2-common_2.6.26-24lenny1_amd64.deb - optional devel linux-headers-2.6.26-2-openvz-amd64_2.6.26-24lenny1_amd64.deb - optional devel linux-headers-2.6.26-2-vserver-amd64_2.6.26-24lenny1_amd64.deb - optional devel linux-headers-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb - optional devel linux-image-2.6.26-2-amd64_2.6.26-24lenny1_amd64.deb - optional admin linux-image-2.6.26-2-openvz-amd64_2.6.26-24lenny1_amd64.deb - optional admin linux-image-2.6.26-2-vserver-amd64_2.6.26-24lenny1_amd64.deb - optional admin linux-image-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb - optional admin linux-libc-dev_2.6.26-24lenny1_amd64.deb - optional devel linux-manual-2.6.26_2.6.26-24lenny1_all.deb - optional doc linux-modules-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb - optional admin linux-patch-debian-2.6.26_2.6.26-24lenny1_all.deb - optional devel linux-source-2.6.26_2.6.26-24lenny1_all.deb - optional devel linux-support-2.6.26-2_2.6.26-24lenny1_all.deb - optional devel linux-tree-2.6.26_2.6.26-24lenny1_all.deb - optional devel xen-linux-system-2.6.26-2-xen-amd64_2.6.26-24lenny1_amd64.deb - extra admin Announcing to
Bug#589179: marked as done (linux-image-2.6.26-2-686: heap base address is not randomised when randomize_va_space is set to 2)
Your message dated Wed, 25 Aug 2010 01:56:04 +
with message-id e1oo5dg-00021n...@franck.debian.org
and subject line Bug#589179: fixed in linux-2.6 2.6.26-24lenny1
has caused the Debian Bug report #589179,
regarding linux-image-2.6.26-2-686: heap base address is not randomised when
randomize_va_space is set to 2
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
589179: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589179
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: linux-2.6
Version: 2.6.26-24
Severity: normal
Hi,
When running the latest stable Debian kernel the base address of a heap is not
randomised regardless of the
setting for randomize_va_space (it is set to 2 by default). This can be
observed by using a simple .c
program (below) or using the paxtest suite available from here:
http://grsecurity.net/~spender/paxtest-0.9.9.tgz
Please bear in mind that I only have tested this within virtualised environment
and I have only tested a x86 system.
sample c program I used:
#include stdio.h
#include stdlib.h
void main() {
char * p = (char *) malloc(40*sizeof(char));
printf(address: %x\n,p);
}
compile and run:
gcc -o heap heap.c
watch -n 1 ./heap
reproducible: always
steps to reproduce:
- compile and run paxtest or simple .c program from above
expected results:
- randomised addressed for heap allocations - address of the malloc'ed var
should be different each time the program is run.
For the paxtest - it should not report 'no randomisation' for 'Heap
randomisation test (ET_EXEC)'
actual results:
- no randomisation of the heap base addresses.
-- Package-specific info:
** Version:
Linux version 2.6.26-2-686 (Debian 2.6.26-24) (da...@debian.org) (gcc version
4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Mon Jun 21 05:58:44 UTC
2010
** Command line:
root=/dev/hda1 ro quiet
** Not tainted
** Kernel log:
[5.227996] usb 1-1: new full speed USB device using uhci_hcd and address 2
[5.485259] PM: Starting manual resume from disk
[5.517670] EXT3-fs: INFO: recovery required on readonly filesystem.
[5.517674] EXT3-fs: write access will be enabled during recovery.
[5.590701] usb 1-1: configuration #1 chosen from 1 choice
[5.643904] usb 1-1: New USB device found, idVendor=0627, idProduct=0001
[5.643909] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[5.643912] usb 1-1: Product: QEMU USB Tablet
[5.643914] usb 1-1: Manufacturer: QEMU 0.12.4
[5.643916] usb 1-1: SerialNumber: 1
[5.710778] usbcore: registered new interface driver hiddev
[5.735324] input: QEMU 0.12.4 QEMU USB Tablet as /class/input/input1
[5.739330] input,hidraw0: USB HID v0.01 Pointer [QEMU 0.12.4 QEMU USB
Tablet] on usb-:00:01.2-1
[5.739330] usbcore: registered new interface driver usbhid
[5.739330] usbhid: v2.6:USB HID core driver
[6.359345] kjournald starting. Commit interval 5 seconds
[6.359345] EXT3-fs: recovery complete.
[6.359345] EXT3-fs: mounted filesystem with ordered data mode.
[9.039926] udevd version 125 started
[9.809803] udev: renamed network interface eth0 to eth6
[ 10.587020] piix4_smbus :00:01.3: Found :00:01.3 device
[ 10.797426] input: Power Button (FF) as /class/input/input2
[ 10.828746] ACPI: Power Button (FF) [PWRF]
[ 11.152352] input: PC Speaker as /class/input/input3
[ 11.368600] input: ImExPS/2 Generic Explorer Mouse as /class/input/input4
[ 11.472414] parport_pc 00:05: reported by Plug and Play ACPI
[ 11.472414] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[ 12.741775] Adding 489940k swap on /dev/hda5. Priority:-1 extents:1
across:489940k
[ 113.697388] EXT3 FS on hda1, internal journal
[ 114.415953] loop: module loaded
[ 121.243828] NET: Registered protocol family 10
[ 121.246126] lo: Disabled Privacy Extensions
[ 122.529155] lp0: using parport0 (interrupt-driven).
[ 122.667535] ppdev: user-space parallel port driver
[ 126.465548] eth6: link up, 100Mbps, full-duplex, lpa 0x05E1
[ 144.751798] eth6: no IPv6 routers present
[ 808.293430] BUG: soft lockup - CPU#0 stuck for 104s! [swapper:0]
[ 808.293430] Modules linked in: ppdev lp ipv6 cpufreq_ondemand cpufreq_stats
freq_table cpufreq_userspace cpufreq_powersave cpufreq_conservative loop
parport_pc parport pcspkr psmouse serio_raw button i2c_piix4 i2c_core joydev
evdev usbhid hid ff_memless ext3 jbd mbcache ide_cd_mod cdrom ide_disk
ata_generic libata scsi_mod 8139too dock floppy 8139cp mii uhci_hcd piix
ide_pci_generic usbcore ide_core thermal processor fan thermal_sys [last
Bug#589179: marked as done (linux-image-2.6.26-2-686: heap base address is not randomised when randomize_va_space is set to 2)
Your message dated Wed, 25 Aug 2010 01:57:58 +
with message-id e1oo5fw-0002fa...@franck.debian.org
and subject line Bug#589179: fixed in user-mode-linux 2.6.26-1um-2+24lenny1
has caused the Debian Bug report #589179,
regarding linux-image-2.6.26-2-686: heap base address is not randomised when
randomize_va_space is set to 2
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
589179: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589179
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: linux-2.6
Version: 2.6.26-24
Severity: normal
Hi,
When running the latest stable Debian kernel the base address of a heap is not
randomised regardless of the
setting for randomize_va_space (it is set to 2 by default). This can be
observed by using a simple .c
program (below) or using the paxtest suite available from here:
http://grsecurity.net/~spender/paxtest-0.9.9.tgz
Please bear in mind that I only have tested this within virtualised environment
and I have only tested a x86 system.
sample c program I used:
#include stdio.h
#include stdlib.h
void main() {
char * p = (char *) malloc(40*sizeof(char));
printf(address: %x\n,p);
}
compile and run:
gcc -o heap heap.c
watch -n 1 ./heap
reproducible: always
steps to reproduce:
- compile and run paxtest or simple .c program from above
expected results:
- randomised addressed for heap allocations - address of the malloc'ed var
should be different each time the program is run.
For the paxtest - it should not report 'no randomisation' for 'Heap
randomisation test (ET_EXEC)'
actual results:
- no randomisation of the heap base addresses.
-- Package-specific info:
** Version:
Linux version 2.6.26-2-686 (Debian 2.6.26-24) (da...@debian.org) (gcc version
4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Mon Jun 21 05:58:44 UTC
2010
** Command line:
root=/dev/hda1 ro quiet
** Not tainted
** Kernel log:
[5.227996] usb 1-1: new full speed USB device using uhci_hcd and address 2
[5.485259] PM: Starting manual resume from disk
[5.517670] EXT3-fs: INFO: recovery required on readonly filesystem.
[5.517674] EXT3-fs: write access will be enabled during recovery.
[5.590701] usb 1-1: configuration #1 chosen from 1 choice
[5.643904] usb 1-1: New USB device found, idVendor=0627, idProduct=0001
[5.643909] usb 1-1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[5.643912] usb 1-1: Product: QEMU USB Tablet
[5.643914] usb 1-1: Manufacturer: QEMU 0.12.4
[5.643916] usb 1-1: SerialNumber: 1
[5.710778] usbcore: registered new interface driver hiddev
[5.735324] input: QEMU 0.12.4 QEMU USB Tablet as /class/input/input1
[5.739330] input,hidraw0: USB HID v0.01 Pointer [QEMU 0.12.4 QEMU USB
Tablet] on usb-:00:01.2-1
[5.739330] usbcore: registered new interface driver usbhid
[5.739330] usbhid: v2.6:USB HID core driver
[6.359345] kjournald starting. Commit interval 5 seconds
[6.359345] EXT3-fs: recovery complete.
[6.359345] EXT3-fs: mounted filesystem with ordered data mode.
[9.039926] udevd version 125 started
[9.809803] udev: renamed network interface eth0 to eth6
[ 10.587020] piix4_smbus :00:01.3: Found :00:01.3 device
[ 10.797426] input: Power Button (FF) as /class/input/input2
[ 10.828746] ACPI: Power Button (FF) [PWRF]
[ 11.152352] input: PC Speaker as /class/input/input3
[ 11.368600] input: ImExPS/2 Generic Explorer Mouse as /class/input/input4
[ 11.472414] parport_pc 00:05: reported by Plug and Play ACPI
[ 11.472414] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[ 12.741775] Adding 489940k swap on /dev/hda5. Priority:-1 extents:1
across:489940k
[ 113.697388] EXT3 FS on hda1, internal journal
[ 114.415953] loop: module loaded
[ 121.243828] NET: Registered protocol family 10
[ 121.246126] lo: Disabled Privacy Extensions
[ 122.529155] lp0: using parport0 (interrupt-driven).
[ 122.667535] ppdev: user-space parallel port driver
[ 126.465548] eth6: link up, 100Mbps, full-duplex, lpa 0x05E1
[ 144.751798] eth6: no IPv6 routers present
[ 808.293430] BUG: soft lockup - CPU#0 stuck for 104s! [swapper:0]
[ 808.293430] Modules linked in: ppdev lp ipv6 cpufreq_ondemand cpufreq_stats
freq_table cpufreq_userspace cpufreq_powersave cpufreq_conservative loop
parport_pc parport pcspkr psmouse serio_raw button i2c_piix4 i2c_core joydev
evdev usbhid hid ff_memless ext3 jbd mbcache ide_cd_mod cdrom ide_disk
ata_generic libata scsi_mod 8139too dock floppy 8139cp mii uhci_hcd piix
ide_pci_generic usbcore ide_core thermal processor fan
Bug#570382: after upgrade: vlogin: openpty(): No such file or directory
On Mon, 23 Aug 2010 21:56:17 +0200 (CEST), Tomas Pospisek t...@sourcepole.ch wrote: On a different note: the last update to the most recent DSA kernels [2] went completely smoothly - that is all vservers restarted without a hickup. Makes me wonder if that was caused by a change in the 2.6.26-24lenny1 kernel? We'll see at the next upgrade. I noticed this too, last DSA went perfectly. Before I would get at least one guest on each machine that would exhibit this problem, this time I got none. However, I *did* get one on my amd64 box. All the others were i386 micah pgpNLGDLqcRcL.pgp Description: PGP signature
Bug#594189: initramfs-tools: environment variable to disable run_bootloader
On Tue, 2010-08-24 at 16:55 +0100, Colin Watson wrote: On Tue, Aug 24, 2010 at 04:08:47PM +0100, Ben Hutchings wrote: On Tue, 2010-08-24 at 16:55 +0200, Michael Prokop wrote: * Ben Hutchings b...@decadent.org.uk [Tue Aug 24, 2010 at 03:45:36PM +0100]: If you insist on installing such a package in the live system then it needs to support a safe configuration where it won't do anything until the user configures it to. It doesn't matter whether it's invoked by the kernel, initramfs-tools, or anything else. It *must* require user configuration. Jepp. But isn't this (possibility for user configuration) exactly what Colin is requesting? No, he was asking for a way to disable hook invocation (which is something of a blunt tool). Actually, what I want is a consistent way to disable bootloader invocation for all bootloaders, without necessarily requiring the bootloader package not to be installed (since that's sometimes extremely awkward to arrange). Exactly where this goes I can't say I mind. If the result is an extension to the bootloader/kernel policy that needs to be implemented in each bootloader package, that would be fine too. [...] OK, so something like this: Boot loader packages must be installable on the filesystem in a disabled state where they will not write to the boot sector or other non-filesystem storage. While a boot loader is disabled, any kernel and initramfs hooks it includes must do nothing except (optionally) printing a warning that the boot loader is disabled, and must exit successfully. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: forcibly merging 588782 586369
Processing commands for cont...@bugs.debian.org: forcemerge 588782 586369 Bug#588782: openvz: openvz and ext4 core dump on quota check Bug#586369: linux-image-2.6.32-5-openvz-686: Kernel oops, with openvz kernel and ext4 Forcibly Merged 586369 588782. thanks Stopping processing here. Please contact me if you need assistance. -- 588782: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588782 586369: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586369 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.12827116719685.transcr...@bugs.debian.org
Bug#588782: same bug as 586369
On Tue, 2010-08-24 at 08:07 +0200, Nicolas Parpandet wrote: same bug as 586369 Right, it looks like it. Has this been fixed in a more recent version? If not, please report this upstream at http://bugzilla.openvz.org/ and let us know the number or URL so we can track it. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#594149: linux-image-2.6.32-5-amd64: Lid switch correct every other time; suspend every other lid close; Samsung N150-11 netbook
On Mon, 2010-08-23 at 23:21 -0400, Doug Currie wrote: Package: linux-2.6 Version: 2.6.32-20 Severity: normal Samsung N150-11 netbook. Each lid closeopen toggles the lid switch state so when the lid is open, half the time it reports closed: e...@esammy:~$ cat /proc/acpi/button/lid/LID0/state state: open # close open lid e...@esammy:~$ cat /proc/acpi/button/lid/LID0/state state: closed So, the netbook only suspends every other time the lid is closed. This could be dangerous with the netbook stowed in running mode getting hot. [...] The firmware should throttle the processor and eventually power-off the system if it is too hot. But still, this behaviour is unfortunate. Did any earlier kernel version handle the lid switch correctly? Can you test the package of Linux 2.6.35 in experimental? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Processed: tagging 594149
Processing commands for cont...@bugs.debian.org: tags 594149 + moreinfo Bug #594149 [linux-2.6] linux-image-2.6.32-5-amd64: Lid switch correct every other time; suspend every other lid close; Samsung N150-11 netbook Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 594149: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594149 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.128271230614383.transcr...@bugs.debian.org
Processed: tagging 588782
Processing commands for cont...@bugs.debian.org: tags 588782 + moreinfo Bug #588782 [linux-2.6] openvz: openvz and ext4 core dump on quota check Bug #586369 [linux-2.6] linux-image-2.6.32-5-openvz-686: Kernel oops, with openvz kernel and ext4 Added tag(s) moreinfo. Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 588782: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588782 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.128271232314476.transcr...@bugs.debian.org
