Package: initramfs-tools
Version: 0.116
Severity: minor
File: /usr/sbin/update-initramfs
Both the update-initramfs(8) manpage and update-initramfs --help show
the -b option without any argument, while it does require one.
(On a similar note, --help seems to imply that for the -k option, the
usertags 464501 - orphaned
submitter 464501 Frédéric Brière orphaned-...@fbriere.net
thanks
On Thu, Dec 18, 2008 at 05:20:55PM -0500, Frédéric Brière wrote:
Its current purpose is to track a specific regression, introduced with
eSCO support in b6a0dc82. Namely, the kernel will always attempt
Package: initramfs-tools
Version: 0.102
Severity: normal
panic() [and thus maybe_break()] attempts to load modules which may not
be present in the initramfs (such as i8042, which is compiled built-in).
This causes any script with set -e to abort.
For example, booting with break=pre-mdadm will
retitle 653440 Kernel freezes when assembling RAID1 array with components all
write-mostly
found 653440
found 653440 3.1.1-1
tags 653440 fixed-upstream
thanks
[ Note to kernel team: any chance 307729c could make it into 3.2.1-1? ]
On Mon, Jan 16, 2012 at 09:42:53AM +0100, Roland Mas wrote:
I
On Wed, Dec 28, 2011 at 11:33:03AM +0100, Roland Mas wrote:
called triple-patte. The rest of the hard disks is used by a third
partition, and /dev/sd[ab]3 make up a two-device RAID1 array called
obelix.
Are both members of this array marked as writemostly, by any chance?
(You can check with
Source: linux-2.6
Severity: wishlist
While CONFIG_SND_PCM_XRUN_DEBUG is mostly used for debugging purposes,
it can also affect the behavior of snd_pcm_update_hw_ptr0() since commit
c87d973. (See XRUN_DEBUG_JIFFIESCHECK in sound/core/pcm_lib.c.)
This has been used before to work around bugs in
On Sat, Feb 14, 2009 at 01:14:10PM -0500, Frédéric Brière wrote:
The bad news is that I can't give 2.6.27+ a try, since 769be97 breaks
things even further; any connection attempt just hangs there, with
Turns out the problematic part of 769be974 is the last patch in
hci_conn_complete_evt
On Sat, Dec 20, 2008 at 10:34:01PM +0100, Moritz Muehlenhoff wrote:
If you find the time plesae check, whether this behaviour persists with
2.6.28
Yes and no.
The good news is that Marcel Holtmann added a disable_esco parameter for
people like me, so we'd no longer have to patch our kernel
On Sun, Jan 04, 2009 at 06:17:33PM +0100, Moritz Muehlenhoff wrote:
Does this error still occur with the Lenny kernel?
I don't know about lenny specifically, but this behavior is still
present in vanilla 2.6.26.
I don't know if this is a problem any longer, though. I opened this bug
back when
Package: linux-2.6
Version: 2.6.21-6
Severity: normal
I recently tried and failed to pair with a bluetooth headset that used
to work some time ago. Specifically, any attempt to establish a
connection to the device (with hcitool cc) would appear to be
successful, with hci_create_connection()
Package: linux-2.6
Version: 2.6.18.dfsg.1-17
Severity: important
[Full disclosure: I've applied the sco-flowcontrol patch as distributed
in bluetooth-alsa, as I can't use my bluetooth headset otherwise.]
I'm getting a full kernel freeze with the following sequence:
- USB bluetooth adapter is
Package: linux-image-2.6.20-1-k7
Version: 2.6.20-3
Severity: important
The 2.6.20-1 package appears to behave as though image_in_boot was set:
[fbriere] toroia:~ $ ls -l /vmlinuz /initrd.img /boot/vmlinuz /boot/initrd.img
lrwxrwxrwx 1 root root 22 2007-05-18 14:57 /boot/initrd.img -
12 matches
Mail list logo
