Package: initramfs-tools,kernel,udev
Currently:
- recent linux-image packages depend on 'initramfs-tools | yaird |
linux-initramfs-tool', so initramfs-tools is the 'default' alternative
- initramfs-tools depends on recent udev
- recent udev refuses to install unless recent kernel is
Package: initramfs-tools
Version: 0.85b
Severity: normal
Looks line postinst script of initramfs-tools package just runs
'update-initramfs -u'
This looks to update initramfs image for one of installed linux-image
packages, while keeping it as-is for all other packages. This could lead
to
severity 390862 important
thanks
Hello.
Currently, debian does not provide any xen kernel with pae enabled.
This forces to use xen hypervisor without pae support, which in turn makes
it impossible to use more than 3.5G of system RAM.
But the very idea of virtualization is to provide better
severity 390862 wishlist
thanks
On Thu, Nov 30, 2006 at 03:08:15PM +0300, Nikita V. Youshchenko wrote:
Currently, debian does not provide any xen kernel with pae enabled.
And?
I've written why it's bad. By this decision, you are breaking important
usage scenario, effectively making
for futher discussion.
On Sun, 26 Nov 2006, Nikita V. Youshchenko wrote:
Looks line postinst script of initramfs-tools package just runs
'update-initramfs -u'
yes and it will stay like this.
This looks to update initramfs image for one of installed linux-image
packages, while keeping
What about idea not to *add* pae versions of xen kernels, but to *replace*
non-pae versions with pae versions?
Rationale:
- not increase in archive size or linux-2.6 package build time,
- this will improve compatimility with other distros (consider scenario
when running FC or RHEL in domU;
Package: initramfs-tools
Version: 0.85c
Severity: minor
While browsing /usr/sbin/update-initramfs script, I've found that it
does not clear 'mode' environment variable that could come from
environment.
Although nothing serious, better to fix it by adding something like
'unset mode' or 'mode='
While browsing /usr/sbin/update-initramfs script, I've found that it
does not clear 'mode' environment variable that could come from
environment.
Although nothing serious, better to fix it by adding something like
'unset mode' or 'mode=' before command-line parsing.
And same with 'version'
but seems to be another solution which apparently compiles to a kernel
module which will catch and report attempts to (ab)use vmsplice at
http://home.powertech.no/oystein/ptpatch2008/ptpatch2008.c
I've just tried to compile this module.
It successfully insmod'ed:
Feb 11 12:54:29 zigzag
Hello.
After upgrading kernel from 2.4 to debian 2.6.6-1-686 package, I suffered
100% reproducable kernel oops whn I unplugged my usb bluetooth dongle.
After some search, I found that the problem is known, and may be fixed by
applying patch-2.6.6-mh2 from http://www.bluez.org/patches.html. I
On Wed, May 26, 2004 at 01:12:03AM +0400, Nikita V. Youshchenko wrote:
Hello.
Hello Nikita,
After upgrading kernel from 2.4 to debian 2.6.6-1-686 package, I
suffered 100% reproducable kernel oops whn I unplugged my usb
bluetooth dongle.
This kind of stuff belongs not to this list
On Wed, May 26, 2004 at 01:12:03AM +0400, Nikita V. Youshchenko wrote:
Hello.
After upgrading kernel from 2.4 to debian 2.6.6-1-686 package, I
suffered 100% reproducable kernel oops whn I unplugged my usb
bluetooth dongle.
After some search, I found that the problem is known
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I've upgraded to debian 2.6.7 kernel; it seems not to have this bug.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA78q6sTbPknTfAB4RAqk6AJ9EFOxEzy9cwsoS6SLRUUqPf7cWkACcD7Vc
CU+24JJmyxsT3N8ySk+U6XU=
=2lg+
-END PGP
I've just found that debian/arch/i386/config.686 and
debian/arch/i386/config.k7 differ not only in cpu-related keys:
[EMAIL PROTECTED]:/ svn diff
svn://svn.debian.org/kernel/dists/trunk/linux-2.6/debian/arch/i386/config.
{686,k7}
...
@@ -41,6 +42,12 @@
# CONFIG_PCMCIA_XIRTULIP is not set
#
asm/system.h is not on the exported headers list. This means that it is
usually not save to use it from userspace. A quick check looks like this
is the case. Don't even think about using it.
Could you please explain what is 'exported headers list', who maintains it,
etc?
Also, what is
Package: linux-image-2.6.26-1-xen-686
Version: 2.6.26-5
Severity: normal
I've just tried to start kernel from linux-image-2.6.26-1-xen-686
instead of etch xen kernel in a domU.
Since that domU runs an application server with 50 KDE session
nortmally active, it required much RAM. Current setup is
Hypervisor version is 3.2.0-3~bpo4+2 (from backports.org).
xen-utils-3.2-1 in dom0 is 3.2.0-3~bpo4+2.
This version is not supported. At least upgrade the hypervisor to 3.2.1
from Lenny.
Thanks for your reply.
I can't upgrade now, since system in question is running several domUs that
are
Hello.
At last we upgraded hypervisor and dom0 of our servers to lenny/amd64.
Now our 32bit domUs correctly see more than 4G of memory. So this bug may
be closed.
signature.asc
Description: This is a digitally signed message part.
Package: linux-image-2.6.26-1-xen-686
Version: 2.6.26-12
Severity: normal
After upgrading a domU from etch to lenny kernel, I've faced a hard domU
lockup that very looks like
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1098
after severak hours f running.
I've applied the workaround
Package: initramfs-tools
Version: 0.92o
Severity: wishlist
There are different things that could be required to do after initramfs
image was created or updated, depending on system setup.
That may include copying initramfs to xen dom0 (or external bootserver),
updating non-standard bootloader
right those hooks should be set up by linux-2.6 not initramfs-tools.
kernel-package uses /etc/kernel and linux-2.6 should use that
structure too.
closing as this has no relation with initramfs-tools
Sorry, but what linux-2.6 has to do with initramfs update trigged by e.g.
mdadm (or random
Is there any chance to get this fix into lenny? AFAIU, this bug may
affect both i386 and amd64, both dom0 and domU [if domU is running
-xen flavour], almost on any hardware with 1 CPUs, and cause system
crash...
Yes, I have added it to the lenny branch.
Hi
I don't see any mention of
Package: linux-image-2.6.26-2-xen-amd64
Version: 2.6.26-17lenny2
Severity: normal
I'm running several servers (Dual Core AMD Opteron, 16G of ram) with
Xen.
Dom0 is debian lenny adm64.
Today I tried to run a large backup in dom0 - copy NFS-mounted partition
to a local volume group.
buki:~# cd
This looks like the same issue as reported in #516479 - although not sure.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Here is one more backtrace of the same crash.
[ 9199.462928] Call Trace:
[ 9199.462928] IRQ [80435886] ? _spin_lock+0x3a/0x42
[ 9199.462928] [a00964f4] ? :sata_sil:sil_interrupt+0x2b/0x275
[ 9199.462928] [8025f0e6] ? handle_IRQ_event+0x47/0x8e
[ 9199.462928]
This asserts that if we spin on a lock after interrupting another spin,
and interrupts are enabled, we must be in a softirq.
Looking at the bottom of the same file drivers/xen/core/spinlock.c:
void xen_spin_kick(raw_spinlock_t *lock, unsigned int token)
{
unsigned int cpu;
tags 542250 +patch
thanks
... I may guess that line 74 should check for in_interrupt() instead of
in_softirq().
I've tried that and it really fixed the problem. Server already runs the
same backup procedure for several hours. Previously it crashed within 15
minutes.
Here is the patch I've
On Wed, 2009-08-19 at 22:36 +0400, Nikita V. Youshchenko wrote:
tags 542250 +patch
thanks
... I may guess that line 74 should check for in_interrupt() instead
of in_softirq().
I've tried that and it really fixed the problem. Server already runs
the same backup procedure
The only featureset provided will be 'rt' (realtime), currently built
for amd64 only. If there is interest in realtime support for other
architectures, we may be able to add that.
We at MSU are definitly interested in -rt for 32-bit x86 (with pae).
Before now, we have been building packages
29 matches
Mail list logo
