Fedora 20 Post-Upgrade: /boot Partition is Almost Full

Question

I just recently upgraded one of my boxes from F18 to F20 which went very smooth (using fedup). However, now my /boot partition is almost full:

/dev/sda2                477M  436M   12M  98% /boot

The FC18 specific contents can be seen below:

[root@local-dev boot]# ls -hal | grep fc18
root root 129K Dec  2 14:35 config-3.11.10-100.fc18.x86_64
root root 129K Dec  2 14:23 config-3.11.10-100.fc18.x86_64.debug
root root 129K Nov  4 09:14 config-3.11.7-100.fc18.x86_64
root root 129K Nov  4 09:05 config-3.11.7-100.fc18.x86_64.debug
root root 129K Nov 20 15:29 config-3.11.9-100.fc18.x86_64
root root 129K Nov 20 15:17 config-3.11.9-100.fc18.x86_64.debug
root root  36M Dec 13 18:23 initramfs-3.11.10-100.fc18.x86_64.debug.img
root root  35M Dec 13 18:25 initramfs-3.11.10-100.fc18.x86_64.img
root root 7.7M Dec 13 18:28 initramfs-3.11.10-100.fc18.x86_64kdump.img
root root  36M Nov 13 15:24 initramfs-3.11.7-100.fc18.x86_64.debug.img
root root  35M Nov 13 15:23 initramfs-3.11.7-100.fc18.x86_64.img
root root 7.7M Nov 13 15:36 initramfs-3.11.7-100.fc18.x86_64kdump.img
root root  36M Dec  1 20:35 initramfs-3.11.9-100.fc18.x86_64.debug.img
root root  35M Dec  1 20:33 initramfs-3.11.9-100.fc18.x86_64.img
root root 7.7M Dec  1 20:55 initramfs-3.11.9-100.fc18.x86_64kdump.img
root root 2.6M Dec  2 14:35 System.map-3.11.10-100.fc18.x86_64
root root 2.8M Dec  2 14:23 System.map-3.11.10-100.fc18.x86_64.debug
root root 2.6M Nov  4 09:14 System.map-3.11.7-100.fc18.x86_64
root root 2.8M Nov  4 09:05 System.map-3.11.7-100.fc18.x86_64.debug
root root 2.6M Nov 20 15:29 System.map-3.11.9-100.fc18.x86_64
root root 2.8M Nov 20 15:17 System.map-3.11.9-100.fc18.x86_64.debug
root root 5.0M Dec  2 14:35 vmlinuz-3.11.10-100.fc18.x86_64
root root 5.5M Dec  2 14:23 vmlinuz-3.11.10-100.fc18.x86_64.debug
root root  174 Dec  2 14:23 .vmlinuz-3.11.10-100.fc18.x86_64.debug.hmac
root root  168 Dec  2 14:35 .vmlinuz-3.11.10-100.fc18.x86_64.hmac
root root 5.0M Nov  4 09:14 vmlinuz-3.11.7-100.fc18.x86_64
root root 5.5M Nov  4 09:05 vmlinuz-3.11.7-100.fc18.x86_64.debug
root root  173 Nov  4 09:05 .vmlinuz-3.11.7-100.fc18.x86_64.debug.hmac
root root  167 Nov  4 09:14 .vmlinuz-3.11.7-100.fc18.x86_64.hmac
root root 5.0M Nov 20 15:29 vmlinuz-3.11.9-100.fc18.x86_64
root root 5.5M Nov 20 15:17 vmlinuz-3.11.9-100.fc18.x86_64.debug
root root  173 Nov 20 15:17 .vmlinuz-3.11.9-100.fc18.x86_64.debug.hmac
root root  167 Nov 20 15:29 .vmlinuz-3.11.9-100.fc18.x86_64.hmac

I am pretty confident, but I haven't been able to find a straight answer on Google yet, but I can safely delete these files now, correct?

Thanks for your time and insight.

Regards,

Answer 1

The simple solution (Linux distro agnostic) is to cd /boot && ls -hl. Read through the output and remove any old kernel files. In my case, the most recent kernel was 3.14., so I sudo rm config-3.11* and removed the other 3.11 kernel files. This freed up about 280 MB from the /boot partition.

Now she's working beautifully again.

If you are running a Debian-base distro you will need to look for the linux-image* files in /boot, but on CentOS / Fedora / RHEL the files to be removed are as follows:

Note: Use uname -a to find out your current kerenl version (ex. output: Linux local-dev 3.14.2-200.fc20.x86_64 #1 SMP Mon Apr 28 14:40:57 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux, so my current kernel version is 3.14.2).

sudo rm vmlinuz-3.{old kerenel version}*

sudo rm config-3.{old kernel version}*

sudo rm System.map-3{old kernel version}.*

And, once you reboot, voila you are good to go!

WARNING: Modifying the /boot partition can easily bork your system. Proceed with caution and only use the above commands if you know what they do, and what you are doing when you execute them!