That command does not print out anything.

My version of blkid is very old, maybe that explains.
blkid 1.0.0 (12-Feb-2003)

Try this and see if that helps:

Hmm, very strange. It produced:
/dev/mapper/VolGroup00-LogVol02: DOS executable (device driver) for DOS

I was expecting it to return ext3 but the output is something unexpected. I have no idea what to try with this. Did you perform mkfs anytime after removing it from LV? Not sure how can ext3 fs can turn into DOS. I have tried file command on my RHEL 6 and the output shows me the file system with which it is formatted. May be because F10 is quite old file command not showing the correct output but cannot for sure.

I was expecting anything else but DOS. As I told, I've tried to find a file system in this disk with e.g. Testdisk. I wonder if it can cause something like this. Otherwise I have refused to write on this disk with any program other than Gparted. I have written an LVM flag sometimes on the disk, just because I had no other idea.

I am out of ideas for now, I am away from my test system and cannot say for sure what you could try. The message:

I got yesterday during testing but that was because I have done vgcfgrestore incorrectly. Once I figured it out it went fine. I would suggest you to recheck the steps that you have performed so far.

---------- Post added 05-04-15 at 04:55 ----------

Another thing you can try to see if you get more information is:

This will give you UUID information.

Don't worry, you have also helped me a lot! I will check my commands.
That file command returned:
/dev/sdb1: LVM2 (Linux Logical Volume Manager) , UUID: sb4SLylaOqJGaXzctrmtkJ9Zfb23gPU

as promised.

The graphical LVM interface allows me to edit the properties of a Logical Volume. It also shows that this volume has no file system. I can select the file system and choose it to be mounted and/or mounted at boot and name the mount point. I suppose this edit would format the disk again and edit fstab? I cannot be sure if I have anything left on this disk, but this would make sure there isn't anything. I will not do it.

Also, let's see the contents of /etc/lvm/backup/VolGroup00. Hopefully, it matches the archived metadata that you posted earlier. [EDIT] That's aside from differences in device names.

Another bit of useful information would be the output from

This file command produced the same result as "file -sL", namely:
/dev/mapper/VolGroup00-LogVol02: DOS executable (device driver) for DOS

The current LVM conf in /etc/lvm/backup/VolGroup00 is:
# Generated by LVM2 version 2.02.39 (2008-06-27): Mon May 4 01:04:27 2015

contents = "Text Format Volume Group"
version = 1

description = "Created *after* executing 'vgchange -ay VolGroup00'"

creation_host = "localhost.localdomain" # Linux localhost.localdomain 2.6.27.41-170.2.117.fc10.x86_64 #1 SMP Thu Dec 10 10:36:29 EST 2009 x86_64
creation_time = 1430690667 # Mon May 4 01:04:27 2015

VolGroup00 {
id = "Yc5AQm-23OO-0Rs5-tw7R-HzdR-iOcy-K2e0Ev"
seqno = 10
status = ["RESIZEABLE", "READ", "WRITE"]
extent_size = 65536 # 32 Megabytes
max_lv = 0
max_pv = 0

physical_volumes {

pv0 {
id = "Husf13-G5Ed-wuuD-UBcI-6EjZ-zQnW-1EHdkm"
device = "/dev/sda2" # Hint only

status = ["ALLOCATABLE"]
dev_size = 487990440 # 232.692 Gigabytes
pe_start = 384
pe_count = 7446 # 232.688 Gigabytes
}

pv1 {
id = "sb4SLy-laOq-JGaX-zctr-mtkJ-9Zfb-23gPUB"
device = "/dev/sdb1" # Hint only

status = ["ALLOCATABLE"]
dev_size = 3907024002 # 1.81935 Terabytes
pe_start = 384
pe_count = 59616 # 1.81934 Terabytes
}
}

logical_volumes {

LogVol00 {
id = "OiJx9U-oSOX-vKVo-hTTM-BmMR-E4oi-7aPAMW"
status = ["READ", "WRITE", "VISIBLE"]
segment_count = 1

segment1 {
start_extent = 0
extent_count = 7350 # 229.688 Gigabytes

type = "striped"
stripe_count = 1 # linear

stripes = [
"pv0", 0
]
}
}

LogVol01 {
id = "psguY9-0QmF-S58p-Iowo-Sz1c-iQja-lW4pxj"
status = ["READ", "WRITE", "VISIBLE"]
segment_count = 1

segment1 {
start_extent = 0
extent_count = 95 # 2.96875 Gigabytes

type = "striped"
stripe_count = 1 # linear

stripes = [
"pv0", 7350
]
}
}

LogVol02 {
id = "apdg4m-EqzS-JNrz-4h9g-Yoc3-92S3-MdPzu3"
status = ["READ", "WRITE", "VISIBLE"]
segment_count = 2

segment1 {
start_extent = 0
extent_count = 1 # 32 Megabytes

type = "striped"
stripe_count = 1 # linear

stripes = [
"pv0", 7445
]
}
segment2 {
start_extent = 1
extent_count = 59616 # 1.81934 Terabytes

type = "striped"
stripe_count = 1 # linear

stripes = [
"pv1", 0
]
}
}
}
}

It certainly looks like the LV got reassembled properly. Let's see what is actually in there. Post the output fromIf you somehow don't have hexdump installed, an acceptable substitute would be

I studied a little the graphical interface of LVM. The physical view shows this SATA disk has 59616 total physical extents. Then there is a choice available to Migrate Selected Extent(s) From Volume. What does that do?

I have hexdump. So the output is:
00000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000040 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000a00
5+0 records in
5+0 records out
2560 bytes (2.6 kB) copied, 0.0328495 s, 77.9 kB/s

Looks pretty empty to me.

I afraid I need to remove this SATA disk again from the LVM to be able to boot next time. It is already late here. I gather we can get to this same state easily now?