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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20100305044305.GC5747@thunk.org>
Date:	Thu, 4 Mar 2010 23:43:05 -0500
From:	tytso@....edu
To:	linux-kernel@...r.kernel.org, lvm-devel@...hat.com
Subject: Re: [2.6.33 REGRESSION BUG] Can't boot lvm on root (Ubuntu 9.10
 userspace) with 2.6.33

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/