"No volume groups found" when using LVM to decrease partition size

Good morning and thanks for your time,

First time using LVM here, and am out of options other than to decrease the size of my /dev/sda4 partition and give some of the space to /dev/sda1 (this is my system partition and is completely full because the previous admin only gave it 16 GBs). I've attached a screenshot of "df -h" output for convenience.

Long story short, /dev/sda1 is full and i need to extend the partition size. /dev/sda4 is 2 TB, so I need to reduce it by 1 TB, and give 700 GB to /dev/sda1 and 200 GB to /dev/sda2 (also way too small). This drive is part of a hardware Raid (mirroring); I'm wondering if this has anything to do with my issue.

Here's what I've done so far and the error I receive:
I booted into Rescue Mode and unmounted /dev/sda4, then ran the following commands...

e2fsck -f /dev/sda4

resize2fs /dev/sda4 1000G

lvreduce -L 1050G /dev/sda4

then receive this error

Volume Group "sda4" not found

When I ran

vgdisplay

I receive this error

No volume groups found

I'm hoping I'm just typing a command wrong or forgetting a command. Thanks for any advice you can provide!

/dev/sda1 and /dev/sda4 aren't part of a VG, they are stand alone partitions and not managed as part of an LVM.

You could take the system down and try with gparted to resize / move the partitions on the physical disk.

BUT TAKE A FULL BACKUP OF YOUR SYSTEM AND VERIFY YOU CAN RESTORE IT FIRST.

As noted, /dev/sda1 and /dev/sda4 aren't using LVM. There is a traditional *nix alternative to resizing the partitions. You can directories folders from / to /state/partition1 and use symlinks or bind mounts within /.

It takes some experience and knowledge to know what things are safe to migrate off of "/", though. For example, do NOT migrate all of /usr, but /usr/share/doc is a good way to get a decent chunk of space.

But more basically, it's a little strange for "/" to be out of space. 16GB should be plenty of space. Something in particular must be consuming a lot of space. I'd migrate that off of "/".

Long story short, /dev/sda1 is full and I need to extend the partition size. /dev/sda4 is 2 TB, so I need to reduce it by 1 TB, and give 700 GB to /dev/sda1 and 200 GB to /dev/sda2 (also way too small).

You can't just "give 700 GB to /dev/sda1" from sda4 as they aren't contiguous. You could do this with LVM but not regular physical partitions. However considering how much space you have you could create a new future root partition of 700 GB or less such as sda5, rsync all of the contents (only 16 GB) to it, and then mount it as the new root. The old 16 GB sda1 could then be used for something else.

However as Isaac said you don't need 700 GB for a / partition. You also don't need a 200GB /var when you are only using 62% of a 3.9 GB /var. Increase it yes but not by 50X. You could re-use sda1 after its contents have been moved to the new root.

This drive is part of a hardware Raid (mirroring); I'm wondering if this has anything to do with my issue.

If this is true 100% hardware RAID then it should be transparent to the OS.

Also as others have said sda4 is not part of LVM.

Thank you all, these were very helpful. I've been learning a lot about this in the last couple days.I really like the idea mentioned by "tofino_surfer"

create a new future root partition of 700 GB or less such as sda5, rsync all of the contents (only 16 GB) to it, and then mount it as the new root. The old 16 GB sda1 could then be used for something else

...this sounds fairly simple, but I've never done anything like this on Linux? Any resources you could share that may help walk me through this?

Originally Posted by dj_thrive Thank you all, these were very helpful. I've been learning a lot about this in the last couple days.I really like the idea mentioned by "tofino_surfer" ...this sounds fairly simple, but I've never done anything like this on Linux? Any resources you could share that may help walk me through this?

If you don't already know how to do it, it's...not quite so simple. After copying over the OS files, you must:

1) Modify /etc/fstab - the "/" entry in particular. Specifying the device by UUID is typically the most robust option.

2) Use something like update-grub while still booted in the old system to create new boot entries to let you boot into the new install. I'm familiar with how to do this in Debian and Ubuntu based linux distributions. You have not specified what you're using.

3) Reboot and use the new boot entry to boot into your new system

4) Do some stuff to fix up /boot because it will be all messed up. Find/replace with UUIDs on /boot/grub/grub.cfg may be a crude temporary fix, or maybe something like update-grub will work.

5) Do a grub-install to install a new grub2 MBR bootloader pointed at the new partition instead of the old partition.

6) Reboot and hopefully it works...

Simpler still is to use a gparted liveCD to move partitions as required as suggested above. This presents a GUI picture of the disk, including unallocated space, where you can drag the partition to where it is needed to arrange free space, then enlarge others as required.
It resizes the filesystem as well as the partition once you click the "Apply changes" button. Very professional piece of work.

Edit: note I was referring to post #5 - this and the prior post crossed in flight.