General answer
(This part was written before the OP revealed the exact partition table.)
Partitions and filesystems are different concepts. Windows often makes a misleading impression they are equivalent but they are not. (Shame on you Windows.)
A partition is just a part of a larger device identified by some entry in the partition table. cfdisk manipulates this table. A filesystem is a structure that usually lives inside a partition (but it may live in a regular file or take the entire device).
A plausible explanation is: with cfdisk you changed the partition table (most likely moved the beginning of the relevant partition) but the filesystem is still where it was because it's not a job of cfdisk to move or resize the filesystem. It's like you changed the table of contents without changing the contents. Your computer is confused because it doesn't find the content it expects (and needs in order to boot) where the table of contents says it should be.
If changing the partition table is the only thing you did then you should change it back to exactly what it was. Compare this answer of mine about a situation where a partition table entry was destroyed and then created anew, thus allowing access to a filesystem that was there all the time.
Changing the partition table back to exactly what it was may not be easy if you haven't made a backup or notes. There are tools (e.g. testdisk) able to scan a disk, find what looks like a filesystem and try to fix the partition table.
If the altered partition was the first partition on the disk then it's possible it used a common value for its starting sector:
- 2048 for 512-byte logical sector size;
- or 256 for 4096-byte logical sector size;
- or 63 for 512-byte logical sector size and quite old Windows (this value should not appear in modern setups).
Manipulating only a partition table should be safe, unless there was a partition table in MBR only and you try to create GPT (or already did). A sane setup places partitions so they don't overlap with the partition table; your old layout was like this for sure. MBR is at the beginning of the disk; GPT needs more space near the beginning and it needs space at the end; so writing a GPT where only MBR used to be may corrupt some data (e.g. a bootloader near the beginning and/or a filesystem at the end). Hopefully you did not change from MBR to GPT. While trying to restore the old partition table you should restore its old type.
With my experience I think I could possibly handle the situation if I knew exactly what changes you made. Without experience a sane procedure is:
If you have means (spare disk space) and time, copy the entire disk to another disk or to a regular file just in case. In Linux this can be as easy as sudo cp /dev/sdx /target-device-or-file. Many sites advise dd; I would use ddrescue in case read errors are going to appear:
sudo ddrescue -b $N /dev/sdx /target-device-or-file /path/to/mapfile
where $N is the physical sector size of the disk in question (512 or 4096) and /dev/sdx is the said disk.
Use testdisk or similar tool and try to recover a sane partition table.
After you recover a sane partition table and everything works as it used to, make room for your Linux installation by using a tool that handles partition tables and filesystems (e.g. gparted). Such tool runs more specific tools (that separately handle partitions or filesystems) in the right order (which is something users can do by hand, but rarely should). A backup (like with ddrescue) is advised before you start.
If for whatever reason you cannot bring the partition table and the whole setup to a sane state then you will probably still be able to recover at least some files. See How do I recover lost/inaccessible data from my storage device?
Specific approach
(This part is a try to fix the specific partition table added to the question.)
The third partition on the device is indeed smaller than it can be. After it there's a gap (unassigned space) from the sector number 210282496 to (and including) 998166527. This confirms your claim that you shrunk it.
The best thing to try is to set the end sector of the 3rd partition to exactly 998166527, so there is no gap between the 3rd and the 4th partition. The new size should be exactly 997599232 sectors. cfdisk should allow you to specify the size in sectors with the S suffix.
I'm almost certain this used to be the number. But even if not, it couldn't have been higher. Setting a partition larger than its filesystem will still work, unless the filesystem doesn't start where the partition starts (and this is not the problem here) or partitions overlap. 998166527 is the largest number you can set so partitions don't overlap.
The header of the filesystem contains information about the size of it. In the current situation the partition is too small to what the header says, so any sane tool will say there is no proper filesystem there.
If the partition is just right or larger, the information from the header will be in effect and the filesystem will be recognized. Therefore you should set the highest possible end sector number in case the filesystem is maximally big. This number will also work with a smaller filesystem. But most likely your filesystem is as big as it could be.
So it's safe to set the size to 997599232 sectors. Try it. Before you write the changes, double check if the new end sector for the 3rd partition is 998166527 and no other start or end sector changed.
