0

This question already has an answer here:

I am not so into Linux and I have the following problem related to the fact that my /boot partition seems to be full and it seems to cause a problem trying to install a program.

I try to explain in detail my doubts because I am not so into system engineering (I am a software developer).

1) Performing the lsblk statment lists information about all available or the specified block devices.

Empirically I think that it should show the list of all the partitions/mounted disks or something like this. What exactly means with the terms block devices?

So if I perform this statment on my Ubuntu system I obtain:

root@MyServer-VPS:~# lsblk
NAME           MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
fd0              2:0    1    4K  0 disk
sda              8:0    0   20G  0 disk
├─sda1           8:1    0  476M  0 part /boot
├─sda2           8:2    0    1K  0 part
├─sda3           8:3    0   10G  0 part
│ └─vg-lv_root 252:0    0 18.6G  0 lvm  /
└─sda5           8:5    0  9.5G  0 part
  ├─vg-lv_root 252:0    0 18.6G  0 lvm  /
  └─vg-lv_swap 252:1    0  952M  0 lvm  [SWAP]
sr0             11:0    1 1024M  0 rom

So what is the difference between disk, part (it should be a partition of the parent disk), lvm and rom?

A specific partition is boot, this one:

sda1           8:1    0  476M  0 part /boot

that is a sda disk partition.

From what I know it should contains the Linux Kernel downloaded versions. Is it?

Ok, the mount point is /boot so I think that it is the /boot directory into my system (is it?), this is the content:

root@MyServer-VPS:/boot# ls
abi-4.4.0-21-generic  config-4.4.0-21-generic  grub                         System.map-4.4.0-21-generic  vmlinuz-4.4.0-21-generic
abi-4.4.0-31-generic  config-4.4.0-31-generic  initrd.img-4.4.0-21-generic  System.map-4.4.0-31-generic  vmlinuz-4.4.0-31-generic
abi-4.4.0-34-generic  config-4.4.0-34-generic  initrd.img-4.4.0-31-generic  System.map-4.4.0-34-generic  vmlinuz-4.4.0-34-generic
abi-4.4.0-38-generic  config-4.4.0-38-generic  initrd.img-4.4.0-34-generic  System.map-4.4.0-38-generic  vmlinuz-4.4.0-38-generic
abi-4.4.0-42-generic  config-4.4.0-42-generic  initrd.img-4.4.0-38-generic  System.map-4.4.0-42-generic  vmlinuz-4.4.0-42-generic
abi-4.4.0-45-generic  config-4.4.0-45-generic  initrd.img-4.4.0-42-generic  System.map-4.4.0-45-generic  vmlinuz-4.4.0-45-generic
abi-4.4.0-47-generic  config-4.4.0-47-generic  initrd.img-4.4.0-45-generic  System.map-4.4.0-47-generic  vmlinuz-4.4.0-47-generic
abi-4.4.0-51-generic  config-4.4.0-51-generic  initrd.img-4.4.0-47-generic  System.map-4.4.0-51-generic  vmlinuz-4.4.0-51-generic
abi-4.4.0-53-generic  config-4.4.0-53-generic  initrd.img-4.4.0-51-generic  System.map-4.4.0-53-generic  vmlinuz-4.4.0-53-generic
abi-4.4.0-57-generic  config-4.4.0-57-generic  initrd.img-4.4.0-53-generic  System.map-4.4.0-57-generic  vmlinuz-4.4.0-57-generic
abi-4.4.0-59-generic  config-4.4.0-59-generic  lost+found                   System.map-4.4.0-59-generic  vmlinuz-4.4.0-59-generic

So what these contents exactly represents? Are the differents Linux kernel versions downloaded on this system?

What are the difference between the abi-, config-, initrd.img-, System.map- and vmlinuz-4 files?

How can I detect the used kernel version?

2) Performing the df -h statment I obtain this output:

root@MyServer-VPS:~# df -h
Filesystem              Size  Used Avail Use% Mounted on
udev                    477M     0  477M   0% /dev
tmpfs                   100M   16M   84M  16% /run
/dev/mapper/vg-lv_root   19G   12G  6.3G  64% /
tmpfs                   497M     0  497M   0% /dev/shm
tmpfs                   5.0M     0  5.0M   0% /run/lock
tmpfs                   497M     0  497M   0% /sys/fs/cgroup
/dev/sda1               461M  458M     0 100% /boot
tmpfs                   100M     0  100M   0% /run/user/0

In particular I have that:

/dev/sda1               461M  458M     0 100% /boot

So it means that my /boot partition is completly full?

My problem is: can I saftly deetect delete all the old kernel version (the not used one) to free up space in the /boot ?

How can I do it?

marked as duplicate by Pilot6, mikewhatever, Jacob Vlijm, Eric Carvalho, Kevin Bowen Feb 5 '17 at 8:16

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • This is odd. Ubuntu 16.04 removes old kernels by default. Are you sure it's Ubuntu, and not one of the odd ball derivatives? – mikewhatever Feb 4 '17 at 17:47
  • 1
    @mikewhatever Ubuntu 16.04 does NOT remove any kernels unless you run apt autoremove. – Pilot6 Feb 4 '17 at 18:00
  • In my experience Ubuntu 16.04 does NOT remove old kernels by default, and there are good reasons for that discussed [here] (askubuntu.com/questions/590673/…) there are a number of ways to do [this type of maintenance] (askubuntu.com/questions/2793/…) Unfortunately there are a lot of ways to do this, and coming up with a system that works for you requires a lot reading and thought on on the subject. There should really be an agreed upon best practice for this problem. – Thompson Dawes Feb 4 '17 at 18:04
  • 1
    Autoremove will remove them all but the current, and previous kernel. – user508889 Feb 4 '17 at 18:05
  • @Pilot6: An added feature in 16.04 does the equivalent of running autoremove daily, see /etc/apt/apt.conf.d/50unattended-upgrades, near line 40. – user535733 Feb 4 '17 at 18:10
0

You can use the command :

uname -a

to see which kernel you are currently using. Then you can use the command :

dpkg -l | grep linux-image

to see which older kernels you can safely remove.

Since removing older kernels might still involve already having some free space in /boot (Yes, a catch22 situation) you could work around that by using the ">" sign to first zero out the older kernels about which you are sure you won't be using them.

For example :

sudo bash
> /boot/vmlinuz-4.4.0-59-generic
> /boot/vmlinuz-4.4.0-57-generic
exit

After this freeing up space in /boot, it becomes easier to remove older kernels with apt-get or dpkg commands.

I've used this method in the past successfully, because manually removing kernels in /boot/ with the rm command, will likely lead to problems with apt-get/dpkg if you want to use the "apt-get autoremove --purge" command.

Not the answer you're looking for? Browse other questions tagged or ask your own question.