Ubuntu 12.04 Server No Space on /boot Partition

Updates fail because /boot partition is full. I have looked at "gparted" to see if I can resize it. I see warnings in blog groups that I could lose grub boot manager. I hear that if the /boot is the first partition, most likely I will have to restore grub. Below is my disk information:

partition 1: /dev/sda1; unknown type; size=977.00 KiB; bios_grub
partition 2: /dev/sda2; ext2; size=244.14 MiB, used=230.98 MiB, free=13.16 MiB
     (partition 2 is /boot)
partition 3: /dev/sda3; LVM2 PV; Mount Point=<hostname>; size=2.73 TiB

If I am thinking correct, partition 3 (RAID) has lots of free space. I could use gparted and shrink the left side to allow me to increase the right side of partition 2, thus increasing the /boot partition. Therefore, partition 1 will not have been touched. Consequently the grub partition will not have been disturbed.

Any advice and warning would be appreciated. Am I thinking correctly?
Who is Participating?
Adding to the point darr247, what are the contents of /boot?

Each kernel with related files usually averages below 10mb.
Install ubuntu on a usb stick. Boot to the stick, then resize.

... or just delete some of those old kernels that you will never boot anyway.
244MB should be big enough for 8 or 9 kernels and RAM images, easy...  you should pare back the number of old kernels to 3 or 4 instead of resizing /sda2, in my opinion.

The idea of keeping backup kernels is in case when they put out a new kernel something particular to your setup/hardware might cause the new kernel to not boot... in that case you can still boot the old kernel[s] by holding down the shift key during POST and making the grub menu appear, then choose one of the old kernels.

If only 1 kernel is displayed (I believe that's the default for the grub that came with Ubuntu 12.04), look for an entry named "Previous Linux Versions" and choosing that one should show you a list of all the old kernels installed.  Please let us know how many are listed there.
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

RayRiderAuthor Commented:
To: Darr247

I have attached a /boot directory list. It looks apparent by the datetimestamp which are old. Yes, I remember seeing the different versions in the grub at boot time. When the updates failed due to lack of partition space, the system failed to boot and came up to the grub screen which I normally don't see. The system would not boot until I chose one of the older versions on the grub list.

There are different filenames in the boot directory. I am assuming I can delete the ones with the smaller number. I am guessing I should delete all with the same number, i.e., abi, config, initrd, system.map and vmlinuz. As you will see on the file dump, these numbers range from 23-34. I am also assuming that 34 is the current running image.
Which kernel boots the system?
uname -a
remove the others preceding it.
apt-get remove <kernel-old>
dpkg --list | grep linux-image

Alternatively if you prefer you can use the graphical synaptic package manager to remove
unneeded versions.
If you follow the directions from arnold and determine you can boot from 3.2.0-34-generic, then I would remove


rebooting between each apt-get remove [kernel-name] run, then reinstall 3.2.0-35-generic (it failed to install because there's currently not enough room to build its 14MB RAM image).

That should leave you booting from 3.2.0-35-generic by default, with 3.2.0-32-generic, 3.2.0-33-generic and 3.2.0-34-generic as backup kernels.
RayRiderAuthor Commented:
To all:

uname -a indicated I was running on 3.2.0-33-generic. Therefore I submitted apt-get remove to all lower ones up to 3.2.0-31-generic, plus the (that one was corrupted and gave me several errors on the apt-get remove command).

I rebooted the system, holding down the shift key to bring me to grub menu. Something happened, maybe I let up key too soon, as I never got to enter the kernel to boot from to test them out. As soon as I released the shift key, the system booted. This time it booted to the highest number 3.2.0-34-generic, leaving me 32 and 33 as a backup.

As of now I am only using 34% of the boot partition. I will try another update packages to see if the 35 kernel will install. I see no reason why it shouldn't.

I have learned a lot from this coming several years ago from a Solaris background, and catching up with Linux. Thanks a million!!

RayRiderAuthor Commented:
Thanks for the solution that didn't require me to "fiddle" with resizing. Just wondering why the system doesn't remove the really old kernels, maybe keep the last two or three as backups.
RayRiderAuthor Commented:
Sorry, I should have picked the later comments as the solution. I was just trying to give the points and didn't bother to see which advice comment applied the most.
If you need, you can request attention to have the question reopened so you can choose the responses you want.

Solaris updates do not maintain prior "kernel versions" I.e. as you know the process of patching is different.

Depending on which method you use to update the system, the removal of prior kernels might be a configuration setting I.e. your current setting is to not remove prior kernels see whether it has a configuration option I.e. delete prior versions.  This way when you update/upgrade a kernel it will remove all prior to the current one while installing a new one.
RayRiderAuthor Commented:
I would like to reopen this question as I have discovered a related problem:

Here is the problem:

I have two identical Ubuntu 12.04.1 LTS servers running side by side.
I am managing both with Webmin 1.610

Server #1 is currently on 3.2.0-36-generic kernel (the latest)
Server #2 is currently on kernel

Server #1 is dynamically showing packages needing updating from the Webmin System Information screen. And,  I can accomplish the updates totally within Webmin.

Server #2 is the subject of this original question when I posted here about the /boot partition filled up. I thought I was done after correcting the /boot space problem. I thought I had fixed the problem with the update

By following the suggestions here, I removed old kernels with the apt-get remove <kernel ver> command. I now have plenty of /boot partition free space. But, I now notice that Webmin on Server #2 is not showing any package updates, whereas I know there should be some since the other server just updated the kernel to 36, accomplished from the Webmin tool.

The original problem of this post for Server #2 surfaced when Server #2 was attempting to update to kernel 35. Therefore, I feel like Server #2 should be trying to get back to kernel 35 that it had failed to update while running of of /boot space now it has free space.

In this Server #2, I have manually refreshed the package update list from Webmin. I also entered from the shell "apt-get update". The command returned several "Hit' and a few "Ign" records, but saw no messages to indicate a kernel, i.e., expecting to see kernel 35 and 36.

I am not wanting to do much more until I understand a bit more why no updates are showing up within Webmin on Server #2.

Any suggestions?
> Any suggestions?

Open a terminal/puTTY and run
$ sudo apt-get update
$ sudo apt-get upgrade

If that doesn't get them synced back together, I suggest you ask a separate question about Webmin, and besides the Linux topic area, include also the Linux Administration topic area  (just copy/paste your message from above, with a link back here to this message - http://www.experts-exchange.com/OS/Linux/Q_27995403.html ).
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.