Ubuntu 14.04- not enough room for upgrade?

[The_Eric]

I have been getting this error message for a little while now when I go to download the suggested updates. I've checked on the hard disk, and there is plenty of room there, but evidently not in the boot folder? I ran the suggested command to clean things up, but that had no effect.

Quote:

The upgrade needs a total of 81.6 M free space on disk '/boot'. Please free at least an additional 16.4 M of disk space on '/boot'. Empty your trash and remove temporary packages of former installations using 'sudo apt-get clean'.

What is going on and what do I need to do to rectify this?

 

[ClutchDisc]

How big is your HDD and how much space is being used? Also I'm wondering if your HDD could be going out - how old is it?

 

[The_Eric]

The drive is a few month old 120 gig Samsung 840 Pro SSD. Not sure how much is on there- but it shouldn't be much...

 

[ClutchDisc]

Oh ok well I would hope the SSD isn't going out! How are the partitions set up?? Could you take a screenshot of gparted and post it here?

 

[simple_gifts]

Guys, as the machine is patched and new kernels are installed, the old ones are not cleaned up. Drive size is not a consideration as the /boot partition to only 240Mb or so He has to go into the /boot partition and delete the old kernels. Read this whole thing before proceeding with any commands. It is not clear by Canonical didn't make cleanup part of the patching process. Having an old kernel handy is helpful, but not 4 of them. Open a terminal and type sudo -s cd /boot [email protected]:/boot$ df -k /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 240972 165105 63426 73% /boot There is only 63Mb left on mine. Get a listing of the files [email protected]:/boot$ ls -l total 156219 -rw-r--r-- 1 root root 1162257 Jul 4 18:18 abi-3.13.0-30-generic -rw-r--r-- 1 root root 1162712 Jul 15 00:29 abi-3.13.0-32-generic -rw-r--r-- 1 root root 1162712 Jul 29 13:41 abi-3.13.0-33-generic -rw-r--r-- 1 root root 1162712 Aug 13 12:45 abi-3.13.0-34-generic -rw-r--r-- 1 root root 165576 Jul 4 18:18 config-3.13.0-30-generic -rw-r--r-- 1 root root 165611 Jul 15 00:29 config-3.13.0-32-generic -rw-r--r-- 1 root root 165611 Jul 29 13:41 config-3.13.0-33-generic -rw-r--r-- 1 root root 165611 Aug 13 12:45 config-3.13.0-34-generic drwxr-xr-x 5 root root 1024 Aug 15 19:53 grub -rw-r--r-- 1 root root 29131950 Jul 12 18:51 initrd.img-3.13.0-30-generic -rw-r--r-- 1 root root 29201029 Jul 22 20:09 initrd.img-3.13.0-32-generic -rw-r--r-- 1 root root 29201729 Aug 12 17:06 initrd.img-3.13.0-33-generic -rw-r--r-- 1 root root 29202331 Aug 19 16:00 initrd.img-3.13.0-34-generic drwx------ 2 root root 12288 Jun 17 19:21 lost+found -rw-r--r-- 1 root root 176500 Mar 12 08:31 memtest86+.bin -rw-r--r-- 1 root root 178176 Mar 12 08:31 memtest86+.elf -rw-r--r-- 1 root root 178680 Mar 12 08:31 memtest86+_multiboot.bin -rw------- 1 root root 3378641 Jul 4 18:18 System.map-3.13.0-30-generic -rw------- 1 root root 3381262 Jul 15 00:29 System.map-3.13.0-32-generic -rw------- 1 root root 3381262 Jul 29 13:41 System.map-3.13.0-33-generic -rw------- 1 root root 3381262 Aug 13 12:45 System.map-3.13.0-34-generic -rw------- 1 root root 5792608 Jul 4 18:18 vmlinuz-3.13.0-30-generic -rw------- 1 root root 5798112 Jul 15 00:29 vmlinuz-3.13.0-32-generic -rw------- 1 root root 5798688 Jul 29 13:41 vmlinuz-3.13.0-33-generic -rw------- 1 root root 5797728 Aug 13 12:45 vmlinuz-3.13.0-34-generic The files with the "3.13.0-30" and "3.13.0-32" can be deleted on my example, since there are two other kernels available (-33 and -34) Get a listing of the files you suspect you want to delete ls *13.0-3[02]* NOTE THE * are wildcards and the [] is a substitution, meaning either 30 or 32 abi-3.13.0-30-generic initrd.img-3.13.0-32-generic abi-3.13.0-32-generic System.map-3.13.0-30-generic config-3.13.0-30-generic System.map-3.13.0-32-generic config-3.13.0-32-generic vmlinuz-3.13.0-30-generic initrd.img-3.13.0-30-generic vmlinuz-3.13.0-32-generic Those are safe to delete since we are running on the highest version. rm *13.0-3[02]* NOTE: DO NOT FAT FINGER THIS Now get another listing [email protected]:/boot# ls -l total 78417 -rw-r--r-- 1 root root 1162712 Jul 29 13:41 abi-3.13.0-33-generic -rw-r--r-- 1 root root 1162712 Aug 13 12:45 abi-3.13.0-34-generic -rw-r--r-- 1 root root 165611 Jul 29 13:41 config-3.13.0-33-generic -rw-r--r-- 1 root root 165611 Aug 13 12:45 config-3.13.0-34-generic drwxr-xr-x 5 root root 1024 Aug 15 19:53 grub -rw-r--r-- 1 root root 29201729 Aug 12 17:06 initrd.img-3.13.0-33-generic -rw-r--r-- 1 root root 29202331 Aug 19 16:00 initrd.img-3.13.0-34-generic drwx------ 2 root root 12288 Jun 17 19:21 lost+found -rw-r--r-- 1 root root 176500 Mar 12 08:31 memtest86+.bin -rw-r--r-- 1 root root 178176 Mar 12 08:31 memtest86+.elf -rw-r--r-- 1 root root 178680 Mar 12 08:31 memtest86+_multiboot.bin -rw------- 1 root root 3381262 Jul 29 13:41 System.map-3.13.0-33-generic -rw------- 1 root root 3381262 Aug 13 12:45 System.map-3.13.0-34-generic -rw------- 1 root root 5798688 Jul 29 13:41 vmlinuz-3.13.0-33-generic -rw------- 1 root root 5797728 Aug 13 12:45 vmlinuz-3.13.0-34-generic How much space is availble; now 141Mb; enough to upgrade or patch [email protected]:/boot# df -k /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 240972 87303 141228 39% /boot I HIGHLY SUGGEST YOU LET ONE OF US GUIDE YOU AS YOU POST YOUR COMMANDS. IF YOU F-FINGER YOU MAY BRICK YOUR SYSTEM.

 

[The_Eric]

Originally Posted By: simple_gifts

Guys, as the machine is patched and new kernels are installed, the old ones are not cleaned up. Drive size is not a consideration as the /boot partition to only 240Mb or so He has to go into the /boot partition and delete the old kernels. Read this whole thing before proceeding with any commands. It is not clear by Canonical didn't make cleanup part of the patching process. Having an old kernel handy is helpful, but not 4 of them. Open a terminal and type sudo -s cd /boot [email protected]:/boot$ df -k /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 240972 165105 63426 73% /boot There is only 63Mb left on mine. Get a listing of the files [email protected]:/boot$ ls -l total 156219 -rw-r--r-- 1 root root 1162257 Jul 4 18:18 abi-3.13.0-30-generic -rw-r--r-- 1 root root 1162712 Jul 15 00:29 abi-3.13.0-32-generic -rw-r--r-- 1 root root 1162712 Jul 29 13:41 abi-3.13.0-33-generic -rw-r--r-- 1 root root 1162712 Aug 13 12:45 abi-3.13.0-34-generic -rw-r--r-- 1 root root 165576 Jul 4 18:18 config-3.13.0-30-generic -rw-r--r-- 1 root root 165611 Jul 15 00:29 config-3.13.0-32-generic -rw-r--r-- 1 root root 165611 Jul 29 13:41 config-3.13.0-33-generic -rw-r--r-- 1 root root 165611 Aug 13 12:45 config-3.13.0-34-generic drwxr-xr-x 5 root root 1024 Aug 15 19:53 grub -rw-r--r-- 1 root root 29131950 Jul 12 18:51 initrd.img-3.13.0-30-generic -rw-r--r-- 1 root root 29201029 Jul 22 20:09 initrd.img-3.13.0-32-generic -rw-r--r-- 1 root root 29201729 Aug 12 17:06 initrd.img-3.13.0-33-generic -rw-r--r-- 1 root root 29202331 Aug 19 16:00 initrd.img-3.13.0-34-generic drwx------ 2 root root 12288 Jun 17 19:21 lost+found -rw-r--r-- 1 root root 176500 Mar 12 08:31 memtest86+.bin -rw-r--r-- 1 root root 178176 Mar 12 08:31 memtest86+.elf -rw-r--r-- 1 root root 178680 Mar 12 08:31 memtest86+_multiboot.bin -rw------- 1 root root 3378641 Jul 4 18:18 System.map-3.13.0-30-generic -rw------- 1 root root 3381262 Jul 15 00:29 System.map-3.13.0-32-generic -rw------- 1 root root 3381262 Jul 29 13:41 System.map-3.13.0-33-generic -rw------- 1 root root 3381262 Aug 13 12:45 System.map-3.13.0-34-generic -rw------- 1 root root 5792608 Jul 4 18:18 vmlinuz-3.13.0-30-generic -rw------- 1 root root 5798112 Jul 15 00:29 vmlinuz-3.13.0-32-generic -rw------- 1 root root 5798688 Jul 29 13:41 vmlinuz-3.13.0-33-generic -rw------- 1 root root 5797728 Aug 13 12:45 vmlinuz-3.13.0-34-generic The files with the "3.13.0-30" and "3.13.0-32" can be deleted on my example, since there are two other kernels available (-33 and -34) Get a listing of the files you suspect you want to delete ls *13.0-3[02]* NOTE THE * are wildcards and the [] is a substitution, meaning either 30 or 32 abi-3.13.0-30-generic initrd.img-3.13.0-32-generic abi-3.13.0-32-generic System.map-3.13.0-30-generic config-3.13.0-30-generic System.map-3.13.0-32-generic config-3.13.0-32-generic vmlinuz-3.13.0-30-generic initrd.img-3.13.0-30-generic vmlinuz-3.13.0-32-generic Those are safe to delete since we are running on the highest version. rm *13.0-3[02]* NOTE: DO NOT FAT FINGER THIS Now get another listing [email protected]:/boot# ls -l total 78417 -rw-r--r-- 1 root root 1162712 Jul 29 13:41 abi-3.13.0-33-generic -rw-r--r-- 1 root root 1162712 Aug 13 12:45 abi-3.13.0-34-generic -rw-r--r-- 1 root root 165611 Jul 29 13:41 config-3.13.0-33-generic -rw-r--r-- 1 root root 165611 Aug 13 12:45 config-3.13.0-34-generic drwxr-xr-x 5 root root 1024 Aug 15 19:53 grub -rw-r--r-- 1 root root 29201729 Aug 12 17:06 initrd.img-3.13.0-33-generic -rw-r--r-- 1 root root 29202331 Aug 19 16:00 initrd.img-3.13.0-34-generic drwx------ 2 root root 12288 Jun 17 19:21 lost+found -rw-r--r-- 1 root root 176500 Mar 12 08:31 memtest86+.bin -rw-r--r-- 1 root root 178176 Mar 12 08:31 memtest86+.elf -rw-r--r-- 1 root root 178680 Mar 12 08:31 memtest86+_multiboot.bin -rw------- 1 root root 3381262 Jul 29 13:41 System.map-3.13.0-33-generic -rw------- 1 root root 3381262 Aug 13 12:45 System.map-3.13.0-34-generic -rw------- 1 root root 5798688 Jul 29 13:41 vmlinuz-3.13.0-33-generic -rw------- 1 root root 5797728 Aug 13 12:45 vmlinuz-3.13.0-34-generic How much space is availble; now 141Mb; enough to upgrade or patch [email protected]:/boot# df -k /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 240972 87303 141228 39% /boot I HIGHLY SUGGEST YOU LET ONE OF US GUIDE YOU AS YOU POST YOUR COMMANDS. IF YOU F-FINGER YOU MAY BRICK YOUR SYSTEM.

Umm... Yeah. I think I'll have to attempt this another time, as I'm about done for the night. Is this something that I'll have to do periodically?

 

[simple_gifts]

Perhaps. Don't get intimidated, condensing what I have written into a one word phrase is "You have to delete some files" It is 10 seconds of work once you know what you are looking at. Sleep tight.

 

[simple_gifts]

Here is a cleaner method using the package manager (forget the tweak portion;goto the command line part) http://ubuntuhandbook.org/index.php/2013/08/remove-old-kernels-from-ubuntu-13-04-13-10/

Quote:

1.) Press Ctrl+Alt+T to open terminal for running commands. Check current running kernel version. uname -r Don’t remove this kernel! 2.) Copy and paste below command and hit run to check list of installed Kernels on your system: dpkg --list | grep linux-image 3.) Find out the kernels you want to remove, and run below command to accomplish it: Change x.x.x.x to the kernel version sudo apt-get purge linux-image-x.x.x.x-generic

 

[uc50ic4more]

This is the command I use to clear out old kernels:

Code:

$ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge

... One could also just install the synaptic package manager, search for Linux and remove all but the most recent kernels. This is why I don't have /boot as a separate partition; just a 20GB / for the OS and /home for my stuff. EDIT: removing old kernels is also trivial is you install Ubuntu Tweak: http://askubuntu.com/questions/2793/how-...p-the-boot-menu (the 3rd method in the 1st answer is for "Ubuntu-tweak")

 

[ClutchDisc]

Originally Posted By: uc50ic4more

This is why I don't have /boot as a separate partition; just a 20GB / for the OS and /home for my stuff.

Okay, now I understand why I have never had this happen to me.. Thanks!

 

[Cardenio327]

I'm just a linux newb, but would using gparted to make the /boot partition a little bit bigger work?

 

[Garak]

Originally Posted By: simple_gifts

rm *13.0-3[02]* NOTE: DO NOT FAT FINGER THIS

I love that!

Originally Posted By: uc50ic4more

$ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge

I thought I spend a lot of time in the command line, but that's inscrutable.

 

[uc50ic4more]

Originally Posted By: Garak

Originally Posted By: uc50ic4more

$ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge

I thought I spend a lot of time in the command line, but that's inscrutable.

My bash scripting is nowhere near a level where I might have come up with that monster; but this page explains what's going with it well enough: http://markmcb.com/2013/02/04/cleanup-unused-linux-kernels-in-ubuntu/

 

[simple_gifts]

Originally Posted By: Cardenio327

I'm just a linux newb, but would using gparted to make the /boot partition a little bit bigger work?

No. That would be seriously playing with fire lol. The issue is that old dereferenced stuff needs to be cleaned out. Making a bigger /boot just delays cleanup until a few more kernel patches are applied When your house fills up, few buy a bigger house, they throw stuff away..... Changing partition boundaries on a running or installed system is best left to the pro's. Making one partition larger requires another getting smaller AND also, the filesystem would need to be extended also. This can be done, but not by faint of heart. Messing with /boot should not even be a consideration on an installed system.

 

[uc50ic4more]

Originally Posted By: simple_gifts

Messing with /boot should not even be a consideration on an installed system.

+1! Remove those old kernels and you'll be in great shape. Old kernels are kept around in case a new kernel breaks something and you need to revert. Things can get a little silly on a desktop system that you've been running for a while as you may end up with several kernels; and if you've no hardware or driver issues, all but the most recent is redundant!

 

[Garak]

Originally Posted By: uc50ic4more

My bash scripting is nowhere near a level where I might have come up with that monster; but this page explains what's going with it well enough:

I usually keep one previous kernel, for the reasons you indicated. At the start of that article, that's much what I type in, expect as piped commands when I want to update. I don't bother with the autoremove too frequently. As for that monster script, well, that's the kind of thing that puts new Linux users into despair.

 

[Hokiefyd]

Are these old kernels the Linux analogy of Windows keeping various restore points when you upgrade hardware or drivers?

 

[Subdued]

sort of

 

[simple_gifts]

Originally Posted By: ClutchDisc

Originally Posted By: uc50ic4more

This is why I don't have /boot as a separate partition; just a 20GB / for the OS and /home for my stuff.

Okay, now I understand why I have never had this happen to me.. Thanks!

One might want to carefully inspect the /etc/fstab file; For mine, the /boot partition is ext2; If you don't have a separate /boot, the entire OS "might be" on a ext2 fs, which is not a logging filesystem. The chances of a corrupted filesystem is higher (not high, but higher) should the power go out. It is not clear why ext2 was chosen, since booting is supported from an ext3 or 4 fs, which are logging.

 

[uc50ic4more]

Originally Posted By: Hokiefyd

Are these old kernels the Linux analogy of Windows keeping various restore points when you upgrade hardware or drivers?

The kernel is basically the mechanism that interfaces software with hardware. In a real production environment you'd want to get a good kernel that works with your hardware and only change or upgrade that if it is absolutely necessary. I don't know, but I would guess that is why Linux OS's tend to keep them around: in case a new one breaks your system. For desktops, a typical consumer might be looking at more rapid hardware changes and therefore may see some value in keeping up to speed with kernel development (new generation of music players, new video cards and drivers, new form factors and interfaces like USB, Firewire, etc.) I have been in a few situations where I have needed a newer kernel in order to use some hardware; bit personally have only ever had to revert to an older kernel once, and only then just briefly because it was an X.org issue with that particular brand spankin' new kernel.