0

I have run out of inodes (IUse% = 100%) and when I run the command from this answer, /usr/src contains the largest number of files (linux-headers*). Based on this answer, I want to remove the old linux-headers but I am confused as to which are the oldest/unused.

The contents of /usr/src/linux-headers* is:

linux-headers-3.13.0-24
linux-headers-3.13.0-24-generic
linux-headers-3.13.0-33
linux-headers-3.13.0-33-generic
linux-headers-3.13.0-34
linux-headers-3.13.0-34-generic
linux-headers-3.13.0-37
linux-headers-3.13.0-37-generic
linux-headers-3.13.0-39
linux-headers-3.13.0-39-generic
<snip>
linux-headers-3.13.0-112
linux-headers-3.13.0-112-generic
linux-headers-3.13.0-113
linux-headers-3.13.0-113-generic

uname -r gives 3.13.0-34-generic

Which headers can I safely delete (using sudo rm -rf /usr/src/linux-headers-3.13.0-x*)?

If I am running 3.13.0-34, are 3.13.0-37 through 3.13.0-113 newer or am I misunderstanding the number sequence?

Community
  • 1
Bernmeister
  • 1,231
  • Check the date on the files. – Rinzwind Mar 31 '17 at 12:50
  • Using ls -l11 /usr/src gives linux-headers-3.13.0-113-generic and linux-headers-3.13.0-113 as the most recent. But does that mean I am using that version given uname -r gives 3.13.0-34-generic. – Bernmeister Mar 31 '17 at 13:08

2 Answers2

2

Don't rm -rf the headers; remove headers by the package name; for example, using sudo apt-get remove linux-headers-3.13.0-24

You can generally remove headers on kernels that you are not using. You should however be running the latest kernel, that is, the one with the highest number, in your case that would be 3.13.0-113-generic. Perhaps re-running sudo update-grub will ensure that the latest kernel is the first one being booted.

Colin Ian King
  • 18,820
  • I tried sudo update-grub (and update-grub2) and I see two kernels: 3.13.0-33-generic and 3.13.0-34-generic. No mention of 3.13.0-113-generic. So am I running 113 or 34? Also I am unable to run apt-get as I am out of disk space, so I think all I can do is rm -rf. – Bernmeister Mar 31 '17 at 13:20
  • ls /boot should show if you have a vmlinuz for 3.13.0-113 - if not, perhaps you may need to re-install it using something like; sudo apt-get install --reinstall linux-image-3.13.0-113-generic – Colin Ian King Mar 31 '17 at 13:49
  • Nope, no 113, just 33/34. Am unable to run any apt-get command - out of disk space! – Bernmeister Mar 31 '17 at 13:55
  • Ah, that's not so good. I suspect you may need to find some large files and remove them, e.g. top 100 largest files: sudo find / -printf '%s %p\n'| sort -nr | head -100 – Colin Ian King Mar 31 '17 at 14:04
  • This problem occurs on my root partition, so I'm not sure what is safe to delete; besides I assume I'd have to use apt-get to remove stuff anyway...and I can't run apt-get! With regard to the headers, I thought about moving one (or more) to another partition so I can then run apt-get to remove other headers. Do you know if the headers which are not 33/34.113 are being used (and so are safe for moving and eventual apt-get remove/purge)? – Bernmeister Mar 31 '17 at 22:43
0

I could not get a definite answer on which linux-headers are safe to remove, so I took an educated gamble and decided, given that I am running 3.13.0-33-generic and 3.13.0-34-generic and 3.13.0-113-generic is the most recent, the other linux-headers are candidates for toasting.

I sudo mv linux-headers-3.13.0-70* through linux-headers-3.13.0-79* to another partition. That freed up enough inodes down to about 90% usage.

Then sudo apt-get purge linux-headers-3.13.0-37* through to linux-headers-3.13.0-49* and that freed up a lot more inodes. I could then continue my install (ironically the latest kernel). I rebooted and all appears well.

Then sudo mv linux-headers-3.13.0-70* through linux-headers-3.13.0-79* back to /usr/src and did the same sudo apt-get purge as above.

During both lots of the purge I got the warning:

dpkg: warning: while removing linux-headers-3.13.0-70-generic, directory '/lib/modules/3.13.0-70-generic' not empty so not removed

which I suspect is relevant to VirtualBox and so hopefully is not a drama in the future when VirtualBox updates...

Footnote: Found a bug report with respect to this issue.

Bernmeister
  • 1,231