Unable to access resume device

jdege · 12-18-2007, 09:30 PM

I have a CentOS 5 system, installed on a single drive with the default paritioning scheme /dev/hda1 as /boot, /dev/hda2 as VolGroup00, with two logical volumes, LogVol00 as /, and LogVol01 as swap.

I've made a backup, and restored onto a second drive, that is partitioned identically, except for the names of the volume group and logical volumes.

I edited /boot/grub/grub.conf and /etc/fstab on the second drive, to use the new names, powered down, removed the first drive, configured the second as master, and booted off of a rescue CD.

From the CD, I ran grub, and did:
root (hd0,0)
setup (hd0)

Then rebooted off the new hard drive.

Grub loads just fine, brings up the menu, and seems to find the kernel. But then I get errors:

Volume Group "VolGroup00" not found
Unable to access resume device (/dev/VolGroup00/LogVol01)
Could not find filesystem '/dev/root'

I've searched for that error message in the forums, but other people who've run into the problem seem to have had issues with accessing various types of HDs. In my case, the problem seems to be that somewhere, somehow, the kernel is trying to load the swap device using the wrong name - using the name that had been correct, when the kernel was on my old drive, but is not correct on the new one.

So the question is, where is the kernel looking to determine where it should be loading swap from, other than in the arguments passed to it by grub, or in /etc/fstab?

I've grep'ed both /boot/grub/ and /etc/, and there's no reference to VolGroup00 in any file in either of them.

grub.conf:

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-53.1.4.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-53.1.4.el5 ro \
root=/dev/LVG20071218/root rhgb quiet
initrd /initrd-2.6.18-53.1.4.el5.img

fstab:

/dev/LGV20071218/root / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
/dev/LGV20071218/swap swap swap defaults 0 0

jschiwal · 12-18-2007, 09:39 PM

Why do you have your swap partition on the logical volume? That is probably the problem. Boot shouldn't be on a logical volume either.

jdege · 12-18-2007, 10:26 PM

Quote:

Originally Posted by jschiwal

Why do you have your swap partition on the logical volume? That is probably the problem. Boot shouldn't be on a logical volume either.

I'm testing a backup restoration. I put swap on the new disk in the same place as it was on the old disk (which is where CentOS's install program put it).

On the old disk, it worked fine.

Boot isn't on a logical volume. Swap on a logical volume is only a problem if the kernel+initrd doesn't understand LVM, and this kernel+initrd does.

The question isn't why it can't read swap, the question is where is it getting the name 'VolGroup00'? It's not in grub.conf, and it's not in fstab. Where is it coming from?

jschiwal · 12-19-2007, 09:35 AM

What does "pvdisplay" say are the PV and LV names? Do these match with your menu.lst and fstab entries?

jdege · 12-19-2007, 10:06 AM

Quote:

Originally Posted by jschiwal

How does grub find and load the kernel and initrd if it doesn't understand lvm?

Why don't you try actually reading what I wrote?

From the first post:

Quote:

I have a CentOS 5 system, installed on a single drive with the default paritioning scheme /dev/hda1 as /boot, /dev/hda2 as VolGroup00, with two logical volumes, LogVol00 as /, and LogVol01 as swap.

And from the second post:

Quote:

Boot isn't on a logical volume.

The kernel and initrd are in the boot partition, which has been the default location for them for a good many years, now. And the boot partition, as I've already said twice, is not on a logical volume.

jdege · 12-19-2007, 01:53 PM

Quote:

Originally Posted by jschiwal

What does "pvdisplay" say are the PV and LV names? Do these match with your menu.lst and fstab entries?

PV names? The PV names are the same, on both disks, and IIRC, the PV name isn't referenced in menu.lst or fstab.

The VG name and LV names are the same on the disk as in menu.lst and fstab. But most importantly, neither menu.lst nor fstab containthe VG and LV names that are being asked for after the kernel loads.

There has to be something else that accesses these names. But it's not fstab, and it's not anything in rc.d, and I'm at a loss as for where else to look.

Does Linux still burn device names into the kernel the way it used to back in version 0.99?

jschiwal · 12-19-2007, 06:20 PM

You may have responded after I revised my second post.

Code:

  --- Physical volume ---
  PV Name               /dev/hda2
  VG Name               VolGroup00
  PV Size               18.53 GB / not usable 31.21 MB
  Allocatable           yes
  PE Size (KByte)       32768
  Total PE              592
  Free PE               1
  Allocated PE          591
  PV UUID               OO2cnO-yx2e-zfiL-nzd8-SMKe-eHix-Y1cnZ0

I was wondering if VG Name would be VolGroup00 instead of LVG20071218.

What does ls /dev/mapper/ say?

These files are usually the targets of /dev/VolGroup*

Code:

sudo ls /dev/VolGroup00/ -l
total 0
lrwxrwxrwx 1 root root 31 Dec 18 09:05 LogVol00 -> /dev/mapper/VolGroup00-LogVol00
lrwxrwxrwx 1 root root 31 Dec 18 09:05 LogVol01 -> /dev/mapper/VolGroup00-LogVol01

Could using vgrename fix the problem?

jdege · 12-19-2007, 10:36 PM

Quote:

Originally Posted by jschiwal

I was wondering if VG Name would be VolGroup00 instead of LVG20071218.

VG Name on the old drive is VolGroup00, VG Name on the new drive is LVG20071218.

Quote:

Originally Posted by jschiwal

Could using vgrename fix the problem?

If I rename the VG on the new drive to VolGroup00, then the two drives will have the same names, again, and I won't be able to mount them in parallel. Which is why I renamed it in the first place.

jschiwal · 12-20-2007, 07:07 PM

I was thinking you pulled the old volume. You might try adding the "noresume" kernel boot option and see if it will boot up. If it does run the lvscan command and see if it barks about anything. I think that both LVM volumes should be detected by the kernel during bootup.

Since you want to backup and restore the entire volume, you might want to use snapshots.
http://www.howtoforge.com/linux_lvm_snapshots

jdege · 12-20-2007, 10:32 PM

Quote:

Since you want to backup and restore the entire volume, you might want to use snapshots.

Yep. Now that I've finally worked through all my problems, I'm doing that.

1. I've given up on trying to change the volume names. I have to put just one disk in, boot from CD, rename the volume on that disk, shut down, put the other disk in, and boot up, to see both volumes at the same time, Then reverse the process when I want to boot from the other disk. If I hadn't had Vantec removable HD slides installed when I bought this machine, I'd have been tearing my hair out. (If both disks are installed in the machine, there are two volume groups present with the same name, and the LVM tool can't manipulate either of them.)

2. I don't really understand why RedHat bothered with LVM at all, for their default configuration. The two benefits I can see n small, single-disk systems, are the ability to move partion boundaries, and the ability to create snapshots. But they create only one partition, so moving partition boundaries is irrelevent. And they allocate all the space, so there's no room for snapshots. You can, of course, shring the logical volume within the volume group, but that means shrinking the filesystem, and that's not something I'm willing to try until _after_ I have a solid backup. So I allocated space on another drive, added it to the volume group, and created the snapshot there. I'll delete it when I'm done.

3. In earlier versions of Linux, "tar --preserve" worked fine for backups and restores. These days, you need "tar --preserve --xattrs".

4. Backing up 80 Gig across a USB line takes quite a while. It'd be faster if I were working IDE to IDE. But when I'm restoring a full disk, I can't restore to the disk I booted from, and I can't boot from the disk I'm restoring from. And since I only have two of the VanTec removable HD bays, that means booting from CD, which means a system that is unusable until it's done. If I boot from one IDE, I can copy from USB to the other, and have a running system the entire time. Which may take longer on the clock, but it's a _lot_ less downtime.

In any case, I thank everyone for their help and their patience.