It happens to me more than I'd like. A piece of hardware fails and I can't get to my data any more. My MB's been acting up so I replaced it (and an ATI video card).

Now it can't seem to find any volume groups.

I get
Volume group "VolGroup00" not found.
Unable to access resume device (/dev/VolGroup00/LogVol01)
...

I can mount the drive in the rescue portion of the Fedora 9 install but I don't know what to do next. I can see my files ...

I tried
chroot /mnt/sysimage
then
grub-install -–recheck /dev/sda

but it still fails.

(I tried sda1 and sda2 as well).

Does anyone have any insight or at the very least does anyone know of a "complete idiot's guide" to this cuz I'm pretty sure I'm it!

Thanks in advance,
m
=

When the Initial RAM disk image is created, the nash script includes a section similar to this:
Before your boot fails, you are probably presented with a message that the system is scanning all the devices for logical volumes, and that no such volumes were found. (Or, if any were found, you should get a message listing all the volumes that were found, and VolGroup00 is not in the list.) So your disk drive(s) access is not working correctly.

I suspect that your problem is a BIOS setting which is making disk access unreliable for Linux. Try changing the settings in your BIOS related to things like "Compatibility Mode" for hard drive access. (My suspicion is formed from your statement that you have a new M/B, so you, perforce, have whole a new set of BIOS settings that you've got to get correct.)

Hi PTrenholme,

Well I went from an ASUS A7N8X Deluxe to a Biostar M7NCD ultra. I would have prefered to keep my ASUS but UPS had their weekly game of rugby and they apparently needed a ball. *sigh* oh well.

The M7NCD Ultra has the settings Optimal, Expert and Turbo. I've got it set on Optimal. Originally it wouldn't even recognize the drive but after a bit of Googling I found out that the HD won't work unless I downgrade it (with a pin) to SATA I. I didn't have to do that on the A7N8X Deluxe. *sigh again*.

I can mount the drive and I can access it. I FTPed a video file over to my XP machine and it played fine so the drive integrity seems ok. I can also run Samba so I can access files that way too. As a last resort I can Samba all the files over to my XP machine but unfortunately I've only got 30GB free on it. (I've got 425GB of data on my Fedora partition.)

I'm hoping there's a way to get the boot to recognize the VolGroup00.

Out of curiosity... what is a nash script?

M


M

Well, for the easy part first, nash is a "bash without the bells-and-whistles" that Red Hat developed to control the login process. The scripts look a lot like bash and the nash script is read by the Initial RAM Disk image to control the loading of the "real" Linux system. In other words, it's the boot process supervisor.

Now to the harder part:

First, a brief digression about the Gnu GRand Unified Boot Loader (GRUB):

Your initrd image is, presumably, loaded from a GRUB script. Somethil\ng like this:By default, most of that is hidden when you start your system, and, at most, you only see the title line for a second or so. (That's the effect of the hidemenu just before the title.) When you see the title line, you can press the <Esc> key to halt the process and display the basic GRUB "action" menu.

The last two lines specify the location of the Linux kernel and the initial RAM disk imaage to be used during the boot.

As i said, that was probably a digression because, in your case, those two lines are probably correct. Although you should verify that your root= section has not been corrupted. (It should read root=/dev/VolGroup00/LogVolume00 if I recall correctly. As you can see, I prefer more mnemonic names.) If there was any problem with the GRUB script, you would not have gotten as far as you did with your boot.

In fact, GRUB must have read the kernel line and passed it to the initial RAM disk, which must have been correctly loaded since the error message you received was generated by the the resume command in the nash script. Here's what that section looks like, for what it's worth:(The two error messages you see are generated by the commands I highlighted in red, although your nash script probably used the default names.)

So the "cup" must have "slipped" somewhere between the reading of the initrd image and the mounting of root device.

The possibilities of which I can think are:

1) The drive is not being accessed properly. (There are some IDE access modes which use undocumented Microsoft features. Those modes can not, of course, be used by Linux systems.) You mentioned that you're using a SATA drive, and that you set the BIOS to access it as a SATA-1 instead of a SATA-2 drive because your new M/B does not support SATA-2 access. It's possible that the Fedora kernel is "resetting" access to SATA-2 because the drive, when interrogated, reports that it supports SATA-2 access. (This happens with my laptop, and a get a page of error messages before the driver gives up and reverts to SATA-1. But that's after the boot.)

Anyhow, this was why I suggested experimenting with your BIOS settings.

2) On this laptop, I can only boot from an older SATA drive, not the newer one I installed as a second drive. I had to move the boot files to the older drive and point GRUB there before I could boot at all. In your case, since you seem to only have one drive, I suggest you try setting up either a GRUB boot floppy (if you've got a floppy drive), or a USB stick as your boot device. If you can boot from either of those, then I'd suspect that Fedora is resetting the access mode to the "preferred" mode reported by the drive. (Assuming that the reported "preferred" mode is not changed by the jumper setting.)

This should work since you can boot in rescue mode.

3) See if you can return the m/b and get a more modern one so you can use your drive as it was intended to be used. (Or, see if there is a BIOS upgrade available from the manufacturer that enables support for SATA-2 drives.)

I have a really dumb question. How many drives do you have? Could the order be reversed?
Sometimes the bios says the drives are in one order but the kernel sees them in another order. So when grub boots it relies on what the bios says, but grub-install sees them in another order. Could swapping the cables help with booting?

Did you try running "lvmdiskscan", "lvscan" and "lvdisplay" from the rescue disk?

Also look at "vgscan", "vgdisplay", "vgck". If vgdisplay shows the volume(s) run "vgmknodes" to create the device nodes.

jschiwal: It's not a dumb question. I have one SATA 500GB drive and an IDE DVD Burner.

PTrenholme: Thanks for the explanation. I definitely need to get a 'For Dummies' book.

Unfortunately if I have to upgrade my MB I'll have to do the entire machine. I've got an AMD Socket 462 machine so I'd have to replace the MB,CPU,RAM and Graphics card. I will if I can't figure this out but...

If I had to guess I'd say it was #1. I just bought a new 650Gb drive and transferred everything off of it. I'm wondering if reinstalling might be easier. My grub.conf seems similar to your above. I also checked and I can find /dev/VolGroup00/LogVol00(it's a link to another file) Here's my grub:

O.K., if you have a USB pen drive - even 64Mb would do (if you could find one that small) - and if your BIOS can be set to boot from a USB drive, you can you explore option 2.

On your XP box, go to the Universal Netboot Installer site, download the exe and (with your Pen drive plugged in to the XP box), run the executable. Install the "Smart Boot Manager" or the "Super GRUB Disk" to your pen drive, reboot, and see if you can use the manager to boot Fedora from your SATA drive.

Both of those managers have built-in help files, and web sites where you can find other advice.

If you can get a boot from the pen drive, then you should be able to install GRUB on that drive (or, if you used the "Super GRUB" manager, you'll already have GRUB on the drive).

If you problem was similar to mine, you may need to move the /boot directory from you HD onto the USB drive and point GRUB (on the USB drive) to that as the boot source. But, hopefully, you'll have a usable system as long as you leave the USB drive plugged in.

(By the way, if you splurge on a larger - say 1 GB - pen drive, you'll note that the UNbootin executable gives you several "Live CD" Linux distributions as options that you can put on the that drive. Last time I saw a 1GB pen drive offered, it was less that $5.)

You know, I may have lead you down the wrong path.

<edit>
First, let me explain what happened to me after I posted the above:

I loaded SBM onto a USB pen drive to make sure it worked before finishing the post. Then I posted the above, and then said to my self, "Ah ha! Maybe I could use SBM to get my second SATA to boot!" So I played around a bit, and made a few changes to the MBR. Just changing the "boot" and 'active" flags. Nothing worked (which didn't surprise me since the problem is, I think, a M/B - BIOS -HD mis-match), so I said, "Rats!" and rebooted.

Then I was really surprised to find that none of the Linuxes I have installed on the system would boot (although the Vista that came with the laptop still booted). So, out came my trusty Fedora Live CD, and - when I did a fdisk -l /dev/sd?, I got a message that the partition table on sdb did not look like a "real" partition table, although fdisk proceeded to list the partitions with no problem.

The "fix" was fairly simple: I started parted /dev/sdb and did a toggle 1 boot twice which forced parted to re-write the partition table. Then fdisk no longer complained, and I could, once more, boot everything on the HDs.

So, it then struck me that your problem could, perhaps, be related to partition table differences. Which lead me to the idea that the UUIDs might have, somehow, been changed. Hence this post. And this edit, so you could think about subtle changes in your partition table, eh?
</edit>

It's possible that the UUID of the logical volume was altered when the old SATA drive was booted by the new M/B. If that happened, the LVM backup and archive files would point to a different UUID than the one being reported by the vgscan and, of course, LVM would therefore not be able to access the volume group.

Do you have the Fedora LiveCD, and can you boot that CD on your system? (It's really a CD, so it doesn't take all that long to download a copy of the ISO file and burn it to a CD.)

So, assuming you have it, or (see the last paragraph, below) from "rescue" mode:

1) Boot from it and log in as "root" (no password needed on the Live CD)
2) Do a pvscan to see if the VG is found. (It should be since "rescue" found it.)
3) Do a pvdisplay to see the UUID of the physical volume
You should get something like this:4) Do a vgchange -a y to activate the logical volume
5) Do a mount /dev/VolGroup00/LogVol00 /mnt to mount the logical volume
6) Do a cat /mnt/etc/lvm/archive/*.vg | grep -B 1 "id =" to see the stored UUIDs. Here's mine (Remember, I don't use the default names.)The first id is the UUID that lvm assigns to the logical volume. The second id is the actual UUID of the (first) physical volume in the volume group. (If there were several physical volumes in the logical volume, they would be ph1, ph2, etc.)
Anyhow, that pv0 UUID should be the same as the UUID displayed at the end of the pvscan. If it isn't, that is probably the root of your problem.

Of course, this may be another red herring, but it should be an easy for you to check.

Oh, I just realized that you could do all of that without the "Live CD." Just boot into "rescue" mode but don't do the chroot. Then you'll be logged in as "root," and can proceed as above.

I had the same problem, so I found this thread. My short story: My (old) PC (a customized Gigabyte-MB with a Sempron) went to hell, so I ordered new components (MB, CPU, RAM). I didn't want to loose my carefully configured Fedora 9 installation, so I kept my harddisk for further use. Until the new components arrived, I plugged the harddisk with my Fedora into my (very old) PC with an 800 MHz AMD K6. No problems so far.

Some days later, the new components arrived and I installed them into my (old) PC and re-transferred my hard disk from my (very old) PC. The effect was as described in this thread, useless to repeat the features. I tried all the tips from here and from other threads. (I learned a lot about LVM).

Nevertheless, nothing of the fiddling around with the logical volumes, grub, parted etc helped - until I found this thread at RedHat:
https://bugzilla.redhat.com/show_bug.cgi?id=466071
Althouh I have Fedora 9 and neither a release candidate of Fedora 10 nor any vmware stuff, the main kickstart for me was the simple idea, that nash starts dealing with LVM, while the device drivers were still busy with the harddisc-setup.

This seems to be realistic, because my new CPU / MB combination is much quicker than the old one. Also, when booting the rescue system of the Fedora live CD, the time between driver initialisation and using the LVs is much, much bigger. So I followed their hint (Creating the file /etc/sysconfig/mkinitrd with the one-line content 'MODULES="scsi_wait_scan"' and rebuilt the initrd) - bingo!

Now, my new PC booted without any problems!

Good end of this story for me?

YES and NO - YES, because my problem is solved.

NO, because this wasn't the reason for not booting.

Because I'm curious about such things, I inspected the old initrd and the new one. Of course, I made a diff of the init-scripts for nash.

And this showed me the reason.

Could it be such simple? Just loading the wrong driver for the harddisk? OK, that would make the system unbootable. Also OK that the rescue-system as well as the Live CD can access the LVMs, because they probe for the correct driver during booting.

I deleted my just created file /etc/sysconfig/mkinitrd and rebuilt the initrd again, this time without any modifications, and installed it.

And - you guess it - my PC booted!

Well, just re-creating the initrd file was the solution for me (and, I think, for some others with this problem).

@Maleki: I'm not sure whether this solves your problem. Both of your MBs use the same chip (nForce 2). Ok, obviously different generations.
Anyway, creating a new initrd is a simple task and it's worth a try.

Sorry for this long article, I'm just happy to have a running system ...

Good luck & kind Regards,

Peter