Why is my root partition displaying as full in gparted?

Question

I know a little about file systems but not very much. I only have a general idea of what LVMs are, although apparently that is what I am using as my root partition.

I have a single 1TB hard drive in my computer. I run Ubuntu 14.04.

I went to install some updates today and was informed that I don't have enough space in by /boot partition.

I went to free up some space with the gparted GUI from a live CD, but I noticed that my root file system is displayed as being full:

According to df however:

Filesystem                  1K-blocks     Used Available Use% Mounted on
/dev/mapper/ubuntu--vg-root 954367812 10720604 895145040   2% /
none                                4        0         4   0% /sys/fs/cgroup
udev                          2995912       12   2995900   1% /dev
tmpfs                          608016     1312    606704   1% /run
none                             5120        0      5120   0% /run/lock
none                          3040072    17312   3022760   1% /run/shm
none                           102400       52    102348   1% /run/user
/dev/sda2                      241965   118221    111252  52% /boot
/dev/sda1                      523248     3428    519820   1% /boot/efi
tmpfs                         3040072        4   3040068   1% /var/lib/polkit-1/localauthority/90-mandatory.d

Whats up with this? Why does gparted think my partition is full?

---

I also have an additional question. Does anyone know know what the difference between the /boot/efi and the /boot partitions are and If I need both of them?

Answer 1

Between them, AFH and Romeo Ninov basically have the answer, but it needs to be bundled together.

Your /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
total 70M
-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.

Answer 2

I find the results from gparted and df differ, but not to this extent: I suspect gparted is misinterpreting your lvm2 contents.

Your problem is that /boot is mounted on a separate, 0.25GB drive, and this is what is running out of space. I'm not sure how you got into this state, or how to get out of it: perhaps grub doesn't boot very well from lvm2 file-systems.

The simplest thing to do first is to remove all kernels except the current and previous (you will never need more than one back-up kernel). Type:

ls -l /boot/initrd*
uname -a

This will show all the installed kernel releases and your running kernel. Then you need to remove all but the last two. I prefer to use synaptic for this: select Installed and in the search box set in turn the numeric part of each of the releases you want to remove, then type Ctrl-a to select all, and right-click and select Mark for Complete Removal (making absolutely sure that you do not remove your current release!). After going through through each of the kernels to be removed, click Apply.

On Ubuntu 15.04 with two kernels installed, my /boot directory is just over 120MB in size, so you should have room for two releases while you install a third on your /dev/sda2 (and remember to remove the oldest release every time you do this).

If this doesn't solve your problem, then you have two options:-

1. Increase the size of /dev/sda2 by moving the boundary between it and /dev/sda3.
2. Search the internet for grub lvm2, and follow the advice there.

To answer your ancillary question, /boot is where the kernel boot files reside, and this is normally within the same file-system as /, but grub needs to identify where the EFI boot files reside, and this is done by mounting the EFI boot partition in /boot/efi. In other words, /boot/efi is the mount point for a separate file-system, but it is unusual for /boot itself to be a mount point. You need both, unless you are booting using a legacy BIOS.

Answer 3

Because on the screen you see PV (physical volume), not filesystem. And entire pv is assigned to vg. Executing

df

you will see the status of filesystem