Hello,
I tried the amd64 version of Gparted and to my surprise I found a function called Rescue in some menu.

However, when I selected it and pressed OK, the system froze. Something was still running, the real time was updated at the lower left corner of the graphical screen. After a while, I tried to interrupt and reboot the PC. Then the updates to real time stopped. I didn't know if it worked or not.

I am not sure, if the CD was even ok. There were lots of I/O errors during boot. I will make a new CD and retry.

Happy Mayday!
I tried with a newer version, maybe 0.22.-1. Also this version has some errors during start-up, but the graphical interface appeared. It is just the behaviour of the program that it does not tell what it is doing. Maybe the earlier version also worked, but I interrupted it.
I let it work overnight and in the morning I found the result:
"The disk scan by gpart did not find any recognizable file systems on this disk."
So, I understand when you remove a disk from LVM, it will be non-recognizable. I have also tried Testdisk and something else, but they haven't found any files either. I suppose nothing else can be done. Thanks for all help you have given.

You're welcome.

If that is the case then you have to restore it from the backup as that is the only option I can think of. As I mentioned earlier removing and adding disk / partition to LVM would be considered as unallocated space whether you put it or take out.

Agreed.
There is something mystical in this PC. I guess as long as I run Fedora 10 in it, I cannot use these SATA disks in LVM, but only in the traditional way. I checked the drive connections. IDE disk goes to IDE1 on the mobo. 300GB SATA disk goes to SATA1. 2TB SATA disk goes to SATA2. CD drive goes to SATA4. If something disturbs the OS detection of them, I believe it's the CD drive. We can of course continue this discussion in another group...

Yes, we can have a separate thread for that discussion. You can mark this thread as solved as there is nothing much can be done on this issue.

I disagree. This looks like it should be easily recoverable, depending on just what was done to remove the new disk from the volume group and whether any subsequent LVM configuration changes were made. You don't find any filesystem on that disk because the start of LogVol02, and thus the filesystem's primary super block, was on the smaller disk.

LVM doesn't care how the device names change. By default it searches all block devices for PV headers. The device names in the backup and archive files all carry a "# Hint only" comment.

Restoring the LVM configuration to its previous state should be just a matter of runningYou might have to do that from something newer than Fedora 10. I'm not sure what the state of vgcfgrestore was back then, though I know it was working in Fedora 12. Do read the manpage for vgcfgrestore first, though.

1 members found this post helpful.

I think you are missing something here, check the output he pasted for pvs:

I don't see /dev/sda1 in the list of pvs output, which basically means that pvremove was issued. Once pvremove is issued it will wipe off the data and in that case vgcfgrestore is useless. We have to also keep in mind that pvremove will not be caught in vgcfgrestore archive as it is not about logical pooling / volume.

I do agree with your suggestion that vgcfgrestore is useful for restoring vg / lv information but the scenario here is different.

@ vpp:

Just to confirm, the output of pvs that you shared here is when your other disk (big disk) was connected to the system but wasn't part of LV. Is that correct?

This is getting interesting. Of course I want to think it is possible to somehow make that big SATA disk once again part of LVM, but the method must be such that there will not be any need to reboot to make the disk contents visible. The actual issue was born after getting the system up with one small IDE disk, one small SATA disk and one bigger SATA disk. After that it was no longer possible to reboot until both SATA disks were taken out of LVM.
I kept the big SATA disk aside, but tested with the smaller one. All I found out was that this PC won't boot, if there is a SATA disk in LVM configuration. Now that SATA disk is part of the file system in traditional way.
During this discussion I have learned that it is also strange that the names of the disks change. They also changed during the tests I made. I don't know how this affects the boot with SATA disks in LVM. I suppose the age of the OS and/or initrd might be the reason/s for this behaviour.
At some point I tried vgcfgrestore only to notice that the command regards most archived LVM configurations invalid. However, of them is exactly the one containing the big SATA disk before removing, but invalid.

Alright lets do this, connect big SATA disk to your system and then share the output of pvs, if pvs shows that there is physical volume on that disk then there are chances of restoring it. If pvs output does not show pv on big SATA disk then there are two things: either you ran pvremove command when you were performing lvremove and vgreduce from rescue mode, or for some reason system is not able to see pv on big SATA disk. In both the cases I don't think data can be recovered.

Edit: Run: pvscan if it doesn't not show up initially in pvs output, if it does not show even after running pvscan then it is not there.

Oh, I forgot to confirm that all these three disks have been connected to the mobo all the time I have had this issue.
Right now the output of pvs is
PV VG Fmt Attr PSize PFree
/dev/sda2 VolGroup00 lvm2 a- 232.69G 32.00M
Probably because I changed the socket of the bigger SATA disk from SATA3 to SATA2. Or maybe the device names just change arbitrarily.

Can you confirm if the result is the same even after running pvscan. I edited my initial post, I guess I wasn't fast enough.

I didn't catch that. The pvremove command won't have wiped anything but the PV header, and it just means that one more step needs to be done first:Note that here you must use the device name that matches where the device is attached when you run the command. Now you will have a PV that is consistent with how it was defined before, and you can then run the vgcfgrestore command.

1 members found this post helpful.

Yes, you are right. I did more testing and was able to get back my pv by using initial uuid (reboot included). Had the wrong impression of the commands pvremove doesn't touch data but pvmove does.

Haven't encountered such scenario, long back I worked on a request to replace a failing disk and if I remember correctly I did pvmove and then pvremove. I was in the impression that direct pvremove will harm the data and that is the reason we get data off the disk first running pvmove and the pvremove.

Thanks for clarifying and pushing me to test this stuff. Glad that learned something new!!

Now, if it can just help the OP as well, ... .

Yes, pvmove can be deadly, and especially a pvmove that was incorrectly interrupted.

BTW, getting the Fedora 10 boot to see the SATA drive might be as simple as going into the BIOS setup and configuring the SATA interfaces in "Legacy IDE" mode. I'm not at all sure about that one.