All of lore.kernel.org
 help / color / mirror / Atom feed
From: tytso@mit.edu <tytso@mit.edu>
To: lvm-devel@redhat.com
Subject: [2.6.33 REGRESSION BUG] Can't boot lvm on root (Ubuntu 9.10 userspace) with 2.6.33
Date: Thu, 4 Mar 2010 23:43:05 -0500	[thread overview]
Message-ID: <20100305044305.GC5747@thunk.org> (raw)
In-Reply-To: <E1Nmppq-0000sA-E1@closure.thunk.org>

On Wed, Mar 03, 2010 at 09:46:02AM -0500, Theodore Ts'o wrote:
> 
> The last kernel I could boot was 2.6.33-rc4, so this might be a
> regression.   As near as I can tell, this udev rule isn't firing:
> 
> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", \
> 	RUN+="watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'"
> 
> So nothing is showing up in /dev/mapper, and so the root can't be
> mounted.  After 45 seconds, it drops me into the initramfs shell, and if
> I manually run "lvm vgscan" and "lvm vgscange -ay", everything is back,
> but then I can't figure out how to restart the boot process from inside
> a failed initramfs.   And of course, the initramfs environment is so
> crappy that there are no debugging aids --- not even a working pager.
> 
> Did I mention how much I hate the whole initramfs with dynamic udev
> rules as a design?

So the workaround I've found for this is to use the magic boot command
line option: 

     break=premount

And then at the initramfs prompt, enter the command "lvm2 vgchange
-ay", followed by control-D.  

Then you'll run into the hal/X11 regression, where I've documented the
workaround I had to use for that.

So I can at least test during the merge window, but it would be nice
if these regressions could get fixed in a real way.

   	 	      	    	      	   - Ted



WARNING: multiple messages have this Message-ID (diff)
From: tytso@mit.edu
To: linux-kernel@vger.kernel.org, lvm-devel@redhat.com
Subject: Re: [2.6.33 REGRESSION BUG] Can't boot lvm on root (Ubuntu 9.10 userspace) with 2.6.33
Date: Thu, 4 Mar 2010 23:43:05 -0500	[thread overview]
Message-ID: <20100305044305.GC5747@thunk.org> (raw)
In-Reply-To: <E1Nmppq-0000sA-E1@closure.thunk.org>

On Wed, Mar 03, 2010 at 09:46:02AM -0500, Theodore Ts'o wrote:
> 
> The last kernel I could boot was 2.6.33-rc4, so this might be a
> regression.   As near as I can tell, this udev rule isn't firing:
> 
> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="lvm*|LVM*", \
> 	RUN+="watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'"
> 
> So nothing is showing up in /dev/mapper, and so the root can't be
> mounted.  After 45 seconds, it drops me into the initramfs shell, and if
> I manually run "lvm vgscan" and "lvm vgscange -ay", everything is back,
> but then I can't figure out how to restart the boot process from inside
> a failed initramfs.   And of course, the initramfs environment is so
> crappy that there are no debugging aids --- not even a working pager.
> 
> Did I mention how much I hate the whole initramfs with dynamic udev
> rules as a design?

So the workaround I've found for this is to use the magic boot command
line option: 

     break=premount

And then at the initramfs prompt, enter the command "lvm2 vgchange
-ay", followed by control-D.  

Then you'll run into the hal/X11 regression, where I've documented the
workaround I had to use for that.

So I can at least test during the merge window, but it would be nice
if these regressions could get fixed in a real way.

   	 	      	    	      	   - Ted

  parent reply	other threads:[~2010-03-05  4:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-03 14:46 [REGRESSION] Can't boot lvm on root (Ubuntu 9.10 userspace) with 2.6.33 Theodore Ts'o
2010-03-03 14:46 ` Theodore Ts'o
2010-03-04 13:54 ` Thorsten Glaser
2010-03-05  4:43 ` tytso [this message]
2010-03-05  4:43   ` [2.6.33 REGRESSION BUG] " tytso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100305044305.GC5747@thunk.org \
    --to=tytso@mit.edu \
    --cc=lvm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.