Between them, AFH and Romeo Ninov basically have the answer, but it needs to be bundled together.
/boot partition is separate because this is essentially required for use of LVM (which is not a filesystem, but a container for logical volumes, which themselves contain filesystems). An LVM partition can be resized; see here for an outline of what's required. I'm not sure I'd go there, though....
You report that your update process is complaining about insufficient space in your 244 MiB
/boot partition, but that partition is currently only 52% used. Distributions that routinely create separate
/boot partitions usually make them about twice as big as yours, but it's still odd that your updates would try to nearly double the amount of space used there. The Ubuntu 14.04 installation on which I'm typing this uses just 80 MiB on
/boot. You may therefore want to check what's there. Type
ls -lh /boot. Here's what I see on my system:
$ ls -lh /boot
-rw-r--r-- 1 root root 1.2M Feb 14 17:06 abi-3.13.0-45-generic
-rw-r--r-- 1 root root 1.2M May 4 01:09 abi-3.13.0-52-generic
-rw-r--r-- 1 root root 162K Feb 14 17:06 config-3.13.0-45-generic
-rw-r--r-- 1 root root 162K May 4 01:09 config-3.13.0-52-generic
drwxr-xr-x 10 root root 4.0K Dec 31 1969 efi
drwxr-xr-x 3 root root 1.0K May 7 11:30 extlinux
drwxr-xr-x 5 root root 1.0K Mar 12 20:08 grub
drwxr-xr-x 2 root root 1.0K Feb 14 17:06 grub.bak
-rw-r--r-- 1 root root 20M Feb 26 18:39 initrd.img-3.13.0-45-generic
-rw-r--r-- 1 root root 20M May 7 11:28 initrd.img-3.13.0-52-generic
drwx------ 2 root root 12K Feb 14 17:05 lost+found
-rw-r--r-- 1 root root 173K Feb 14 17:06 memtest86+.bin
-rw-r--r-- 1 root root 174K Feb 14 17:06 memtest86+.elf
-rw-r--r-- 1 root root 175K Feb 14 17:06 memtest86+_multiboot.bin
-rw-r--r-- 1 root root 227 Feb 14 17:06 refind_linux.conf
-rw------- 1 root root 3.3M Feb 14 17:06 System.map-3.13.0-45-generic
-rw------- 1 root root 3.3M May 4 01:09 System.map-3.13.0-52-generic
-rw------- 1 root root 5.6M Feb 14 17:06 vmlinuz-3.13.0-45-generic
-rw-r--r-- 1 root root 5.6M Feb 19 21:38 vmlinuz-3.13.0-45-generic.efi.signed
-rw------- 1 root root 5.6M May 4 01:09 vmlinuz-3.13.0-52-generic
-rw-r--r-- 1 root root 5.6M May 10 21:36 vmlinuz-3.13.0-52-generic.efi.signed
That's fairly typical (although with a little more than some systems would have). If you see more files of different types than I've shown here, it's possible that something has added something new and extraneous, and such files might be a candidate for removal -- but if you don't understand them, ask for advice before deleting them.
Another thing to check for is extraneous kernels. These are the files with names that begin with
vmlinuz. (They're paired with
initrd.img files, for which AFH had you search.) My own example shows four kernel files, but these are really signed and unsigned versions of just two kernels. If you see more than three kernel versions (each of which may be available in signed and unsigned form), try the following command:
sudo apt-get autoremove
This command should remove all but the original and two most recent kernels from your system, which should clear up some space.
If you do have to resize partitions, it might be safer to shrink your EFI System Partition (ESP;
/dev/sda1 in your case) and expand
/boot into that space than to mess with your LVM setup. I wouldn't recommend resizing by more than about 200 MiB, and you should definitely back up both partitions on removable media before you proceed, because both partitions are critical to booting, so if something goes wrong, you'll be in deep trouble. Also, be aware that some EFIs can be finicky about the FAT filesystems on their ESPs. A few (mostly older EFIs, from before 2012) will react badly to a FAT32 ESP that's smaller than 512 MiB. Thus, if you try resizing in this way, start by shrinking the ESP, then do a test boot. If you can boot, expand
/boot into the freed space and try booting again. If you have problems after shrinking the ESP, use an emergency system to expand it back to its original size.