This is a server. It has 120 GB drives which are overkill.

The root fs on this server resides inside an LVM volume.

When you're in the rescue environment, is LVM even activated? What does ls /dev/mapper/ show?

What's the output of pvdisplay, vgdisplay, and lvdisplay?

It seems /mnt/sysimage is supposed to contain a mounted filesystem representing the root fs of the server. Is that the case? If not, then it's no wonder you can't chroot into it.

That's easily fixed, though: You just have to activate the volume group, mount the root fs to /mnt/sysimage, mount /dev/sda2 (the boot partition) to the now available directory /mnt/sysimage/boot, then chroot into /mnt/sysimage and finally mount /sys and /proc manually.

ls /dev/mapper/

pvdisplay
nothing returned

lvdisplay
nothing returned

Yes, like I've been saying, upon loading the rescue OS, it can't see any image to repair. "No Linux partitions" All that grub2 work killed things that rendered this a bunch of files instead of a recognizable OS.

So you say I have to:

- activate the volume group
- mount the root fs to /mnt/sysimage
- mount /dev/sda2 boot partition to the directory /mnt/sysimage/boot
- chroot into /mnt/sysimage
- mount /sys
- mount/proc

I have no idea how to do any of those. So not easily fixed. Resetting the CMOS to get back into the BIOS was a bit much if you ask me.

that is probably the rescue usb, you mentioned in your orginal post. There was no mention of any other drives?

vgchange -ay --ignorelockingfailure

You may not need the last parameter.

If nothing happens, try running pvscan and then vgscan, then try again.
mount /dev/mapper/<something-or-other>centos-root /mnt/sysimage

Not exactly sure what the full name of the activated volume will be (except it will contain "centos-root") since I don't know the name of the Volume Group, but ls /dev/mapper/ should display it.
mount /dev/sda2 /mnt/sysimage/boot
chroot /mnt/sysimage
mount -t proc proc /proc
mount -t sysfs sysfs /sys
You do now.
Who knows. It might be.

When you get back into you system,

It will look something like this, but the sizes will be different and sda,sdb may be reversed.
I mainly want to know if the partition table is gpt or msdos, if any disk flags are set, files system for each partition and flags for each partition

- Nothing happened
- No matching physical volume found (pvscan)
- Reading volume groups from cache (vgscan)

Then nothing again, both without and with that last parameter.

Only sda shows up, and it's msdos. Sorry, no flags at all.

"Nothing" may be OK, but the "no matching physical volume" message definitely isn't something I'd expect to see on a system using LVM.

If LVM is active, there should be links in /dev/mapper to the various volumes, but if LVM can't activate the volume group(s), the directory will only contain the character device "control". What does ls /dev/mapper/ show?

Is /dev/sda3 present, and is it an LVM partition? Please post the output from fdisk -l /dev/sda.

ls /dev/mapper:
control
live-base
live-rw

/dev/sda3 is nor present, just sda1 (boot), and sda2 (EFI)

Then you don't have access to the LVM Volume Group and the Logival Volumes contained therein, which means you don't have a root filesystem to mount.

So where did your LVM/root partition go? If it's been accidentally deleted, it should be pretty easy to recreate it.

Could you please post the full, unedited output from fdisk -l /dev/sda and fdisk -l /dev/sdb?

I have absolutely no clue.

$ fdisk -l /dev/sda

Disk /dev/sda: 8086 MB, 8086618112 bytes, 15794176 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimal/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier 0x4e2780e2

Device Boot Start End Blocks Id System
/dev/sda1 * 0 1929215 964608 0 Empty
/dev/sda2 444 17851 8704 ef EFI (FAT-12/16/32)


$ fdisk -l /dev/sdb
fdisk: cannot open /dev/sdb: No such file or directory

Oh, I see; the drive we've been dealing with all this time is actually the 8 Gb USB stick you've been using to boot the system. And of course this is using EFI.

No wonder the LVM subsystem found no volumes; all this time we've been barking up the wrong tree. No worries, we'll just have to take a step back and try again.

The first question is: Where are your drives? It seems really odd that a CentOS-based rescue system would be unable to detect an AHCI disk controller.

See what the kernel log has to say about disk controllers and drives, and post the results: dmesg | grep "ata\|scsi"

Every supported disk controller is registered as a scsi controller, and there vill be a message saying something like "scsi host0: Fusion MPT SAS Host" (the last part will identify your actual hardware). Then there will be an "atax.yy" entry for every detected SATA drive, something like this: "ata2.00: ATA-8: HGST HTS721010A9E630, JB0OA3J0, max UDMA/133".

Also post the output from lspci as it will show the actual hardware present in your server. It should then be pretty straightforward to identify the disk controller and figure out what we have to do to load the requisite modules and have the drives show up.

The internal drive isn't showing up. Either the drive died or a setting in the bios is wrong. Do you have an option in bios settings to restore defaults? If so, recommend trying that