[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Cannot boot from root lvm volume: lvm2 broken?



On Wed, Mar 26, 2008 at 08:32:50PM +0100, Benjamin Kircher wrote:
> Hi there,
> 
> 
> need some advice over here. Installed Etch from netinstall iso and upgraded
> to sid, which works flawlessly. All partitions except /boot are in a LVM
> group (even my root fs is a LVM volume). Then I removed (more precise:
> purged) 2.6.18-5-486 kernel in favor of 2.6.24-1-686. After running a
> "update-initramfs -u" and a "shutdown -r now" my box fails to boot up. It
> complains:
> 
> (nah nah nah, a lot of this not and a lot of that not, neh neh ney)
> ...
> /scripts/local-top/lvm2: line 68 tr not found
> /scripts/local-top/lvm2: line 68 sed not found
> (I guess, this part of the script tries to activate my volume group)
> ...
> /proc/mounts: fopen %s failed: No such file or directory
> Failed to create lvm type filter
> Waiting for root file system ...
> 
> ... which my box never gets. Hereafter it throws me to a very limited shell.
> Indeed, /proc and /dev are empty ;(

Hey wow! I'm seeing this too (though i can boot). I thought it was
from moving to an amd64 kernel on i386 userland. But apparently
not. It seems that the initrd environment is broken at the moment. I'm
not sure, maybe it's ash (I think that's the initrd shell) that's
broken. 

You'll notice that this limited shell (busybox) doesn't function
properly -- ls doesn't exist for example. But you can fake it with
`busybox <cmd>` to get it to execute. So, for example, to get an ls of
the current directory, use `busybox ls` and there it will be.

So to boot this thing, you need to duplicate the processes that happen
in the initrd phase. This means you need to activate your lvm and
possible any encrypted stuff (if you have encryption as well, let me
know and we'll work through that). 

to activate lvm, do this from the busybox shell:

vgchange -ay <name-of-volume-group> 

-ay for "activate yes" essentially.

this will create your volume group in /dev/mapper. Check it with 

busybox ls /dev/mapper

if that's working, then you should be able to just 

exit

the busybox shell and your boot should continue. 


Essentially, certain necessary functions are missing from the initrd
causing these scripts to fail. It should be fairly simple for you to
get booted, and once that's done just stay up until a fix comes
through, or keep track of what you did to successfully boot so you can
reproduce it.

And this warrants a bug report, if one doesn't exist
already. hmmm... a little quick searching doesn't reveal anything
specific. I would file it with initramfs-tools as they know who get's
included in the initrd and can forward it on if required.

A

Attachment: signature.asc
Description: Digital signature


Reply to: