Processed: tagging 652525

2011-12-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org: > tags 652525 + patch Bug #652525 [initramfs-tools] Takes excessively long time to generate initramfs Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 652525: http://bugs.debian.org/cgi-bin/bugrep

Bug#652525: Takes excessively long time to generate initramfs

2011-12-17 Thread Josh Triplett
Package: initramfs-tools Version: 0.99 Severity: normal File: /usr/sbin/update-initramfs In the last few versions of initramfs-tools, update-initramfs started taking an excessively long time to generate the initramfs: ~$ time sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-

Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs

2011-12-17 Thread Marco d'Itri
On Dec 17, Roger Leigh wrote: > 1) Generation of /etc/fstab in the initramfs, including the rootfs >and all the filesystems desired to be mounted This is highly suboptimal, because it suddenly makes the initramfs not generic anymore. The initramfs should: - mount / as usual - look at the root

Bug#652505: 2.6.32-5-powerpc: Kernel error sometimes on connecting to Wifi

2011-12-17 Thread Benjamin Mach
Package: linux-2.6 Version: 2.6.32-38 Severity: important File: 2.6.32-5-powerpc -- Package-specific info: ** Version: Linux version 2.6.32-5-powerpc (Debian 2.6.32-38) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Mon Oct 3 04:26:33 UTC 2011 ** Command line: root=UUID=80d676

Re: [PATCH] m68k/irq: don't use pr_crit in an header

2011-12-17 Thread Thorsten Glaser
Uwe Kleine-König dixit: >so better use plain printk with KERN_CRIT directly. Wasn’t it considered good style to switch f̲r̲o̲m̲ that t̲o̲ pr_crit? In that case, my other patch from Message-ID can still be used. Feel free to assume a Signed-off on that by me, if this is the desired direction of

Bug#652503: [Possible SPAM]-linux-image-2.6.32-5-kirkwood: L2TP tunnel fails when IPSEC SA rekeys (while using the pppol2tp kernel driver)

2011-12-17 Thread Frank L
Package: linux-2.6 Version: 2.6.32-38 Severity: important Tags: patch When using a L2TP/IPSEC VPN, taking advantage of the pppol2tp kernel driver (e.g. using openl2tp), the l2tp tunnel fails when the IPSEC SA is rekeyed. This is fixed by a commit to kernel 3.2-rc5 (see https://github.com/torvald

[PATCH] m68k/irq: don't use pr_crit in an header

2011-12-17 Thread Uwe Kleine-König
Using pr_crit in an header results in funny messages. Consider #define pr_fmt(fmt) "mydriver: " fmt #include which makes the message from ack_bad_irq mydriver: unexpected IRQ trap... so better use plain printk with KERN_CRIT directly. This fixes a build problem on m68k

Re: aufs vs. m68k conflict, please advice

2011-12-17 Thread Uwe Kleine-König
On Sat, Dec 17, 2011 at 07:00:00PM +, Thorsten Glaser wrote: > Uwe Kleine-K�nig dixit: Your mailer is broken. And it added: X-Message-Flag: Your mailer is broken. Get an update at http://www.washington.edu/pine/getpine/pcpine.html for free. to your mail :-) I guess it means you not m

Re: aufs vs. m68k conflict, please advice

2011-12-17 Thread Thorsten Glaser
Uwe Kleine-K�nig dixit: >On Sat, Dec 17, 2011 at 02:28:35PM +, Thorsten Glaser wrote: >> Maybe something like this? […] >> Just an idea of the moment, Well, it does make the thing compile with minimal effort. >IMHO the problem is that aufs provides an incomplete definition of >pr_fmt. Eithe

Re: aufs vs. m68k conflict, please advice

2011-12-17 Thread Uwe Kleine-König
On Sat, Dec 17, 2011 at 02:28:35PM +, Thorsten Glaser wrote: > Ben Hutchings dixit: > > >why other architectures get away with it. Maybe they just don't use > >pr_*() in headers. > > Maybe something like this? > > #define ack_bad_irq(irq) do { \ > pr_cr

Bug#652484: linux-image-3.1.0-1-amd64: kernel oops when USB drive hot unplugged

2011-12-17 Thread Andrew Varner
Package: linux-2.6 Version: 3.1.1-1 Severity: normal I used dd to write an entire 4GB USB flash drive. It was only going at 2MB/s, so I ran it overnight. In the morning, it was done, so I unplugged the USB drive. Immediately there was a kernel oops. The flash drive was plugged into a 7 port USB

Re: aufs vs. m68k conflict, please advice

2011-12-17 Thread Thorsten Glaser
Dixi quod… >Maybe something like this? With that, aufs indeed compiles and module-links. bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr -- To UNSUBSCR

Re: Bug#652015: pu: package iotop/0.4-2

2011-12-17 Thread Adam D. Barratt
On Thu, 2011-12-15 at 09:56 +0800, Paul Wise wrote: > On Wed, 2011-12-14 at 19:25 +, Adam D. Barratt wrote: > > > Please go ahead; thanks. > > Uploaded. For the record, this was accepted earlier today. Regards, Adam -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with

Re: aufs vs. m68k conflict, please advice

2011-12-17 Thread Ben Hutchings
On Sat, 2011-12-17 at 14:28 +, Thorsten Glaser wrote: > Ben Hutchings dixit: > > >why other architectures get away with it. Maybe they just don't use > >pr_*() in headers. > > Maybe something like this? > > #define ack_bad_irq(irq) do { \ > pr_crit("une

Bug#652475: linux-image-3.1.0-1-amd64: USB autosuspend goes crazy filling the log files

2011-12-17 Thread Luca Capello
Package: linux-2.6 Version: 3.1.1-1 Severity: normal Hi there! There is a problem somewhere with USB autosuspending on my ThinkPad X60. When enabled through powertop, the kernel splits out messages different times every seconds, thus filling the log files: = $ ls -lh /var/log/debug* /var/log/

Re: aufs vs. m68k conflict, please advice

2011-12-17 Thread Thorsten Glaser
Ben Hutchings dixit: >why other architectures get away with it. Maybe they just don't use >pr_*() in headers. Maybe something like this? #define ack_bad_irq(irq) do { \ pr_crit("unexpected IRQ trap at vector %02x\n", \ (unsigned int)

AW: Re: Bug#652026: amavisd-new: Init-script not working (stop/restart)

2011-12-17 Thread michael.reincke
Hi, I think the problem is not the kernel nor amvisd-new. The could be perl. I remember that I have to change definitions for nagios done via nrpe. Some check_procs commands couldn't find no longer the they have to look for. I will check on monday that only perl processes are hit by this bug. R

Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs

2011-12-17 Thread Roger Leigh
Package: initramfs-tools Version: 0.99 Severity: normal Tags: patch Hi, In order to make the libraries and binaries in /usr available during early boot, it would be desirable to be able to mount /usr in addition to the rootfs inside the initramfs. This patch implements a generic solution into tw