Bug#409243: fails to boot.
Il giorno ven, 09/02/2007 alle 01.55 +0100, maximilian attems ha scritto: On Thu, 01 Feb 2007, Mauro Sanna wrote: Then I upgrade to etch. I install the new kernel 2.6.18 and initramfs-tools. I create the new initrd then, at the end of upgrade, reboot the system. It hangs saying that cannot find my volume group and is waiting for root filesystem... In my preceding upgrades, months ago, I didn't had this problem. I have this problem with newer upgrades to etch. how did you create the initrd? please send output of the installed linux-image dpkg -l linux-image* un linux-imagenon definita (descrizione non disponibile) un linux-image-2. non definita (descrizione non disponibile) ii linux-image-2. 2.6.18+5 Linux kernel 2.6 image on PPro/Celeron/PII/P pn linux-image-2. non definita (descrizione non disponibile) pn linux-image-2. non definita (descrizione non disponibile) ii linux-image-2. 2.6.18-8~bpo.1 Linux 2.6.18 image on PPro/Celeron/PII/PIII/ dpkg -l kernel-image* ii kernel-image-2 2.6.8-16sarge6 Linux kernel image for version 2.6.8 on 386. I am using sarge and I have installded backport of linux image 2.6.18. When I boot with kernel 2.6.8 it's all ok. When I boot with kernel 2.6.18 it says that it can't find volume group vg00 and waiting for root filesystem. The creation of initrd with kernel 2.6.18 is automatic, I'have tried also update-initarmfs, reboot but the system hangs with the above messages. If you try to install etch using one boot partition and lvm for the remaining disk space you'll see that it don't boot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409243: fails to boot.
reassign 409243 lvm2 stop On Fri, 09 Feb 2007, Mauro Sanna wrote: ii linux-image-2. 2.6.18+5 Linux kernel 2.6 image on PPro/Celeron/PII/P I am using sarge and I have installded backport of linux image 2.6.18. When I boot with kernel 2.6.8 it's all ok. When I boot with kernel 2.6.18 it says that it can't find volume group vg00 and waiting for root filesystem. The creation of initrd with kernel 2.6.18 is automatic, I'have tried also update-initarmfs, reboot but the system hangs with the above messages. If you try to install etch using one boot partition and lvm for the remaining disk space you'll see that it don't boot. no it does not it's because your lvm2 is still from sarge and it be interesting to track the failure down, currently i have no other info beside the failure. could you add vgscan to your initramfs and check what it is saying inside of the rescue shell. you'd have to add a following line to the bottom of one hook in /usr/share/initramfs-tools/hooks/ : copy_exec /lib/lvm-200/vgchange /sbin -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#409243: fails to boot.
Processing commands for [EMAIL PROTECTED]: reassign 409243 lvm2 Bug#409243: fails to boot. Bug#409171: problems with initramfs-tools. Bug reassigned from package `initramfs-tools' to `lvm2'. stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Kernel frozen
Hi folks Noone wants to say it, so I do: The kernel for etch is frozen. No updates shall be done except for security problems affecting the installer. Bastian -- Without freedom of choice there is no creativity. -- Kirk, The return of the Archons, stardate 3157.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel frozen
On Fri, Feb 09, 2007 at 05:00:07PM +0100, Bastian Blank wrote: Hi folks Noone wants to say it, so I do: The kernel for etch is frozen. No updates shall be done except for security problems affecting the installer. [Shouldn't this be on debian-kernel-maint?] Thanks Bastian. Now, I'd like to create a process for tracking non-security changes for incorporation in etch point releases. My personal preference is to use usertags: bts user debian-kernel@lists.debian.org , usertag NN dkt-pending-etch-update Any bug that is of severity important or higher is a candidate for a stable update. Of course, the stable release team needs to approve each one. I would suggest that we track each issue via a bug report and only add a fix to svn once the bug report has been approved by the SRM team. As for svn, how about we move sid/linux-2.6 to etch/linux-2.6 now, and start a etch-security branch? Or is the convention that we should leave it under sid/ until it has been superseded in sid? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian-kernel-maint
We've had debian-kernel-maint for a while now, but its never really been used. Should we keep it around? From what I understand, the reason for this list was to separate kernel discussions from the bug noise. Since debian-kernel is still listed as the maintainer, it seems to me that it makes more sense to move debbugs stuff away debian-kernel rather than move discussions to a new list (since many of them will begin w/ a message to the maintainer address). How about we ask the bugs.debian.org folks to redirect bug mail to debian-kernel-maint, and continue to use debian-kernel for discussions? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398470: fix for oops caused by key serial collisions
The oops is being caused by collisions in the key serial allocation code
and subsequent corruption being introduced into the key serial rbtree.
The following patch against 2.6.18 will fix it. Bug also exists in
2.6.19 and 2.6.20; it is patched in 2.6.21 going forward.
---
Fix rbtree corruption causing oops in key serial allocation.
Premature optimization in key_alloc_serial contained bugs which were
exposed by the change to random serial selection in 2.6.18. This patch
fixes that by properly traversing the rbtree when dealing with collisions.
It also returns -ENOMEM when there are no more serials left to allocate
(which would be hard to do, but still).
---
commit 74dde47f248cceb6f7964543a84d5d48cbd0118f
tree 49a18110c7b1c24f8b9ce0353a6bfd026e535cf5
parent e478bec0ba0a83a48a0f6982934b6de079e7e6b3
author Matt Mitchell [EMAIL PROTECTED] Fri, 09 Feb 2007
12:37:02 -0600
committer Matt Mitchell [EMAIL PROTECTED] Fri, 09 Feb 2007
12:37:02 -0600
security/keys/key.c | 58
++-
1 files changed, 30 insertions(+), 28 deletions(-)
diff --git a/security/keys/key.c b/security/keys/key.c
index 80de8c3..d8f5cc2 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -178,12 +178,17 @@ static inline void key_alloc_serial(struct key *key)
struct rb_node *parent, **p;
struct key *xkey;
+ key_serial_t orig;
+ int keyspace_loop;
+
/* propose a random serial number and look for a hole for it in the
* serial number tree */
do {
get_random_bytes(key-serial, sizeof(key-serial));
key-serial = 1; /* negative numbers are not permitted */
+ orig = key-serial;
+ keyspace_loop = 0;
} while (key-serial 3);
spin_lock(key_serial_lock);
@@ -199,37 +204,29 @@ static inline void key_alloc_serial(struct key *key)
p = (*p)-rb_left;
else if (key-serial xkey-serial)
p = (*p)-rb_right;
- else
- goto serial_exists;
- }
- goto insert_here;
-
- /* we found a key with the proposed serial number - walk the tree from
-* that point looking for the next unused serial number */
-serial_exists:
- for (;;) {
- key-serial++;
- if (key-serial 2)
- key-serial = 2;
-
- if (!rb_parent(parent))
+ else {
+ /* if we have already looped, check for exhausted
+* keyspace */
+ if ((keyspace_loop == 1) (key-serial = orig)) {
+ /* this is just a dummy */
+ key-serial = -1;
+ spin_unlock(key_serial_lock);
+ printk(KERN_WARNING key_alloc_serial:
+ keyspace exhausted\n);
+ return;
+ }
+
+ key-serial++;
+ if (key-serial 2) {
+ keyspace_loop = 1;
+ key-serial = 2;
+ }
+ parent = NULL;
p = key_serial_tree.rb_node;
- else if (rb_parent(parent)-rb_left == parent)
- p = (rb_parent(parent)-rb_left);
- else
- p = (rb_parent(parent)-rb_right);
-
- parent = rb_next(parent);
- if (!parent)
- break;
-
- xkey = rb_entry(parent, struct key, serial_node);
- if (key-serial xkey-serial)
- goto insert_here;
+ }
}
/* we've found a suitable hole - arrange for this key to occupy it */
-insert_here:
rb_link_node(key-serial_node, parent, p);
rb_insert_color(key-serial_node, key_serial_tree);
@@ -326,9 +323,14 @@ struct key *key_alloc(struct key_type *type, const
char *desc,
goto security_error;
/* publish the key by giving it a serial number */
- atomic_inc(user-nkeys);
key_alloc_serial(key);
+ /* check for success */
+ if (key-serial == -1)
+ goto no_memory_3;
+ else
+ atomic_inc(user-nkeys);
+
error:
return key;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
A suggested patch for update-initramfs: rm update-initramfs
Unpacking linux-image-2.6.18-4-xen-686 (from
.../linux-image-2.6.18-4-xen-686_2.6.18.dfsg.1-10_i386.deb) ...
Setting up linux-image-2.6.18-4-xen-686 (2.6.18.dfsg.1-10) ...
/boot/initrd.img-2.6.18-4-xen-686 does not exist. Cannot update.
That it's even possible for this script to exit like this is a bug.
Looking at update-initramfs, I think it's a flawed concept. Why would
anyone ever update an initramfs? You should generate one each time --
not extract the cpio file, muddle around it it and then ball it back
up again. Just my 2 cents. Not that update-initramfs really does that
AFAICT it just runs mkinitramfs anyway.
I could send a patch, but seriously this script is designed to fail at
ever turn instead of just work. It's got panic() and mild_panic() all
over the place. delete()? How about rm -f file. Don't check, don't
panic if it fails. Just run it!
I'm not sure why this script exists at all, but it seems like it
should be replaced with one line:
mkinitramfs -o /boot/initrd.img-${KVER} ${KVER}
/endrant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Generic IDE support in Debian kernel-image packages
Hello, I would like to know what it would take to enable generic ide support as a fallback option using a stock Debian kernel-image. I think that having the option available without recompiling a custom kernel would be a great boon to all Debian users who are trying to use Debian with a Linux kernel on new or marginally supported ide hardware. Thank you for your time and thoughts, -- Jacob Please CC me, I am not on this list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel frozen
On Fri, Feb 09, 2007 at 11:51:29AM -0700, dann frazier wrote: On Fri, Feb 09, 2007 at 05:00:07PM +0100, Bastian Blank wrote: Hi folks Noone wants to say it, so I do: The kernel for etch is frozen. No updates shall be done except for security problems affecting the installer. [Shouldn't this be on debian-kernel-maint?] Thanks Bastian. Now, I'd like to create a process for tracking non-security changes for incorporation in etch point releases. My personal preference is to use usertags: bts user debian-kernel@lists.debian.org , usertag NN dkt-pending-etch-update Any bug that is of severity important or higher is a candidate for a stable update. Of course, the stable release team needs to approve each one. I would suggest that we track each issue via a bug report and only add a fix to svn once the bug report has been approved by the SRM team. i'd like to continue to push the stable 2.6.16 serie patches, for the stable branch. As for svn, how about we move sid/linux-2.6 to etch/linux-2.6 now, and start a etch-security branch? Or is the convention that we should leave it under sid/ until it has been superseded in sid? -- dann frazier -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409435: linux-image-2.6.18-4-amd64: old version of libdevmapper1.02 installed == eat filesystem on pvmove
On Wed, Feb 07, 2007 at 12:35:32AM +0100, Marc Lehmann wrote: it's just not release-critical, as you suggested in your bug severity. I never suggested it was release-critical. reportbug suggested to use critical because: 1 critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. which is certainly true. if reportbug is mistaken, do you know a better wording and do you think I should report this agains reportbug so it can be fixed, if critical, in fact, means something else. I don't disagree with the definition reportbug uses for critical, there are just some nuances that aren't easy to express in a short description like that. Like, for instance, the fact that it's not a kernel bug alone which causes dataloss, but a combination of a kernel bug together with a broken, unsupported version of devmapper. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 410010 is important
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.27 # Frederik's message missed control@ severity 410010 important Bug#410010: linux-image-2.6.18-3-amd64: Panic When BNX2 Ring Buffer Fills Severity set to `important' from `critical' End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel frozen
[Bcc'ing debian-kernel, moving to debian-kernel-maint] On Sat, Feb 10, 2007 at 01:04:52AM +0100, maximilian attems wrote: i'd like to continue to push the stable 2.6.16 serie patches, for the stable branch. It'd be great if you could keep monitoring 2.6.16.y changes. However, I think we need to be more picky about what we consider. The SRMs have said that important and greater bugs can get fixed in a stable release. Looking at the changesets that have gone into 2.6.16.y, I don't think many qualify. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-kernel-maint
On Fri, Feb 09, 2007 at 11:56:17AM -0700, dann frazier wrote: We've had debian-kernel-maint for a while now, but its never really been used. Should we keep it around? From what I understand, the reason for this list was to separate kernel discussions from the bug noise. Since debian-kernel is still listed as the maintainer, it seems to me that it makes more sense to move debbugs stuff away debian-kernel rather than move discussions to a new list (since many of them will begin w/ a message to the maintainer address). How about we ask the bugs.debian.org folks to redirect bug mail to debian-kernel-maint, and continue to use debian-kernel for discussions? I believe the original idea was to create d-k-m for discussions and keep d-k as the address in maintainer field (and the primary contact address for the user requests). This appears to be the most straightforward way, as it requires no changes. -- Jurij Smakov [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
