[QUOTE=chickenjoy;

Solution:
Put those untampered disks back in exactly the same places.

if not:
None. You would have to reinstall the whole linux system again.[/QUOTE]

Seems a bit daft, no?. The root directory and all the data in boot is Ok but the system needs the whole system reinstall just because the huge memory space was reduced, even though the memory space reduction is not crucial to the systems booting.

That seems to be an area where some reprogramming could be done?

I just looked at CentOS's main wiki page, and this is the very first thing I saw:
Hehe. So apparently CentOS is actually based off of Red Hat, I'm sorry for any confusion I may have caused there. Moving on;

I have never used CentOS in specific before, but try inserting the CDs, then booting from them. (I'm not sure if you know how to do this, but attempt to enter your computer's BIOS after powering it on, this is by pressing a special key when you see its manufacturer come up when you first turn it on. Then set your CD drive as the first boot device, then save the settings and allow the computer to reboot with the CentOS cd in the drive. If you need specific instructions for changing the boot order of your devices, try googling your motherboard maker and model.)

Now once you are at the screen for the CD, try and find an option that contains the word "live" in it. Press enter on that, then the CD will boot up. Hopefully you will see some similar things to what you used to see when you booted up your computer before it became unbootable. Once you are either on a desktop or a terminal screen waiting for input, go ahead and mount the boot hard drive. In a desktop, it should come with a graphical mount manager, but in a terminal you will want to execute the following two commands:
Now browse to or cd into /mnt/sda1, and hopefully you should see the files that you always see when you are normally in the root of your computer.

First thing you may want to do now is open up a terminal if you're not already in one. Then type chroot /mnt/sda1, and supposing that sh and bash are still intact, you will be presented with the same prompt you just had. Except this time you are "virtually" locked into the hard drive, and the only way to exit it is by literally typing "exit". This transition between your live CD and chroot can become fairly confusing, so if you ever are confused, find out what is in the directory to figure out where you are at the moment.

And just so you know, I'm entering a slightly different linux world here, so I apologize if I get something wrong or give you an incorrect command. We'll both be learning here ;)

By default, CentOS comes with what is called a "package manager", which literally manages the packages, or programs on your computer. They are very useful to people who don't want to have to figure out what each package depends on, and then what those packages depend on, etc. etc. The particular package manager on CentOS is called "yum", so just to make sure we have it, type yum. If you get a reply that is not something to the effect of an error, then you are in the green.

Type in "yum update", which will contact CentOS's servers and download any updates it can find for your system. Of course, at this point you will need to be connected to the internet for this to work.

So I'll leave it at that. Once the update(s) are finished, go ahead and exit from the terminal and reboot your computer. See if it boots up, then if you get the same error, there may be more work to do.

Thanks tgp1994
I got the centos cds out but the first one labelled rescue cd does not give any option lie. so i tried linux resue option that it offered.
after a lot of srolling text it came to :-/bin/sh-3.00#
so I will post the output of my typing in commands:

-bin/sh-3.00# mkdir/mnt/sda1
-bin/sh-3.00#mount /dev/sda1 /mnt/sda1
mount: mounting /dev/sda1 on mnt/sda1 failed: inalid argument.

does that mean anything? cheers

Invalid argument? I don't ever remember seeing that come out of mount. Try typing mount -t ext2 /dev/sda1 /mnt/sda1 instead, where the -t is specifying the filesystem type. Of course, if you have ext3 that is what you would put instead.

No, it doesn't.

Your root system may be OK, but if you're referencing any LVM's anywhere (say, for /var, home, etc.), you're done, time to reload the OS and move on. The UID messages you're getting, indicate the LVM can't be rebuilt, because the references are missing. The physical devices are not there, the metadata has been removed, you've got nothing there TO recover.

There are some ways to fix broken LVM's or software RAID array's, but if you overwrite the partition tables, move slices, etc., that's it. No "reprogramming" is going to help you, the metadata that makes LVM/RAID work is gone....you deleted critical data from your disks, period. If you delete things like this, there's nothing that can be done.

LVM's and RAID's are built to be recoverable, when there's something to recover...3 of 4 disks removed and monkeyed around with, doesn't leave you that. If you removed a parity disk, or even a single disk in the array, you could easily recover, which is the purpose of LVM/RAID.

In the time it has taken you to go back and forth here, you could have had a whole new working system, learned about bare-metal recovery tools (mentioned on several threads here, like mondoarchive, systemimager, etc.), and been further down the road with some real understanding of LVM's.

True, if it's just a CCTV computer then you should not need RAID or this LVM. All you would need is one hard drive, first partition set to the main/operating system, and the second one set for linux-swap.

@TBOne

Thank you for coming back to answer.
I have already ordered the new OS disk and the CCTV recording software. The ones that came with the system in 2007 havr long gone missing.
Experimentation is the basis of all improvement and that's what we are doing.
Also, I am not saying the linux with Lvm is in any way inferior to any other system- it has served me well for 3 yrs without a single hitch. But then monkeying around with it has revealed a potential problem. If the first disk has 250 gb which surely is much more than what the OS needs and is untouched, and the other 3 disks are used just to store the recorded video for 2-3 months, then the system should not need a complete fresh install if the storage space is reduced. I do not know in depth the architecture of the system or arrangement of the files/directories, boot programme, but it would be better if the system was arranged such that if I just remove 2 of the 3 hard disks ( used just for storage of video, not any programmes to run the system), then it should not crash completely and need a new install. I am sure the code/ programming can be modified by some genius out there to accomplish this.

cheers

Well I hope this has or will at some point serve someone and help them later on. And did you say "ordering"? Why not download and burn the new os to a cd?

Again, there is nothing to modify. LVM's quite happily handle growing/shrinking of partitions, adding disks, etc. But what you did blew away the metadata, that keeps track of what devices/partitions, belong to what VG, etc. Without that, it doesn't work, period. There is no 'reprogramming' that can be done, to handle this.

If you set the LVM up and put the metadata in a different location, or backed it up elsewhere, you could have recovered. But you didn't. What you're asking for is something akin to "Gee, someone really smart should be able to make a car engine run without all the parts...". It doesn't work that way. LVM's handle errors all the time, but they CAN'T handle intentional misuse, and there's no way to code for such a thing.