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

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

On Sat, Mar 29, 2008 at 3:44 PM, Benjamin Kircher <benjamin.kircher@gmail.com> wrote:

On Thu, Mar 27, 2008 at 5:00 PM, Andrew Sackville-West <andrew@farwestbilliards.com> wrote:
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

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


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.


Version: GnuPG v1.4.6 (GNU/Linux)


Hi Andrew,

I'm not able to activate lvm from within busybox, a "vgchange -ay group0" gives me:

/proc/mounts: fopen %s failed: No such file or directory
/proc/devices: fopen failed: No such file or directory

Failed to create lvm type filter

/proc and /dev (except /dev/console) are empty like the ocean.

I think you're right: My initrd is really f'd up. The first lines I noticed during boot up:
/init: line 11: mount: not found
cat: can't open '/proc/cmdline': No such file or directory
/scripts/init-top/framebuffer: line 100: mknod: not found
/init: line 157: printf: not found

I took a look at the initramfs-tools bug page and couldn't find any similar reports. I'll do some further investigations (need to know how initramfs works in detail).


Okay, I got it.

My bad. I purged the running kernel while installing the new one, which leaves my initrd image broken and the system unbootable. Well, I did this every time without problems... until Wednesday.

So the correct procedure is to install the new kernel first, then reboot with the new one and finally purge the old one.

Next time I do such a stunt, I'll examine the contents of the initrd first. Cheers anyway!


Reply to: