You've hosed your system; I hope you have backups. If not, I have some recovery suggestions later. First, though, I want to point out your mistakes so you don't repeat them....
My 14.04 was complaining of 0 bytes on /boot, so I went in and done a sudo apt-get remove linux-headers-3.2.0.2* since there was already a linux-headers-3.2.0.30 available (I wanted to remove all but current to free up that space and stop the system complaining). I've since found out this is a terrible idea.
The linux-headers package (actually, linux-headers-3.13.0-45-generic or something similar) doesn't contain files in /boot; it holds header files used by programmers to write programs that interact with the kernel. Most of its files go in the /usr/src directory tree. An ordinary user might not need them, although they're probably pulled in by dependencies. The point is that deleting linux-headers was probably harmless and would not have helped you recover space in /boot.
The kernel itself comes from a package called linux-image, not linux-headers. If you removed that package (including all versions of it; you might have two or more kernels installed at once), then the computer would stop booting. I don't know offhand if Boot Repair would be able to fix this. Re-installing GRUB would be useless. You'd need to boot an emergency system and re-install the linux-image package. You might also need to reconfigure (but not re-install) GRUB.
since my ext4 is an LVM and I hadn't run the Live Disc in UEFI mode, the Boot Repair program asked me to add a bios_grub flag to the /dev/sda3, which I did (which removed the LVM flag).
This is your first very serious mistake. The "bios_grub flag" is a partition type code that tells GRUB it may use the partition to store part of itself, without going through any filesystem or LVM on the partition. Thus, once you made this change and re-installed GRUB, GRUB overwrote the first few sectors of your LVM. Most of the LVM's data were still intact, and it's conceivable you could have recovered at this point, although it might have been tough. But then....
I reset the flag to LVM and reset the filesystem to ext4 using mkfs.ext4 /dev/sda3.
If letting GRUB write itself to the first sectors of the LVM partition was throwing the data in the trash, this action was the sanitation workers hauling your trash away. The mkfs utility (and all its "helpers," like mkfs.ext4) does not simply tell Linux what the filesystem type is, as you seem to think; it writes new low-level filesystem data to the disk. This is sort of like painting over a sheet of paper so you can re-use it.
Your best chance of recovery at this point is if you've got good backups. If so, I recommend you re-install Ubuntu from scratch and restore your personal data from the backups.
If you don't have backups, there's still a chance you can recover something, but it will be difficult -- sort of like going to the city dump and sifting through the trash to find your stuff. The procedure is:
- Do a low-level backup of the disk, as in
sudo dd if=/dev/sda of=/path/to/lots/of/disk/space/sda-backup.img. You'll need a second disk that's larger than the original, available at /path/to/lots/of/disk/space, in which to store the backup. The point of this is to have a recovery option in case you make more mistakes, which are very likely at this point -- some of the following actions could make matters worse, and there's no way around that.
- Use
gdisk to delete the partitions on the original disk.
- Use TestDisk to try to locate your original ext4 filesystem and build a new partition around it. Note that, AFAIK, TestDisk doesn't know about LVM, but there's a good chance that it can create a "raw" (non-LVM) partition around the filesystem, provided you didn't grow your filesystem after creating it. Note that TestDisk will probably discover the filesystem you created that overwrote the original, but because you used LVM originally, the new filesystem didn't begin at the same point as the original, and the critical data structures will be offset compared to one another, so TestDisk might be able to find enough of the original filesystem to access it.
- If TestDisk was successful, run
fsck on the resulting partition. Chances are it will encounter errors and you'll have to help it recover. Many files will be damaged. I'd be shocked if you could boot from that OS, but it might be intact enough to recover at least some of your personal files.
- If TestDisk was unsuccessful, use PhotoRec to try to recover individual files. This will be a painful process, since you'll need to review every file to figure out what it is.
It's possible that TestDisk or fsck will actually do further damage. If you suspect this has happened, you can restore your backup.
Best of luck with your recovery. When you're done, use the new disk you've bought to back up your system regularly.
