[linux-lvm] Re: Fedora Core 3 system with lvm2 won't boot

Tue Dec 14 03:21:14 UTC 2004

On Mon, Dec 13, 2004 at 03:53:58PM -0800, Dan Stromberg wrote:
> 2) Anyone know how I can boot from a rescue CD, and get to a point where
> I can attempt to fsck the filesystem, or at least see where in bringing
> up LVM2 the system is getting confused?

I'm not an LVM2 expert, but I'll try and help.

> On Mon, 2004-12-13 at 11:44 -0800, Dan Stromberg wrote:
> > Anyway, now when it tries to boot, I see:
> > 
> > Red Hat nash version 4.1.18 starting
> >   Reading all physical volumes.  This may take a while...
> >   Found volume group "VolGroup00" using metadata type lvm2
> >   2 logical volume(s) in volume group "VolGroup00" now active
> > 
> > 
> > ...and that's it.  I've left it there for over and hour, and it never
> > gets past that.
> > 
> > I booted off of an FC3 rescue cd, and found that I could mount the /boot
> > partition, but I cannot mount the / partition.  I ran various lvm
> > commands that identified two lvm volumes on the system.
> > fsck'ing /dev/hda2 (which is /) is getting me no where though - it just
> > says "invalid argument".

Yes, it would do, it looks like /dev/hda2 holds a volume (sorry if my terminology
is incorrect, it's bloody confusing), but definitely not a filesystem directly.
So you don't want to fsck /dev/hda2!

> > I tried firing up device mapper and udev in order to get
> > a /dev/VolGroup00 directory, but it just wouldn't do it - at least, not
> > with the things I tried.  I could mkdir the directory, but then "lvm
> > vgmknodes" would remove it.

You don't actually have to use udev if you can't get it to work. udev is just
a userspace program which automates the grunt work of setting up a ramdisk-based
/dev filesystem.

All you really need to do to gain access to the root filesystem is:

1) Note down what the root= device is that appears on the kernel
command line (this can be found by going to boot from hard drive and then examining
the kernel command line in grub, or by looking in /boot/grub/grub.conf )

2) Be booted from rescue disk

3) Sanity check: ensure that the nodes /dev/hda, /dev/hda2 etc. exist

4) Start up LVM2 (assuming it is not already started by the rescue disk!) by
typing:

  lvm vgchange --ignorelockingfailure -P -a y

Looking at my initrd script, it doesn't seem necessary to run any other commands
to get LVM2 volumes activated - that's it.

5) Find out which major/minor number the root device is. This is the slightly tricky
bit. You may have to use trial-and-error. In my case, I guessed right first time:
(no comments about my odd hardware setup please ;)

[root at localhost t]# ls /sys/block
dm-0  dm-2  hdd    loop1  loop3  loop5  loop7  ram0  ram10  ram12  ram14  ram2  ram4  ram6  ram8
dm-1  hdc   loop0  loop2  loop4  loop6  md0    ram1  ram11  ram13  ram15  ram3  ram5  ram7  ram9
[root at localhost t]# cat /sys/block/dm-0/dev
253:0
[root at localhost t]# devmap_name 253 0
Volume01-LogVol02

In the first command, I listed the block devices known to the kernel. dm-* are the LVM
devices (on my 2.6.9 kernel, anyway). In the second command, I found out the major:minor
numbers of /dev/dm-0. In the third command, I used devmap_name to check that the device
mapper name of node with major 253 and minor 0, is the same as the name of the root device
from my kernel command line (cf. step 1). Apart from a slight punctuation difference,
it is the same, therefore I have found the root device.

I'm not sure if FC3 includes the devmap_name command. According to fr2.rpmfind.net, it doesn't.
But you don't really need it, you can just try all the LVM devices in turn until you find
your root device. Or, I can email you a statically-linked binary of it if you want.

6) Create the /dev node for the root filesystem if it doesn't already exist, e.g.:

  mknod /dev/dm-0 b 253 0

using the major-minor numbers found in step 5.

Please note that for the purpose of _rescue_, the node doesn't actually have to be under
/dev (so /dev doesn't have to be writeable) and its name does not matter. It just needs
to exist somewhere on a filesystem, and you have to refer to it in the next command.

7) Do what you want to the root filesystem, e.g.:

  fsck /dev/dm-0
  mount /dev/dm-0 /where/ever

As you probably know, the fsck might actually work, because a fsck can sometimes
correct filesystem errors that the kernel filesystem modules cannot.

8) If the fsck doesn't work, look in the output of fsck and in dmesg for signs of
physical drive errors. If you find them, (a) think about calling a data recovery
specialist, (b) do NOT use the drive!

I _think_ that is the right order to do things in, but I'm not 100% sure.

If this works, I expect a reward, ta.

-- 
Robin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20041214/c6a5cad8/attachment.sig>