[REGRESSION] Can't boot lvm on root (Ubuntu 9.10 userspace) with 2.6.33

[REGRESSION] Can't boot lvm on root (Ubuntu 9.10 userspace) with 2.6.33

[Theodore Ts'o]

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?

I'll probably kludge some kind of "sleep 10; lvm vgscan ; lvm vgchange
-ay" into some local initramfs script, but it would be nice to know what
happened and what the real right fix should be.  Did anything change
recently that might have caused this to fail?

						- Ted

[REGRESSION] Can't boot lvm on root (Ubuntu 9.10 userspace) with 2.6.33

[Theodore Ts'o]

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?

I'll probably kludge some kind of "sleep 10; lvm vgscan ; lvm vgchange
-ay" into some local initramfs script, but it would be nice to know what
happened and what the real right fix should be.  Did anything change
recently that might have caused this to fail?

						- Ted

Re: [REGRESSION] Can't boot lvm on root (Ubuntu 9.10 userspace) with 2.6.33

[Thorsten Glaser]

Theodore Ts'o <tytso <at> mit.edu> writes:

> a failed initramfs.   And of course, the initramfs environment is so
> crappy that there are no debugging aids --- not even a working pager.

While not a pager (could probably easily be added), I’ve got patches
for klibc that let an almost full-featured mksh build against it… and
it’s not much bigger (40K or so) than ash.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”	(#nosec)    ‣‣‣ Please let MySQL and MariaDB finally die!

Re: [2.6.33 REGRESSION BUG] Can't boot lvm on root (Ubuntu 9.10 userspace) with 2.6.33

[tytso]

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

[2.6.33 REGRESSION BUG] Can't boot lvm on root (Ubuntu 9.10 userspace) with 2.6.33

[tytso]

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