update-initramfs should produce a more helpful error message when there isn't enough free space--or provide an automatic tool for removal of old files

[Brian Murray]

Binary package hint: initramfs-tools

When installing a kernel, /boot may become full during execution of post-installation script typically when update-initramfs is creating or updating an initrd.img file. This is resulting in kernel installation error. For example:

Setting up initramfs-tools (0.98.8ubuntu3) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
dpkg: error processing initramfs-tools (--configure):
 subprocess installed post-installation script returned error exit status 1

Ideal behavior:

Give a more helpful error message when this unfortunate situation occurs so that user can fix the broken system and keep it going.

Workaround:

As the bug reporting system forwards user to this bug report, such instructions can be given here:
https://help.ubuntu.com/community/RemoveOldKernels

[kireol (kireol)]

df -H
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 40G 13G 26G 33% /
none 1.6G 369k 1.6G 1% /dev
none 1.6G 46M 1.5G 3% /dev/shm
none 1.6G 390k 1.6G 1% /var/run
none 1.6G 0 1.6G 0% /var/lock
none 1.6G 0 1.6G 0% /lib/init/rw
/dev/sda1 96M 85M 5.7M 94% /boot
/dev/sda4 113G 71G 36G 67% /home
/home/me/.Private
                       113G 71G 36G 67% /home/me

Don't see how I'm even REMOTELY in the same bug as this one.

But since obviously nobody else cares and just randomly marks bugs as duplicate, I couldnt care less anymore either.

Why bother reporting stuff if people can't do the bare minimum.

[Brian Murray (brian-murray)]

Kireol - I selected your bug report as a duplicate of this one because of the following error message in your DpkgTerminalLog.txt file attached to your bug report.

"gzip: stdout: No space left on device
update-initramfs: failed for /boot/initrd.img-2.6.32-32-generic"

Looking at your df output /boot is on a separate partition and it in fact doesn't have much free space.

[kireol (kireol)]

I apologize. I'm having a bad day, #1. And #2 I had 2 tabs open and read
the wrong thread which was completely unrelated to mine. again, sorry.

On Thu, Jun 16, 2011 at 5:35 PM, Brian Murray <email address hidden> wrote:

> Kireol - I selected your bug report as a duplicate of this one because
> of the following error message in your DpkgTerminalLog.txt file attached
> to your bug report.
>
> "gzip: stdout: No space left on device
> update-initramfs: failed for /boot/initrd.img-2.6.32-32-generic"
>
> Looking at your df output /boot is on a separate partition and it in
> fact doesn't have much free space.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (797759).
> https://bugs.launchpad.net/bugs/798414
>
> Title:
> update-initramfs does not check for free space
>
> Status in “initramfs-tools” package in Ubuntu:
> New
>
> Bug description:
> Binary package hint: initramfs-tools
>
> When generating a new initramfs there is no check for available free
> space, subsequently its possible for update-initramfs to fail due to a
> lack of free space. This is resulting in package installation
> failures for initramfs-tools. For example:
>
> Setting up initramfs-tools (0.98.8ubuntu3) ...
> update-initramfs: deferring update (trigger activated)
> Processing triggers for initramfs-tools ...
> update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic
>
> gzip: stdout: No space left on device
> E: mkinitramfs failure cpio 141 gzip 1
> update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
> dpkg: error processing initramfs-tools (--configure):
> subprocess installed post-installation script returned error exit status
> 1
>
> WORKAROUND:
>
> Remove unused kernels using computer janitor or manually free space on
> your partition containing the /boot file system.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/798414/+subscriptions
>

[BetaMax (betabel)]

In the computer Janitor isn't the option for clean up old kernels, please check it out for this problem

[Luca Galliani (lucagallianimail)]

before sudo aptitude autoremove

[Christian Mertes (cmertes)]

Luca, what's that command? It fails for me but then there isn't much of a sentence around it to explain what you mean exactly. Did it use to work but doesn't anymore?

In any case, a solution to remove old kernels is much needed. It's tedious for those who know how to do it and an impossible task for the average Windows convert.

[Mr Mister (mstrerotic)]

this is the result of choosing automatic partitioning at install time using the seperate /tmp /home /usr etc. partitions...
I was a bit nervous using this option when it didn't let me review the partition table afterward....
I definitiley would have increased my boot partition size from 333 Mb although that really should be big enough...
I manually removed all 3.2 kernel entries from the root shell in rescue mode and then reinstalled the 3.5 with synaptic...
all is well so far but I hope I don't have to do this again as it is a bit unnerving...

[Mr Mister (mstrerotic)]

oops I meant to say...
I manually removed all 3.2 kernel entries USING the root shell in rescue mode and then reinstalled the 3.5 with synaptic...

[bunnyella79 (bunnyella79)]

installArchives() failed: Vorkonfiguration der Pakete ...
Vorkonfiguration der Pakete ...
Vorkonfiguration der Pakete ...
Vorkonfiguration der Pakete ...
(Reading database ...
(Reading database ... 5%%
(Reading database ... 10%%
(Reading database ... 15%%
(Reading database ... 20%%
(Reading database ... 25%%
(Reading database ... 30%%
(Reading database ... 35%%
(Reading database ... 40%%
(Reading database ... 45%%
(Reading database ... 50%%
(Reading database ... 55%%
(Reading database ... 60%%
(Reading database ... 65%%
(Reading database ... 70%%
(Reading database ... 75%%
(Reading database ... 80%%
(Reading database ... 85%%
(Reading database ... 90%%
(Reading database ... 95%%
(Reading database ... 100%%
(Reading database ... 243333 files and directories currently installed.)
Preparing to replace linux-image-3.5.0-25-generic 3.5.0-25.38 (using .../linux-image-3.5.0-25-generic_3.5.0-25.39_amd64.deb) ...
Done.
Unpacking replacement linux-image-3.5.0-25-generic ...
dpkg: error processing /var/cache/apt/archives/linux-image-3.5.0-25-generic_3.5.0-25.39_amd64.deb (--unpack):
 cannot copy extracted data for './boot/vmlinuz-3.5.0-25-generic' to '/boot/vmlinuz-3.5.0-25-generic.dpkg-new': failed to write (No space left on device)
No apport report written because MaxReports is reached already
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.5.0-25-generic /boot/vmlinuz-3.5.0-25-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.5.0-25-generic /boot/vmlinuz-3.5.0-25-generic
Preparing to replace libssl1.0.0:i386 1.0.1c-3ubuntu2.1 (using .../libssl1.0.0_1.0.1c-3ubuntu2.2_i386.deb) ...
De-configuring libssl1.0.0:amd64 ...
Unpacking replacement libssl1.0.0:i386 ...
Preparing to replace libssl1.0.0:amd64 1.0.1c-3ubuntu2.1 (using .../libssl1.0.0_1.0.1c-3ubuntu2.2_amd64.deb) ...
Unpacking replacement libssl1.0.0:amd64 ...
Errors were encountered while processing:
 /var/cache/apt/archives/linux-image-3.5.0-25-generic_3.5.0-25.39_amd64.deb
Error in function:
Setting up libssl1.0.0:amd64 (1.0.1c-3ubuntu2.2) ...
Setting up libssl1.0.0:i386 (1.0.1c-3ubuntu2.2) ...
Setting up linux-image-extra-3.5.0-25-generic (3.5.0-25.39) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.5.0-25-generic /boot/vmlinuz-3.5.0-25-generic
update-initramfs: Generating /boot/initrd.img-3.5.0-25-generic

gzip: stdout: No space left on device
cpio: Fehler beim Schreiben: Datenbergabe unterbrochen (broken pipe)
E: mkinitramfs failure cpio 1 gzip 1
update-initramfs: failed for /boot/initrd.img-3.5.0-25-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-extra-3.5.0-25-generic.postinst line 1010.
dpkg: error processing linux-image-extra-3.5.0-25-generic (--configure):
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency prob...

[Andy Balaam (mail-artificialworlds)]

Warning: removing kernel packages can be dangerous, and might even leave your system unable to boot, so please don't do this if you don't understand what is going on.

I fixed this on my system by removing some old kernels, that I am not using any more.

I checked what kernel I am using like this:

uname -r

This gave me a version number of a kernel I MUST NOT remove because I am using it.

Then I checked what kernels were installed like this:

sudo apt-get remove linux-<TAB>

I.e. I typed "sudo apt-get remove linux-" and pressed the TAB key twice to see a list of possible completions. I chose the linux-image-* and linux-image-extra-* packages that contained versions of the kernel that I was not running, and removed them like this:

sudo apt-get remove linux-image-3.5.0-17-generic linux-image-extra-3.5.0-17-generic linux-image-3.5.0-19-generic linux-image-extra-3.5.0-19-generic

The exact list of packages in the "remove" line might be different for you - I found it out by doing what I describe at the top.

Then I made sure the recently-downloaded kernel packages that failed to configure were ok by running:

sudo apt-get upgrade

Warning: removing kernel packages can be dangerous, and might even leave your system unable to boot, so please don't do this if you don't understand what is going on.

[Redoubts (redoubts)]

@Andy, #10
I had a very similar problem, and your solution worked for me. I do autoremove & autoclean somewhat frequently, and yet when I tried apt-get remove linux-<TAB>, I found the following on my system:

linux-firmware linux-image-3.5.0-23-generic
linux-generic linux-image-3.5.0-24-generic
linux-headers-3.5.0-23 linux-image-3.5.0-25-generic
linux-headers-3.5.0-23-generic linux-image-3.5.0-26-generic
linux-headers-3.5.0-24 linux-image-extra-3.5.0-21-generic
linux-headers-3.5.0-24-generic linux-image-extra-3.5.0-22-generic
linux-headers-3.5.0-25 linux-image-extra-3.5.0-23-generic
linux-headers-3.5.0-25-generic linux-image-extra-3.5.0-24-generic
linux-headers-3.5.0-26 linux-image-extra-3.5.0-25-generic
linux-headers-3.5.0-26-generic linux-image-extra-3.5.0-26-generic
linux-headers-generic linux-image-generic
linux-image-3.5.0-21-generic linux-libc-dev
linux-image-3.5.0-22-generic linux-sound-base

as well as 3.5.0-17 (but nothing in between that and -23), which I removed to make space.

[Haw Loeung (hloeung)]

Some other workarounds are:

1) change the compression from the default gzip. I personally use xz and the initrd image works out to be ~30% smaller.

2) change the modules included from "most" to "dep". This reduced the initrd image another 30%.

These options are changed in /etc/initramfs-tools/initramfs.conf.

[Abhisek Mukherjee (abhisek)]

One thing to suggest is from install media when kernel is loaded it uses lz compression, but when installed in HDD it uses gz compression, which is definitely bigger in size. xz or lz should be used in vmlinuz.

[Redoubts (redoubts)]

I'm link dropping a bug report into this thread since they're very related.

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/923876

is attempting to prevent the /boot partition from getting this full to begin with.
As of today (2013-03-26), the status shows 'fix implemented' in Precise, but 'pending' in Quantal.

[matl (mat.l)]

I think my boot partition was to small, because I could not resize it, "sudo apt-get autremove" solved this problem for me.

[baron_army (baron-army)]

Is anything being done about this bug? I know we want to ensure responsible kernel hygiene but this is kind of annoying.

[markling (markling)]

This error is still occuring. It appears to be preventing me adding packages through the Ubuntu Software Centre. Tried to file crash report but it said "already filed" and sent me here. Boot partition 96 per cent full. It's only a few weeks since this last happened. Lucky I've got nothing better to do all day than tinker with Ubuntu errors like I was some sort of retired computer hobbyist who doesn't need to earn a living.

Lucky in fact, that Ubuntu is only an operating system for hobbyists who don't have to earn a living and so can spend all their time tinkering with errors like retired hobbyists. I can't wait to go back to the forums to learn all about removing discarded linux images from my boot partition again! I understand why people say Windows sucks. Linux is fun!

[Fran Cool (francool50)]

Solution from mat.l on 2013-05-31 seems simple but ... how can I open a term to use it ? Alt+F1 (Maj+Alt+F1) don't work (from the "bureau" [desktop] of Raring)

[Fran Cool (francool50)]

semms OK on Raring Ringtail :
opening terminal with ctrl+alt+T
then sudo apt-get autoremove

[Tim Fisher (k2trf)]

@Andy's workaround (https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/798414/comments/10) worked for me under Raring perfectly, though I also ran an update, upgrade and dist-upgrade before another autoremove, autoclean and check.

@Haw - thank you for the additional workarounds, gzip should not be the default for this by any means.

[Enrique Latorres (enrique-7)]

Most likely is that you have a separate boot partition because you are using lvm or an encrypted filesystem. Most kernel updates add a new kernel but do not erase old versions. This way boot partition gets full. The solution is simply to uninstall unused kernel images...
if possible install aptitude, run "sudo aptitude search ~ilinux-image". This will show you the installed kernels
Just remove the older versions, keep two of the newest.
Run "sudo apt-get autoremove linux-image-3.8.0-23-generic" for each of the older kernels. Put your version here.
This should free space on boot partition...

[Ian Nicholson (imnichol)]

On 07/29/2013 06:38 PM, Enrique Latorres wrote:
> Most likely is that you have a separate boot partition because you are using lvm or an encrypted filesystem. Most kernel updates add a new kernel but do not erase old versions. This way boot partition gets full. The solution is simply to uninstall unused kernel images...
> if possible install aptitude, run "sudo aptitude search ~ilinux-image". This will show you the installed kernels
> Just remove the older versions, keep two of the newest.
> Run "sudo apt-get autoremove linux-image-3.8.0-23-generic" for each of the older kernels. Put your version here.
> This should free space on boot partition...
>
That's definitely the reason, but it's not a long-term solution. It's
not 1995, we shouldn't expect users to have to manually remove packages
just because they want an encrypted FS.

[Mark Russell (marrusl)]

@Ian,

One possible workaround for this issue is mentioned in LP bug 1062623. The suggestion is to use grub to boot the encrypted partition directly and then you don't need a separate /boot.

[Massimo Manchi (massimo-manchi)]

Hi.

I've an alert "/boot full" that is on sda1

df -H
File system Dim. Usati Dispon. Uso% Montato su
/dev/mapper/lubuntu--vg-root 57G 19G 36G 35% /
none 4,1k 0 4,1k 0% /sys/fs/cgroup
udev 1,1G 4,1k 1,1G 1% /dev
tmpfs 211M 1,1M 210M 1% /run
none 5,3M 0 5,3M 0% /run/lock
none 1,1G 1,1M 1,1G 1% /run/shm
none 105M 17k 105M 1% /run/user
/dev/sda1 239M 236M 0 100% /boot
/dev/sdb1 1,1T 717M 1,0T 1% /media/massimo/Seagate Expansion Drive

and this is the ls

ls /boot
abi-3.8.0-19-generic initrd.img-3.8.0-26-generic
abi-3.8.0-21-generic initrd.img-3.8.0-27-generic
abi-3.8.0-22-generic initrd.img-3.8.0-28-generic
abi-3.8.0-23-generic lost+found
abi-3.8.0-24-generic memtest86+.bin
abi-3.8.0-25-generic memtest86+_multiboot.bin
abi-3.8.0-26-generic System.map-3.8.0-19-generic
abi-3.8.0-27-generic System.map-3.8.0-21-generic
abi-3.8.0-28-generic System.map-3.8.0-22-generic
config-3.8.0-19-generic System.map-3.8.0-23-generic
config-3.8.0-21-generic System.map-3.8.0-24-generic
config-3.8.0-22-generic System.map-3.8.0-25-generic
config-3.8.0-23-generic System.map-3.8.0-26-generic
config-3.8.0-24-generic System.map-3.8.0-27-generic
config-3.8.0-25-generic System.map-3.8.0-28-generic
config-3.8.0-26-generic vmlinuz-3.8.0-19-generic
config-3.8.0-27-generic vmlinuz-3.8.0-21-generic
config-3.8.0-28-generic vmlinuz-3.8.0-22-generic
grub vmlinuz-3.8.0-23-generic
initrd.img-3.8.0-19-generic vmlinuz-3.8.0-24-generic
initrd.img-3.8.0-21-generic vmlinuz-3.8.0-25-generic
initrd.img-3.8.0-22-generic vmlinuz-3.8.0-26-generic
initrd.img-3.8.0-23-generic vmlinuz-3.8.0-27-generic
initrd.img-3.8.0-24-generic vmlinuz-3.8.0-28-generic
initrd.img-3.8.0-25-generic

Can I delete something to let free space or I must enlarge this space?

Macs

[markling (markling)]

Enrique:

"Most likely is that you have a separate boot partition because you are using lvm or an encrypted filesystem."

True on both counts.

LVM and encryption were offered as options in the Xubuntu installer-for-dummies. Granted, an insy bit of knowledge may be required to to summon the courage to choose such options in the installer. But there is a whole D-class of user who have been led, bovine-like, into such territory with the odd sign here and passing chatter there.

"Most kernel updates add a new kernel but do not erase old versions."

That is apparenlty so.

Software Updater is still periodically, as today, giving me the message: "The upgrade needs a total of 43.2 M free space on disk '/boot'. Please free at least an additional 1,147 k of disk space on '/boot'. Empty your trash and remove temporary packages of former installations using 'sudo apt-get clean'."

It is not beyond me to look the routine to solve this problem up on the forums again. I might even next time remember that you posted a workaround here. It is however a great inconvenience. The last thing I need from Xubuntu is any more minor glitches or loose ends that cause me to have to workaround or dowithout or getlostinforumhell. Linux seems at times like it is disappearing under a mound of minor glitches.

This one is more than an inconvenience because it stops kernel upgrades. It is as though, if your usual morning routine was, after running out of the front door with toast in your mouth and papers falling out of your sachel, to jump in your car and speed off, that every now and again when you switched the car on it would say you needed petrol but you couldn't fill up till you cleaned the carburetter. You would speed off to work, knowing that the car was faulty and wondering when you could find the mental energy to pull out the Haynes manual and go over the carburetter cleaning routine again. And all because the good person who gave you the carborettor didn't get round to quite finishing it. It's fair enough, I suppose. But it does rather limit the appeal of motor transport to people who have the time and energy to clean their carburetter periodically.

[markling (markling)]

Enrique:

I am sorry to report that your workaround does not appear to work. Looks like I may to to getlostinforumhell.

Here's what my computer said about your workaround:

user@comp:~$ sudo aptitude search ~ilinux-image
i linux-image-3.5.0-28-generic - Linux kernel image for version 3.5.0 on 64
i linux-image-3.8.0-23-generic - Linux kernel image for version 3.8.0 on 64
i linux-image-3.8.0-25-generic - Linux kernel image for version 3.8.0 on 64
i linux-image-3.8.0-26-generic - Linux kernel image for version 3.8.0 on 64
i linux-image-3.8.0-27-generic - Linux kernel image for version 3.8.0 on 64
i linux-image-extra-3.5.0-28-gene - Linux kernel image for version 3.5.0 on 64
i linux-image-extra-3.8.0-25-gene - Linux kernel image for version 3.8.0 on 64
i linux-image-extra-3.8.0-26-gene - Linux kernel image for version 3.8.0 on 64
i linux-image-extra-3.8.0-27-gene - Linux kernel image for version 3.8.0 on 64
i linux-image-generic - Generic Linux kernel image
user@comp:~$ sudo apt-get autoremove linux-image-3.5.0-23-generic
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-image-3.5.0-23-generic
E: Couldn't find any package by regex 'linux-image-3.5.0-23-generic'
user@comp:~$ sudo apt-get autoremove linux-image-3.5.0-25-generic
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-image-3.5.0-25-generic
E: Couldn't find any package by regex 'linux-image-3.5.0-25-generic'
user@comp:~$ sudo apt-get autoremove linux-image-3.5.0-26-generic
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-image-3.5.0-26-generic
E: Couldn't find any package by regex 'linux-image-3.5.0-26-generic'
user@comp:~$ sudo aptitude search ~ilinux-image
i linux-image-3.5.0-28-generic - Linux kernel image for version 3.5.0 on 64 bi
i linux-image-3.8.0-23-generic - Linux kernel image for version 3.8.0 on 64 bi
i linux-image-3.8.0-25-generic - Linux kernel image for version 3.8.0 on 64 bi
i linux-image-3.8.0-26-generic - Linux kernel image for version 3.8.0 on 64 bi
i linux-image-3.8.0-27-generic - Linux kernel image for version 3.8.0 on 64 bi
i linux-image-extra-3.5.0-28-generic - Linux kernel image for version 3.5.0 on 64 bi
i linux-image-extra-3.8.0-25-generic - Linux kernel image for version 3.8.0 on 64 bi
i linux-image-extra-3.8.0-26-generic - Linux kernel image for version 3.8.0 on 64 bi
i linux-image-extra-3.8.0-27-generic - Linux kernel image for version 3.8.0 on 64 bi
i linux-image-generic - Generic Linux kernel image

It's a precarious operation to force on a user anyway (I say that of the situtation, not your good help). The most recent kernel comes at the top of the list. The list then progresses from oldest to second most recent. I nearly deleted the most recent kernel.

[markling (markling)]

To confuse matters, when I do 'uname -r' I get: 3.8.0-27-generic. Yet the list above suggests -28 is the latest. I might easily have deleted all but -28, effectively deleting the current kernel.

This really is a horrid state of affairs. As Andy Balaam wrote: "Warning: removing kernel packages can be dangerous, and might even leave your system unable to boot, so please don't do this if you don't understand what is going on". The problem with this error is you are left with no choice.

[KevinMorse (kevin-j-morse)]

This bug is the single most frustrating aspect of managing or helping others manage Ubuntu Server installations.

I've come across probably 20 or 30 default installations of Ubuntu Server that have this problem because the new packages seem to get automatically downloaded but the old ones don't get automatically cleaned out.

Can one setup a cron job to do apt-get autoremove every day or is this bad practice?

[markling (markling)]

This is still happening.

I can't stress enough what an incredible hinderance it is to the working day when your system starts crashing and you have to do the updates but the updates won't work because you have first to remove old kernel images your OS has not cleaned up.

So I go trapsing after the instructions to do this manually again.

It looks like I have to manually remove 19 kernel images before I can install my updates and get back on with my work.

Here's the kernel images Xubuntu has left me to clean up:

---------------------------------------------------------------------------------------------------------------------------------------

~$ dpkg --list | grep linux-image
rc linux-image-3.5.0-27-generic 3.5.0-27.46 amd64 Linux kernel image for version 3.5.0 on 64 bit x86 SMP
rc linux-image-3.5.0-28-generic 3.5.0-28.48 amd64 Linux kernel image for version 3.5.0 on 64 bit x86 SMP
rc linux-image-3.8.0-19-generic 3.8.0-19.30 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
rc linux-image-3.8.0-23-generic 3.8.0-23.34 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
rc linux-image-3.8.0-25-generic 3.8.0-25.37 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
ii linux-image-3.8.0-26-generic 3.8.0-26.38 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
ii linux-image-3.8.0-27-generic 3.8.0-27.40 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
ii linux-image-3.8.0-29-generic 3.8.0-29.42 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
ii linux-image-3.8.0-30-generic 3.8.0-30.44 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
ii linux-image-3.8.0-31-generic 3.8.0-31.46 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
rc linux-image-extra-3.5.0-27-generic 3.5.0-27.46 amd64 Linux kernel image for version 3.5.0 on 64 bit x86 SMP
rc linux-image-extra-3.5.0-28-generic 3.5.0-28.48 amd64 Linux kernel image for version 3.5.0 on 64 bit x86 SMP
rc linux-image-extra-3.8.0-19-generic 3.8.0-19.30 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
rc linux-image-extra-3.8.0-25-generic 3.8.0-25.37 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
ii linux-image-extra-3.8.0-26-generic 3.8.0-26.38 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
ii linux-image-extra-3.8.0-27-generic 3.8.0-27.40 amd64 Linux kernel image for version 3.8.0 on 64 bit x86 SMP
ii linux-image-extra-3.8.0-29-generic 3.8.0-29.42 amd64 Linux kernel image for versio...

[markling (markling)]

The name of this error is unhelpful.

"update-initramfs should produce a more helpful error when there isn't enough free space"

It should be:

"software updater preventing installing updates by rubbish heap of old kernel images"

or

"ubuntu should clean up its discarded kernel images automatically because they stop software updates from working"

[markling (markling)]

So here's the scenario:

. Thunar crashed out again when I was in the middle of some work.
. Software upates have been waiting for a week because they won't install until I manually remove my operating system's discarded kernel images
. So I stop work to install the updates but there are 19 discarded kernel images
. I need to remove each of these 19 kernel images by hand
. Work is really pressured at the moment. I can't spare the time
. I don't have a choice because the updates won't install and Thunar keeps crashing.

[PiG Pong (pig-c)]

"sudo apt-get autoremove" works for me.

Thanks!

[Redoubts (redoubts)]

Note that the autoremove trick won't work for kernels installed before a fix was released.
https://bugs.launchpad.net/ubuntu/precise/+source/aptitude/+bug/923876/comments/45

You can make the tedium of manual removal slightly easier with curly-braces. The following would expand into several packages:
apt-get remove linux-image-extra-3.8.0-{19,23,24,25,etc.}-generic # please verify numbers before running

Also note that you have a few 3.5 kernels (eg 3.5.0-28-generic) along with your 3.8 kernels, which may appear to be newer, even thought they are less relevant now.

It's a shame they placed your carburetor behind the timing belt.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[David Burrows (d-m123)]

I need help with Ubuntu and Skip ,downloads etc.

[Andreas Kostyrka (andreas-kostyrka)]

@Mark Russell:

Does booting via grub from an encrypted filesystem include handling lvm (including multiple PVs), raid devices, and so on?

[Mick (4mer-sin-r)]

I'm kinda new at this. Do I understand you to be saying that, in order to free up space on my hdd, I can safely delete such items from my /boot file as abi 3.11.0-17-generic and abi 3.11.0-19-generic if abi 3.11.0-24-generic has been installed?

[T Gates (tgates-t)]

Don't delete them all just a few of the oldest ones. It will only free space for your /boot ..
df- H will show /boot free space. Once you free up some room on the /boot you can run "sudo apt-get autoremove"

[Bill Meier (wmeier)]

I don't know which kernals are okayu to delete. I have had update problems before where I was told to delete old, or unused kernals. I would do this if I could tell which ones to delete.

[Jonathan Harker (jesusaurus)]

Is there a reason update-initramfs can't calculate it's needed space and compare with available space before trying to make an initrd image?

[Richard Hansen (rhansen)]

User kamalwanas recently vandalized this bug by changing the status from confirmed to fix released, but I can't seem to change it back. I was able to revert the vandalism by abnercontreras11 (change the package back to initramfs-tools).

[LanceZ (lance-zimmerman)]

I have over 400GB free, so no I'm not low on disk space.

[Bill Meier (wmeier)]

Lance,

I found that the installation creates a 241 meg partician that is a
mirror of the /boot directory. That is what gets filled up. I finally
gave up trying to make more space and reinstalled the system. I am not
Ubuntu literate enough to figure out the command line instructions.

You would think they would create the larger space during the install if
this becomes a problem. I like and use Ubuntu all the time and have
recommended it to friends who are not as computer literate as myself.
They will not be able to fix this themselves.

I have multiple hard drives, internal and external on my computer, so
nothing on the drive containing the operating system is really
important. All data is stored on other drives. starting over fresh is a
pain in the butt, but put the problem off until The space is used up again.

Bill

On 02/19/2015 02:38 AM, LanceZ wrote:
> I have over 400GB free, so no I'm not low on disk space.
>

[Dr. Horst Armbruster (harmbruster)]

Bug Confirmed! to persist through several updates.
I learned programing on an Altair, used DEC computers and decided recently not to use Windows any more on my personal computers due to the mess the constant updating of MS Windows 8.1 created for the use of an HP printer. I unpluged an Ethernet cable on a computer running National Instruments' LabView to prevent it from being updated automatically. If Ubuntu cannot update Ubuntu for whatever reason I just shall buy an Apple computer for my private use.

Horst Armbruster

[Glendon Gross (gross-clones)]

I stumbled across this bug after purchasing a used Dell PowerEdge 2850 and installing Ubuntu 14.04 server. I've been building kernels for years and so I downloaded kernel 3.13.11 from ftp.kernel.org and built a new kernel and a new set of modules. But update-initramfs failed do to lack of space in /boot. I did install with lvm enabled, and the size of /boot that was created is 240 megs (240972 1K blocks.) This was fine until I built and installed new modules. So the way I fixed it was by moving the old initrd.img-3.13.0-24-generic to the / directory, and then creating a symlink. (I doubt that kernel will now boot, but it will depend how lvm handles the boot process, and I'm not very familiar with lvm yet.) Anyway, after moving the old initrd there was enough space in /boot for update-initramfs to finish successfully. Regrettably, it left me with only 198 blocks available in /boot. I am now investigating whether it is feasible to resize /boot or not. But suffice it to say that if the installation created a larger default /boot partition, many of these problems would not be reported. The new kernel is running fine, so at least I was able to recover the system.

[Mr.Gosh (mr-gosh)]

One part og the Bug is that on luks encrypted installations the /boot partition is way too small for more than 4 kernel versions...

luckily "apt-get autoremove" unsinstalls old kernels meanwhile...

affects me until today on my luks machines - so apt-get should warn about missing space for these packages und "unattended-upgrades" package should mail the admin about missing space BEFORE it tries to install these packages..

[Richard Hansen (rhansen)]

undo recent bug vandalism

[Maja Kirkeby (maja-tonnesen)]

I'm not a computer-wiz and
I had trouble installing the Tweak tool because .. gunzip had no space. The standard autoclean and autoremove was not able to help me as i had an odd dependency-issue for one of the old kernels and the return code for the preinstalled removal-program was 1 -then it tried to figure out the dependency and ... ran out of space .

After manually removing some of the older kernels and images (using remove because purge didn't work), I was able to install Tweak and remove the rest. Lovely 2 hours used on annoying kernel issues -but hey it seems solved now. And next time i have the tweak-janitor :)

/Maja

PS: Unfortunately I've restarted and cannot copy-paste the full story of issues. I hope you can make do with what I recall.

[Peter Ruibal (fmoo)]

I just go this for the fourth time in two years and finally decided to follow up.

Some questions:

Won't every Ubuntu user *eventually* hit this? Can we expect them to google around, run random junk in a terminal, and hope things go smoothly after that?

Should the install scripts just be able to uninstall old kernels on its own if it detects there's not enough space? What happens if their current kernel has a critical security vulnerability? Would they just stay vulnerable forever?

[David Gerstmann (gerstmann-david)]

Please advise as to what computer janitor program we should download that would be effective against this bug.

Sent from my MetroPCS 4G Wireless Phone

<div>-------- Original message --------</div><div>From: Peter Ruibal <email address hidden> </div><div>Date:05/23/2015 1:02 AM (GMT-08:00) </div><div>To: <email address hidden> </div><div>Cc: </div><div>Subject: [Bug 798414] Re: update-initramfs should produce a more helpful error
  when there isn't enough free space </div><div>
</div>I just go this for the fourth time in two years and finally decided to
follow up.

Some questions:

Won't every Ubuntu user *eventually* hit this? Can we expect them to
google around, run random junk in a terminal, and hope things go
smoothly after that?

Should the install scripts just be able to uninstall old kernels on its
own if it detects there's not enough space? What happens if their
current kernel has a critical security vulnerability? Would they just
stay vulnerable forever?

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/798414

Title:
  update-initramfs should produce a more helpful error when there isn't
  enough free space

Status in tools for generating an initramfs:
  Confirmed
Status in NULL Project:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: initramfs-tools

  When generating a new initramfs there is no check for available free
  space, subsequently its possible for update-initramfs to fail due to a
  lack of free space. This is resulting in package installation
  failures for initramfs-tools. For example:

  Setting up initramfs-tools (0.98.8ubuntu3) ...
  update-initramfs: deferring update (trigger activated)
  Processing triggers for initramfs-tools ...
  update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic

  gzip: stdout: No space left on device
  E: mkinitramfs failure cpio 141 gzip 1
  update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
  dpkg: error processing initramfs-tools (--configure):
   subprocess installed post-installation script returned error exit status 1

  WORKAROUND:

  Remove unused kernels using computer janitor or manually free space on
  your partition containing the /boot file system.

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions

[Daniel Oliver (oliverdanielj)]

Looks like this bug tracks a change in an error message, which is strange since most users will be very confused about why this is hitting. For instance, my hard drive has 132 of 148 gigs free (89% free). The system telling me to, "free disk space" will do little to help help clear the matter up.

It seems like there's a functionality bug occurring --- perhaps the title of the bug should be changed to reflect that?

Just my $.02.

[James Dunn (jamesbdunn)]

When transferring from Windows OS as a new Linux user, I clicked on the Ubuntu download and install button and followed the instructions. Ubuntu set up a 250Mb boot partition on a fresh flash hard drive. Two problems resulted:

1) Updates quickly filled up the boot partition and no more updates are reaching a completed status

2) The updates are not smart enough to set security settings to cleanup the boot partition before adding updates

Why the install set the boot partition to 250Mb if it needs more, I do not know.

So it appears to me as a new Linux user

[James Dunn (jamesbdunn)]

@Fran Cool - message #19

Thank You, I think :.)

I don't know what I'm doing, but used your code and it freed up some boot space.

We'll see if I can reboot my computer after I sync my dropbox.

[Sue (ladylyddie79)]

Ugh.... seriously... I really hope that a different approach can be made soon.

[Sune Woeller (sune-woeller)]

feeling amazed that the original report of this problem is from 2011 and still not fixed. How can anybody expect ubuntu to be a realistic alternative for normal desktop users? Sorry for the rant, but come on... This is unprofessional.

[Elilzabeth Maxwell (bmax524)]

how do I fix this bug?

[Bill Canaday (bill13510)]

Elizabeth,
This is not an especially long message thread and there are at least two different fixes above.

The Linux "way" of things is to request that users make at least minimal efforts to solve their own problems.

Pretty much everyone here is either an end-user or a volunteer developer. Unless you have paid for support, there - is - no "help desk".

Unlike the famous RTF manuals of yore, all of the comments above are in ordinary English.

Say one "Our Father" and count your blessings.

But, read them you must. Solving problems by educating yourself is how angels earn their wings in Linux.

Ten minutes of reading and the memorization of a single, simple, command will almost certainly solve the problem although there are two alternative methods mentioned that will DEFINITELY solve the problem at the expense of being vastly more "techy".

You will also, if you read closely, learn how to nest options within the same command so that multiple files receive the same flying fickle finger of fate with no fatal finger flinching cramps from typing the same command over again

That, alone, is worth the journey.

[Alan Burgess (z-alan-4)]

Hello Casaba,

Could you provide detailed instructions on how to resolve this issue please.

Also when will this bug be resolved?

Thanks

Alan

On 12/08/15 12:10, Csaba wrote:
> ** Project changed: null-and-void => ubuntu
>

[David Gerstmann (gerstmann-david)]

Hello Alan Burgess, my name is David. The easiest way that I have found to
deal with this problem is to go into your Terminal and type in the
following in this order (I'll try to be as specific as possible).
    sudo apt-get autoclean (that's exactly how it should look, then press
enter), next...
    sudo apt-get autoremove (then enter), again...
    sudo apt-get clean (enter)

Do this every time before you attempt to update your computer. It may be a
bit of a pain, but it'll get you to where you need to be until someone
comes up with a permanent fix or another long term supported version comes
out again. Try this and let me know how it works for you. Good luck.
    P.S., if you don't know what the terminal is, go into your dash and
simply type in the search window... "terminal", and that should come up
with what's known as the terminal emulator. Click on it and follow the
above instructions.

On Wed, Aug 12, 2015 at 1:35 PM, Alan Burgess <email address hidden>
wrote:

> Hello Casaba,
>
> Could you provide detailed instructions on how to resolve this issue
> please.
>
> Also when will this bug be resolved?
>
> Thanks
>
> Alan
>
>
>
> On 12/08/15 12:10, Csaba wrote:
> > ** Project changed: null-and-void => ubuntu
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/798414
>
> Title:
> update-initramfs should produce a more helpful error when there isn't
> enough free space
>
> Status in initramfs-tools:
> Confirmed
> Status in Ubuntu:
> Fix Released
> Status in initramfs-tools package in Ubuntu:
> Confirmed
>
> Bug description:
> Binary package hint: initramfs-tools
>
> When generating a new initramfs there is no check for available free
> space, subsequently its possible for update-initramfs to fail due to a
> lack of free space. This is resulting in package installation
> failures for initramfs-tools. For example:
>
> Setting up initramfs-tools (0.98.8ubuntu3) ...
> update-initramfs: deferring update (trigger activated)
> Processing triggers for initramfs-tools ...
> update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic
>
> gzip: stdout: No space left on device
> E: mkinitramfs failure cpio 141 gzip 1
> update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
> dpkg: error processing initramfs-tools (--configure):
> subprocess installed post-installation script returned error exit
> status 1
>
> WORKAROUND:
>
> Remove unused kernels using computer janitor or manually free space on
> your partition containing the /boot file system.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions
>

[David Gerstmann (gerstmann-david)]

This "workaround" is not really feasible for a large percentage of Linux users because it assumes that we already know how to use, or possess, or even know what a computer janitor is; or know how to free space on our partitions. If your going to present a "workaround" at least do the due diligence of explaining how its done or provide a link to a place that does.

[David Gerstmann (gerstmann-david)]

In addition to what I said in comment #59... If what I wrote does not work for you and the other "solutions" are too complicated for your time sensitive schedules (as they are for me), then I recommend that you reinstall Ubuntu 14.04 LTS on your computer as I had to. This, I think, will clear up any "dependency" issues related to kernals. Then faithfully follow my instructions in comment # 59 above. This has worked for me so far. Occasionally the sudo apt-get process in comment # 59 seems to fail, but I've ignored those little hiccups and just tried again and once again it seems to work (fingers crossed, eyes crossed, and for Bill Canaday in comment # 57... flying fickle fingers crossed.). Until someone wiser and techier comes along, good luck fellow Ubuntu brothers and sistas.

   P.S. Please let me know how this works for you.

[Thomas A. F. Thorne (tafthorne)]

I am not sure when this problem occurred but reading over it it sounds like it pertains to a lack of space. I know that my /boot partition has run out of space several times recently. I do not know why, as I thought left the partitioning plan up to Ubuntu when I installed.

I have found that the
purge-old-kernels
script is very helpful in getting me down to just the kernel images that I am using. It might be worth performing that action too if you are low on space. I think the script will come from the main repos, so if you do not have it I expect an appropriate 'apg-get install 'prompt will be provided.

[Thomas A. F. Thorne (tafthorne)]

According to https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels the purge-old-kernels is part of the bikeshed package. To install it you will need to do:
  sudo apt-get install bikeshed
To run it you will need to do
  sudo purge-old-kernels
You can confirm if it (and any other tidying up actions) have helped by comparing the output of
  df -h
before and after you run the command. I usually see my /boot Mounted on point go from ~100% Use to ~50% Use. If you have prombles with disk space on other file-systems then
  sudo apt-get autoremove
may help you. After that I would recommend that you try running the Disk Usage Analyser program. It provides a relatively intuitive GUI that helps locate where most of your disk space is being used. It will then be up to the operator to work out what files can and cannot be removed in an attempt to free space. I would advise that you do not remove anything you do not know the source or use of. Hopefully some searching can aid in identifying where most files come from though.

[PcB Computer Support (pc-t)]

Remove unused kernels using computer janitor or manually free space on your partition containing the /boot file system.

Cant do that have no access

[aurelio76 (oskarbronski)]

Thank you.

2015-08-15 7:35 GMT+02:00 David Gerstmann <email address hidden>:

> Hello Alan Burgess, my name is David. The easiest way that I have found to
> deal with this problem is to go into your Terminal and type in the
> following in this order (I'll try to be as specific as possible).
> sudo apt-get autoclean (that's exactly how it should look, then press
> enter), next...
> sudo apt-get autoremove (then enter), again...
> sudo apt-get clean (enter)
>
> Do this every time before you attempt to update your computer. It may be a
> bit of a pain, but it'll get you to where you need to be until someone
> comes up with a permanent fix or another long term supported version comes
> out again. Try this and let me know how it works for you. Good luck.
> P.S., if you don't know what the terminal is, go into your dash and
> simply type in the search window... "terminal", and that should come up
> with what's known as the terminal emulator. Click on it and follow the
> above instructions.
>
> On Wed, Aug 12, 2015 at 1:35 PM, Alan Burgess <email address hidden>
> wrote:
>
> > Hello Casaba,
> >
> > Could you provide detailed instructions on how to resolve this issue
> > please.
> >
> > Also when will this bug be resolved?
> >
> > Thanks
> >
> > Alan
> >
> >
> >
> > On 12/08/15 12:10, Csaba wrote:
> > > ** Project changed: null-and-void => ubuntu
> > >
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/798414
> >
> > Title:
> > update-initramfs should produce a more helpful error when there isn't
> > enough free space
> >
> > Status in initramfs-tools:
> > Confirmed
> > Status in Ubuntu:
> > Fix Released
> > Status in initramfs-tools package in Ubuntu:
> > Confirmed
> >
> > Bug description:
> > Binary package hint: initramfs-tools
> >
> > When generating a new initramfs there is no check for available free
> > space, subsequently its possible for update-initramfs to fail due to a
> > lack of free space. This is resulting in package installation
> > failures for initramfs-tools. For example:
> >
> > Setting up initramfs-tools (0.98.8ubuntu3) ...
> > update-initramfs: deferring update (trigger activated)
> > Processing triggers for initramfs-tools ...
> > update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic
> >
> > gzip: stdout: No space left on device
> > E: mkinitramfs failure cpio 141 gzip 1
> > update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
> > dpkg: error processing initramfs-tools (--configure):
> > subprocess installed post-installation script returned error exit
> > status 1
> >
> > WORKAROUND:
> >
> > Remove unused kernels using computer janitor or manually free space on
> > your partition containing the /boot file system.
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/798414
>
> Title:
> update-initramfs should produce a more helpful error whe...

[Guillermo (casalguillermo)]

Thank you. Also i founded this alternative solution:

https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels

> Date: Wed, 9 Sep 2015 10:24:00 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: Re: [Bug 798414] Re: update-initramfs should produce a more helpful error when there isn't enough free space
>
> Thank you.
>
> 2015-08-15 7:35 GMT+02:00 David Gerstmann <email address hidden>:
>
> > Hello Alan Burgess, my name is David. The easiest way that I have found to
> > deal with this problem is to go into your Terminal and type in the
> > following in this order (I'll try to be as specific as possible).
> > sudo apt-get autoclean (that's exactly how it should look, then press
> > enter), next...
> > sudo apt-get autoremove (then enter), again...
> > sudo apt-get clean (enter)
> >
> > Do this every time before you attempt to update your computer. It may be a
> > bit of a pain, but it'll get you to where you need to be until someone
> > comes up with a permanent fix or another long term supported version comes
> > out again. Try this and let me know how it works for you. Good luck.
> > P.S., if you don't know what the terminal is, go into your dash and
> > simply type in the search window... "terminal", and that should come up
> > with what's known as the terminal emulator. Click on it and follow the
> > above instructions.
> >
> > On Wed, Aug 12, 2015 at 1:35 PM, Alan Burgess <email address hidden>
> > wrote:
> >
> > > Hello Casaba,
> > >
> > > Could you provide detailed instructions on how to resolve this issue
> > > please.
> > >
> > > Also when will this bug be resolved?
> > >
> > > Thanks
> > >
> > > Alan
> > >
> > >
> > >
> > > On 12/08/15 12:10, Csaba wrote:
> > > > ** Project changed: null-and-void => ubuntu
> > > >
> > >
> > > --
> > > You received this bug notification because you are subscribed to the bug
> > > report.
> > > https://bugs.launchpad.net/bugs/798414
> > >
> > > Title:
> > > update-initramfs should produce a more helpful error when there isn't
> > > enough free space
> > >
> > > Status in initramfs-tools:
> > > Confirmed
> > > Status in Ubuntu:
> > > Fix Released
> > > Status in initramfs-tools package in Ubuntu:
> > > Confirmed
> > >
> > > Bug description:
> > > Binary package hint: initramfs-tools
> > >
> > > When generating a new initramfs there is no check for available free
> > > space, subsequently its possible for update-initramfs to fail due to a
> > > lack of free space. This is resulting in package installation
> > > failures for initramfs-tools. For example:
> > >
> > > Setting up initramfs-tools (0.98.8ubuntu3) ...
> > > update-initramfs: deferring update (trigger activated)
> > > Processing triggers for initramfs-tools ...
> > > update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic
> > >
> > > gzip: stdout: No space left on device
> > > E: mkinitramfs failure cpio 141 gzip 1
> > > update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
> > > dpkg: error processing initramfs-tools (--configure):
> > > subprocess installed post-installation script returned error exit
> >...

[David Gerstmann (gerstmann-david)]

This is in response to Thomas A.F. Thorne's entry # 63. Hi there, so I went ahead and tried to download bikeshed as you suggested and the download failed, and at the end this error message came up... E: sub-process /usr/bin/dpkg returned and error code (1). I'm assuming the download failed because of dependency issues created by the bug we are all discussing here. I went ahead and tried to run bikeshed just in case and this error came up... E: invalid operation purge-old-kernals.... smack my head! I just realized my problem, I was misspelling kernel. I just ran bikeshed with the command and it just told me it's preparing to remove 831 mg..., just entered command df -h and /boot mounted on point is at 56%, down from 99%. Looks like a success so far, not sure what the error codes were all about earlier. I'm going to update to see what happens... and the update was successful.
   I'm sure someone will get a laugh out this little play by play. So is this something that I'll need to do wherever this bug rears it's head, or is this a one-time deal? Thank you for taking the time to post this solution.

[Taluk (terlukropuk23)]

please help

[Elilzabeth Maxwell (bmax524)]

I did not subscribe to this.  When I tried to use you unsubscribe section it said I was not subscribed to any items. So why am I getting these.  Please stop immediately.

     On Saturday, September 19, 2015 1:55 AM, Taluk <email address hidden> wrote:

 please help

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/798414

Title:
  update-initramfs should produce a more helpful error when there isn't
  enough  free space

Status in initramfs-tools:
  Confirmed
Status in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: initramfs-tools

  When generating a new initramfs there is no check for available free
  space, subsequently its possible for update-initramfs to fail due to a
  lack of free space.  This is resulting in package installation
  failures for initramfs-tools.  For example:

  Setting up initramfs-tools (0.98.8ubuntu3) ...
  update-initramfs: deferring update (trigger activated)
  Processing triggers for initramfs-tools ...
  update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic

  gzip: stdout: No space left on device
  E: mkinitramfs failure cpio 141 gzip 1
  update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
  dpkg: error processing initramfs-tools (--configure):
   subprocess installed post-installation script returned error exit status 1

  WORKAROUND:

  Remove unused kernels using computer janitor or manually free space on
  your partition containing the /boot file system.

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions

[gravy45 (gravy45)]

Related to the proposed workaround, I've been using Ubuntu MATE since April-2015 and already ran into this issue after the few "apt-get dist-upgrade". It seems to me that 100 Mb for /boot partition under automatic partitioning needs to be expanded. Is that a new bug/feature request?

I agree that the way to fix this is not to implement the workaround but rather to produce a more helpful error, but if the size of the partition is artificially low, it should be bumped up.

[Geoff Hickey (ardri)]

The Ubuntu problem reporter now redirects to this bug whenever there's not enough space on the /boot partition to install a new version of the kernel. This has gotten much more common on systems set up since 2014, because Ubuntu now creates a small, separate /boot partition by default. On systems partitioned with earlier versions of Ubuntu /boot is part of a much larger / partition, so you may never run into this.

I've included my workaround to this problem, which I'm now using every couple of weeks when one or another of my Ubuntu systems gets into this state.

But I also want to disagree with the resolution proposed by the title of this bug. Even if the "fix" proposed in the title of this bug were implemented, it wouldn't solve the problem or even make it easier for less-technical users to get their systems working again.

Ubuntu must manage the set of kernels installed on the system. It must set up a /boot partition capable of holding the number of kernels it expects to see on a normal system. If /boot becomes full it must be able to identify and remove some old kernels. Expecting the end user to manage this means Ubuntu is unsuitable for non-technical users, and I think that goes entirely against Ubuntu's founding principles. Moreover, I don't know why even a technically-minded user would be satisfied with the current state of affairs. There's no reason why the package manager should get into a broken state every few weeks that requires human intervention to fix. These old kernels serve no purpose for the great majority of users, technical or not.

For those who are running into this for the first time, here's the workaround I use to fix this problem. Be very careful doing this; deleting the wrong thing can easily render your system unbootable. I use aptitude for package management, so you'll need to install it before you can do this (sudo apt-get install aptitude). At a command prompt:

$ aptitude search linux-image | grep ^i

This will produce a list of installed kernel images, which look like this:

i linux-image-3.19.0-28-generic - Linux kernel image for version 3.19.0 on 686
i linux-image-3.19.0-30-generic - Linux kernel image for version 3.19.0 on 686

You can delete all of them, except the most recent one and the one that's actually running, which may or may not be the same. The most recent one will be the last numbered one on the list. You can find out what's actually running by running this command:

$ uname -a
Linux gh-narcissus 3.19.0-30-generic #33-Ubuntu SMP Mon Sep 21 20:58:04 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

To delete the unused kernels, do this:

$ sudo aptitude purge linux-image-3.19.0-28-generic

You'll can list more than one image on this command line. Aptitude will warn you that it's going to remove linux-image-extra- packages with the same version numbers as the linux-image packages your purging. That's ok, but make sure the list doesn't include linux-image-generic (which will happen if you accidentally put the latest kernel version on the list).

This will sometimes fail, if /boot is completely full. In that case, I remove some of the boot files for the unused kernel images manually, and then run the...

[Justin (labadvisor)]

I had this problem about a month ago and deleted old kernels and it worked fine at that point. I had tried a few different flavors before I settled on Lubuntu so I thought that might be why I had the older kernel versions floating around. Here I am with the same problem again.

Filesystem Size Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-root 228G 14G 204G 7% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 479M 8.0K 479M 1% /dev
tmpfs 99M 1.5M 98M 2% /run
none 5.0M 0 5.0M 0% /run/lock
none 493M 76K 493M 1% /run/shm
none 100M 24K 100M 1% /run/user
/dev/sda2 237M 232M 0 100% /boot

sda2 is chock full again so I checked my kernels:

i linux-image-3.16.0-44-generic - Linux kernel image for version 3.16.0 on 3
i linux-image-3.16.0-45-generic - Linux kernel image for version 3.16.0 on 3
i linux-image-3.16.0-46-generic - Linux kernel image for version 3.16.0 on 3
i linux-image-3.16.0-48-generic - Linux kernel image for version 3.16.0 on 3
i linux-image-3.16.0-49-generic - Linux kernel image for version 3.16.0 on 3
i linux-image-3.16.0-50-generic - Linux kernel image for version 3.16.0 on 3
i linux-image-extra-3.16.0-44-gen - Linux kernel extra modules for version 3.1
i linux-image-extra-3.16.0-45-gen - Linux kernel extra modules for version 3.1
i linux-image-extra-3.16.0-46-gen - Linux kernel extra modules for version 3.1
i linux-image-extra-3.16.0-48-gen - Linux kernel extra modules for version 3.1
i linux-image-extra-3.16.0-49-gen - Linux kernel extra modules for version 3.1

I am confident that I had deleted all but 49 and 50 last time but here they are again. I'll admit that I am a relative noob on linux so the problem may be with the user! I am posting this information primarily to try and help. I'm going to delete the extra kernels again and see how it goes.

[Bill Meier (wmeier)]

I can't believe they haven't taken care of this yet. When I go to delete
the older kernels I get denied. I tried some other things I saw
mentioned but, probably because I didn't know what I was doing, they
didn't work for me either. Now, I make sure all my data is on the other
hard drive and just reinstall the system... start over. I am running
Lubuntu 15.04 now, we'll see.

On 10/12/2015 02:26 PM, Justin wrote:
> I had this problem about a month ago and deleted old kernels and it
> worked fine at that point. I had tried a few different flavors before I
> settled on Lubuntu so I thought that might be why I had the older kernel
> versions floating around. Here I am with the same problem again.
>
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/ubuntu--vg-root 228G 14G 204G 7% /
> none 4.0K 0 4.0K 0% /sys/fs/cgroup
> udev 479M 8.0K 479M 1% /dev
> tmpfs 99M 1.5M 98M 2% /run
> none 5.0M 0 5.0M 0% /run/lock
> none 493M 76K 493M 1% /run/shm
> none 100M 24K 100M 1% /run/user
> /dev/sda2 237M 232M 0 100% /boot
>
> sda2 is chock full again so I checked my kernels:
>
> i linux-image-3.16.0-44-generic - Linux kernel image for version 3.16.0 on 3
> i linux-image-3.16.0-45-generic - Linux kernel image for version 3.16.0 on 3
> i linux-image-3.16.0-46-generic - Linux kernel image for version 3.16.0 on 3
> i linux-image-3.16.0-48-generic - Linux kernel image for version 3.16.0 on 3
> i linux-image-3.16.0-49-generic - Linux kernel image for version 3.16.0 on 3
> i linux-image-3.16.0-50-generic - Linux kernel image for version 3.16.0 on 3
> i linux-image-extra-3.16.0-44-gen - Linux kernel extra modules for version 3.1
> i linux-image-extra-3.16.0-45-gen - Linux kernel extra modules for version 3.1
> i linux-image-extra-3.16.0-46-gen - Linux kernel extra modules for version 3.1
> i linux-image-extra-3.16.0-48-gen - Linux kernel extra modules for version 3.1
> i linux-image-extra-3.16.0-49-gen - Linux kernel extra modules for version 3.1
>
> I am confident that I had deleted all but 49 and 50 last time but here
> they are again. I'll admit that I am a relative noob on linux so the
> problem may be with the user! I am posting this information primarily to
> try and help. I'm going to delete the extra kernels again and see how it
> goes.
>

[PcB Computer Support (pc-t)]

ere my solution for UBUNTU whit simple install of one ubuntu 15.4

Error of Bootintrams Update

1. Open a terminal

2. Then check what for kernel u use : enter „cat /proc/version“ in Terminal
OUTPUT something like:
Linux version x.xx.x-XX-generic …

3.open Filemanager with Root rights in Terminal Ubuntu Nautilus
Tipe in terminal „gksudo nautilus“
or kdesudo dolphin,gksudo thunar, gksudo pcmanfm, gksudo caja
then enter

4. The Nautilus open with root rights (attention now)
got to /Boot folder

5. select and kill all file beginning with
abi AND config AND initrt AND system.map AND vmlinuz
but only the file where have not the right system number verified with cat /proc/version before (Linux version x.xx.x-XX-generic) and ATTENTION LEFT all files abi AND config AND initrt AND system.map AND vmlinuz with these number and left all the other files with memtest

6. then go to terminal and set
A: sudo update-grub (ENTER)
B: sudo apt-get update (ENTER)
C: sudo apt-get upgrade (ENTER)

7. Rebot the system

IT works fine and now everytime i got the intram error i do the same again and it works

but could someone help us to enlarge the boot sector?

or to create a repair file to go step by step to resolve the problem
and implementing next release to get bigger boot sector ?? With best regards
.......................................................................
PcB - Personal Computing Bisceglia
COMPUTER SUPPORT

[PcB Computer Support (pc-t)]

PS sorry my English isnt the best... and yes i use start use linux not so long away but maybe someone more practicaly can write a nice clear rool for that what i postet here for user without lot of experiance like me..

thanks and i am sorry to have just short time to invest here ..

Marc

[Juha Simola (jm-simola)]

I think we should add GUI to
- list all installed kernels.
- letting user to remove all kernels except the current one or newer.
- shortcut "clear all older than current"

[PcB Computer Support (pc-t)]

attention dont delete all kernels, need exepting all kernels from acctual used kernel to all kernel theyre newer then this..

Von meinem iPhone gesendet

Am 21.10.2015 um 08:41 schrieb Juha Simola <email address hidden>:

I think we should add GUI to
- list all installed kernels.
- letting user to remove all kernels except the current one or newer.
- shortcut "clear all older than current"

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/798414

Title:
 update-initramfs should produce a more helpful error when there isn't
 enough free space

Status in initramfs-tools:
 Confirmed
Status in Ubuntu:
 Fix Released
Status in initramfs-tools package in Ubuntu:
 Confirmed

Bug description:
 Binary package hint: initramfs-tools

 When generating a new initramfs there is no check for available free
 space, subsequently its possible for update-initramfs to fail due to a
 lack of free space. This is resulting in package installation
 failures for initramfs-tools. For example:

 Setting up initramfs-tools (0.98.8ubuntu3) ...
 update-initramfs: deferring update (trigger activated)
 Processing triggers for initramfs-tools ...
 update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic

 gzip: stdout: No space left on device
 E: mkinitramfs failure cpio 141 gzip 1
 update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
 dpkg: error processing initramfs-tools (--configure):
  subprocess installed post-installation script returned error exit status 1

 WORKAROUND:

 Remove unused kernels using computer janitor or manually free space on
 your partition containing the /boot file system.

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions

[markling (markling)]

No, Bill Canaday (bill13510). No, no, no. And no.

The linux way is everyone does their bit to make the software better. Users, who are not developers or system administrators, report when things don't work properly. This is a time-consuming and often seemingly thankless, fruitless and pointless process. But they persist because they share with developers the hope that the system might become good enough one day for all users, and not just those who are prepared to put up with the unending extra hours is takes to put up with, work around, and fix all the problems inherent in this perpetually unfinished, half-finished, half-baked software.

[Iain (iainm-f)]

As a very new member of the Ubuntu community can I make a couple of observations?

First: I understand the statement "Insufficient space in /boot" however: when I used the instruction that is supposed to clear space [sudo apt-get clean] it either didn't or didn't clear enough. So I thought I'd take the direct approach. I'm an Administrator, so I loaded the Files application and went looking, but when I found what I thought was the /boot folder the system would not allow me to delete some older files (looked like downloads from earlier updates). Maybe the error message can include a solution that tells me how to delete the old files and/or increase the space of the /boot folder? Or even where to find the /boot folder?

My second comment is that maybe once the installation of an update has successfully completed then the downloaded installation files could be deleted?

I've tried limiting the download to smaller sections of the current update but nothing seems to install.

Quick update: I thought I'd take one more look at the search engine and I found another command to remove junk from the boot (sudo apt-get autoremove) and this tells me it removed 300MB but the install still says it needs 30MB more than the available limit...

How do I clean up the /boot folder?

[Alan Burgess (z-alan-4)]

Iain,

This 'bug has been around for a long time now and the information that
is on or comes back from the forum is inadequate and in one instance
rendered my computer unbootable.

In the end I moved back to Windows 7 for all my serious work and now use
Ubuntu 14.04 for anything that I'm prepared to loose. I hope one day to
be able to move back to Ubuntu as my main computing platform when it is
as stable as Win 7.

Good luck.

On 10/11/15 23:43, Iain wrote:
> As a very new member of the Ubuntu community can I make a couple of
> observations?
>
> First: I understand the statement "Insufficient space in /boot" however:
> when I used the instruction that is supposed to clear space [sudo apt-
> get clean] it either didn't or didn't clear enough. So I thought I'd
> take the direct approach. I'm an Administrator, so I loaded the Files
> application and went looking, but when I found what I thought was the
> /boot folder the system would not allow me to delete some older files
> (looked like downloads from earlier updates). Maybe the error message
> can include a solution that tells me how to delete the old files and/or
> increase the space of the /boot folder? Or even where to find the /boot
> folder?
>
> My second comment is that maybe once the installation of an update has
> successfully completed then the downloaded installation files could be
> deleted?
>
> I've tried limiting the download to smaller sections of the current
> update but nothing seems to install.
>
> Quick update: I thought I'd take one more look at the search engine and
> I found another command to remove junk from the boot (sudo apt-get
> autoremove) and this tells me it removed 300MB but the install still
> says it needs 30MB more than the available limit...
>
> How do I clean up the /boot folder?
>

[Arnett Carroll (arnett-carroll)]

arnett@UbunutuLinuxLTS-Gateway-NE56R41u-NE56R:~$ sudo apt-get --purge autoremove[sudo] password for arnett:
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
4 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up linux-image-3.13.0-68-generic (3.13.0-68.111) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
The link /initrd.img is a dangling linkto /boot/initrd.img-3.13.0-68-generic
vmlinuz(/boot/vmlinuz-3.13.0-68-generic
) points to /boot/vmlinuz-3.13.0-68-generic
 (/boot/vmlinuz-3.13.0-68-generic) -- doing nothing at /var/lib/dpkg/info/linux-image-3.13.0-68-generic.postinst line 491.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.13.0-68-generic /boot/vmlinuz-3.13.0-68-generic
run-parts: executing /etc/kernel/postinst.d/dkms 3.13.0-68-generic /boot/vmlinuz-3.13.0-68-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.13.0-68-generic /boot/vmlinuz-3.13.0-68-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-68-generic

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-3.13.0-68-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.13.0-68-generic.postinst line 1025.
E: Sub-process /usr/bin/dpkg returned an error code (1)
arnett@UbunutuLinuxLTS-Gateway-NE56R41u-NE56R:~$ sudo apt-get --purge autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
4 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up linux-image-3.13.0-68-generic (3.13.0-68.111) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
The link /initrd.img is a dangling linkto /boot/initrd.img-3.13.0-68-generic
vmlinuz(/boot/vmlinuz-3.13.0-68-generic
) points to /boot/vmlinuz-3.13.0-68-generic
 (/boot/vmlinuz-3.13.0-68-generic) -- doing nothing at /var/lib/dpkg/info/linux-image-3.13.0-68-generic.postinst line 491.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.13.0-68-generic /boot/vmlinuz-3.13.0-68-generic
run-parts: executing /etc/kernel/postinst.d/dkms 3.13.0-68-generic /boot/vmlinuz-3.13.0-68-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.13.0-68-generic /boot/vmlinuz-3.13.0-68-generic
update-initramfs: Generating /boot/initrd.img-3.13.0-68-generic

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-3.13.0-68-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.13.0-68-generic.postinst line 1025.
dpkg: error processing package linux-image-3.13.0-68-generic (--configure):
...

[Ads20000 (ads20000)]

For me, simply using `sudo apt-get autoremove` and then `sudo apt upgrade` works.

[Ads20000 (ads20000)]

What release is this fixed in? Though running `apt-get autoremove`, `apt-get clean` and `apt upgrade` works (for me at least), the bug still applies (in Trusty)...

[David Jones (drj)]

I think this is a pretty serious issue because if you select Full Disk Encryption when install Ubuntu a very small (~250e6 byte) partition is created. Each kernel update creates another (~30e6 byte) initrd.img file and you quickly run out of space (only enough space for about 4 kernel upgrades). Typically during the update-initramfs of a "apt-get upgrade".

It is not acceptable for ordinary users to have to manage their kernels and their free space in the /boot partition.

[Ads20000 (ads20000)]

Surely the installation process should automatically remove the oldest kernel before installing the newest one if there isn't enough space to install the newest one?

[Jeroen (p-launchpad-3)]

Like #84, I ran into this issue after only a few weeks of running a standard Ubuntu installation with full disk encryption.

[Hobson Lane (hobs)]

Like #86, but for me it took 3 weeks. Depends on number of kernel patches released after initial install. The OS should `sudo apt-get autoclean` instead of crash. Fine to "notify" user of the inadequate default boot partition size, but definitely not OK to scare them with a "Crash" notice every time that boot partition is found to be too small for the pace of kernel patches and the default kernel retention policy.

[Doug McNutt (dmcnutt)]

I have found a problem several times running updates which are coming more and more often. That's probably good for security but the automated attempt to update adds a bunch of files to a root level directory, like this:

lenovo[~]> cd /boot
lenovo[/boot]> ls -l
total 92010
-rw-r--r-- 1 root root 1312266 Dec 2 15:52 abi-4.2.0-21-generic
-rw-r--r-- 1 root root 1312266 Dec 17 20:23 abi-4.2.0-22-generic
-rw-r--r-- 1 root root 184850 Dec 2 15:52 config-4.2.0-21-generic
-rw-r--r-- 1 root root 184850 Dec 17 20:23 config-4.2.0-22-generic
drw-rw-rw- 5 root root 1024 Dec 20 10:25 grub
-rw-r--r-- 1 root root 34594062 Dec 18 10:36 initrd.img-4.2.0-21-generic
-rw-r--r-- 1 root root 34597280 Dec 20 10:25 initrd.img-4.2.0-22-generic
drw-rw-rw- 2 root root 12288 May 26 2015 lost+found
-rw-r--r-- 1 root root 182704 Aug 27 09:04 memtest86+.bin
-rw-r--r-- 1 root root 184380 Aug 27 09:04 memtest86+.elf
-rw-r--r-- 1 root root 184840 Aug 27 09:04 memtest86+_multiboot.bin
-rw------- 1 root root 3740849 Dec 2 15:52 System.map-4.2.0-21-generic
-rw------- 1 root root 3740849 Dec 17 20:23 System.map-4.2.0-22-generic
-rw------- 1 root root 6799408 Dec 2 15:52 vmlinuz-4.2.0-21-generic
-rw------- 1 root root 6799856 Dec 17 20:23 vmlinuz-4.2.0-22-generic

To fix I have to login as root and delete older files that, hopefully, will never be needed for a backup.

There is plenty of extra room on the disk and it's hard to understand why the files can't just continue to waste space but I can't find evidence of some limit other than the disk itself. Is it possible that root has some limit to its own use?

[Greyed (grey)]

4+ years and still not fixed. And no, to the many people who have listed how to "fix" it via apt commands, that is not a fix, that is a kludge. APT (in its myriad forms) is a package manager. That means these kernel packages should be managed. So here are the facts.

1: Ubuntu now suggests for partitioning a tiny /boot partition.
2: Ubuntu now pushes out several minor kernel updates per month.
3: Those kernel updates do not clean up after themselves.

Add those three together and it means every Ubuntu user will, I stress WILL, run into this problem in short order.

This is a core package, it is a managed package, this problem should be MANAGED, not kludged. But all I see in going back through the history of this bug is two things which should not be happening.

1: The bug being assigned out to someone only to be assigned to nobody right after it.
2: People disparaging others for wanting the issue resolved.

[Kenneth Bingham (qrkourier)]

I second ~grey's assertion. I installed Wily 15.10 only a few weeks ago and accepted the default /boot partition size suggested for use with LVM and today was unable to perform a routine package upgrade due to a lack of free space on /boot. I was able to work around the problem by first listing installed kernel versions:

$ dpkg -l linux-image-\*|grep ^ii
ii linux-image-4.2.0-16-generic 4.2.0-16.19 amd64 Linux kernel image for version 4.2.0 on 64 bit x86 SMP
ii linux-image-4.2.0-21-generic 4.2.0-21.25 amd64 Linux kernel image for version 4.2.0 on 64 bit x86 SMP
ii linux-image-4.2.0-22-generic 4.2.0-22.27 amd64 Linux kernel image for version 4.2.0 on 64 bit x86 SMP
ii linux-image-4.2.0-23-generic 4.2.0-23.28 amd64 Linux kernel image for version 4.2.0 on 64 bit x86 SMP
ii linux-image-extra-4.2.0-16-generic 4.2.0-16.19 amd64 Linux kernel extra modules for version 4.2.0 on 64 bit x86 SMP
ii linux-image-extra-4.2.0-21-generic 4.2.0-21.25 amd64 Linux kernel extra modules for version 4.2.0 on 64 bit x86 SMP
ii linux-image-extra-4.2.0-22-generic 4.2.0-22.27 amd64 Linux kernel extra modules for version 4.2.0 on 64 bit x86 SMP

then identifying the running kernel

$ uname -r
4.2.0-22-generic

then purging old kernel pax
$ sudo apt-get purge linux-image-4.2.0-{16,21}

and finally completing package upgrades
$ sudo aptitude update && sudo aptitude upgrade

[Ronny Ager-Wick (ronny-ager-wick)]

Completely agree with @grey - it is unacceptable that such a simple thing will consistently create problems for ALL ubuntu users, many of which will not be comfortable with entering "sudo apt-get -y autoremove" or whatever in terminal.

I do understand the issue though - each kernel is a separate package, and as such, apt can't just uninstall it without asking.

So I suggest that as default, instead of linux-image-generic depending on the latest kernel package, create a new pakcage, perhaps called "linux-image-generic-current", which does not /depend/ on the latest kernel package, but /is/ the latest kernel package (or a copy at least). This way. when a new kernel is released, this package will get a new version and the kernel will be downloaded and *replace* the old one. There may be a catch here, but I am sure if there is someone knowledgeable will tell me :)
It's important that this is the default, as less knowledgeable users will then avoid the issue without having to do anything.

Yes, I know that this way, you can't boot on an older kernel. This is rarely an issue though, as most people don't do that. For the few cases it is needed, maybe one could add another package "linux-image-generic-previous" for the second to the last version and/or "linux-image-generic-original" for the first kernel to be released for the current version of Ubuntu?
Of course it's completely possible for a user to install one specific kernel separately, which they can use in case the latest one can't boot.

For people who genuinely needs the current way of always retaining the previous kernels, linux-image-generic could continue to be maintained as well as linux-image-generic-current, and either of the two can be installed, but not both. I believe this is possible with apt?

I also suggest the default boot partition size to be 5% of total disk space, min 250MB (current default), max 2GB.
But no matter how big you make it, eventually it will run out of space anyway, so only increasing the size of the /boot partition is just delaying the issue.

Alternatively, can a cron or startup job be set up as default (on all new installations of Ubuntu), that runs "apt-get -y autoremove", perhaps only for linux-kernel packages (if possible) at boot or every month or so?

[Ronny Ager-Wick (ronny-ager-wick)]

@dmcnutt /boot is usually a separate partition, byt default around 250MB, which is way too small. Use command "df" to see how much space you have left on each partition. if /boot is nearly full, it doesn't help if / has loads of space.

[Doug McNutt (dmcnutt)]

Very helpful Mr. Ager-Wick

Its strange that partitions show up as /boot under, somehow under /dev/sda1.
I guess that makes sence but I also have a disk reported as
/dev/sdb1 /media/kit/UNTITLED
which is actually a portable disk tied in by USB connections. (kit is
another user)
/dev/null/ is about my level of usage for /dev at all. I shall work on that.
Is there, perhaps, something wrong with reporting usage that start with
/dev?
/dev/dm-0, or perhaps dm-O, shows 143G size and 72G used and I have no
idea where or what it's used for. It sounds like I might have a problem
there.
Currently:
/dev/sda1 236M 144M 80M 65% /boot
which will be OK for a while but I had no idea that it was a partition
rather than a simple directory. There is a real directory /div/ which
could also be handling it within the system. I assumed that while
deleting older entries and it worked with simple rm commands.

On 01/06/2016 09:33 AM, Ronny Ager-Wick wrote:
> @dmcnutt /boot is usually a separate partition, byt default around
> 250MB, which is way too small. Use command "df" to see how much space
> you have left on each partition. if /boot is nearly full, it doesn't
> help if / has loads of space.
>

[Markku Vire (markku-vire)]

I have installed several systems using the encryption option from the graphical installer. I really need to use the full disk encryption and the installer option seems to be the most straightforward way to achieve this. As far as I remember the manual partitioning did not allow to setup LVM, which in turn was the way to unlock both swap and rootfs by entering a single password.

Having that small /boot seems ridiculous, given that the the device itself is 2 TB. Increasing the boot partition size could work as band-aid solution to make the manual cleanup happen not that often. Or the update tool could automatically try to remove the few oldest kernels.

[Paulo Almeida (paulo-cruz1920)]

Andy Balaam, thank you. That worked!

[william burt (wdburt)]

Andy Balaam, thank you indeed. I am a new Ubuntu user, switching from Windows (work). Can't believe this kludge has been going on as long as the comments indicate. Board comments led me to try your fix, and it worked.

[Clifford Ruhlman (sharpdrop)]

@Andy Balaam, another thank you! I would also like to second William Burt and everyone else who has said enough already!

[Ronny Ager-Wick (ronny-ager-wick)]

@dmcnutt
USB disks show up here just like other disks in "df", so that's normal.
/dev/dm-0 is most likely an encrypted partition. /boot cannot be in an encrypted partition because you need it for decryption. If the disk was just one big encrypted partition, you'd need to boot on a USB stick or something in order to decrypt it. If you install ubuntu on a disk using disk encryption (for example ext4), then you don't need to separate /boot on a separate partition.

[Jake McGregor (jake-mcgregor86)]

The only thing I can add here (and hopefully I'm not repeating anyone here) is /boot claims to be about 75% full, and I have also seen it 100% on another system of mine. It appears the problem is during the transition between kernel 4.3 and 4.4. I use an encrypted partition on both systems, one of which is a Surface Pro 3 using secure boot (if that matters to anyone). I have only had one case where the system was unable to boot because of this. Lucky for me I have a cloud backup. The others I caught it in time. I was able to keep the system stable by fixing what appeared to be a dependency error. Then again not rebooting might have also helped. My guess is the Ubuntu installer didn't leave much space on /boot, though normally all that is stored there is a few kernels and related files. Everything appears fine now.

[Hobson Lane (hobs)]

df -h | grep -E '(10|9)[0-9]%\s+/boot' && sudo apt-get autoremove

[Chris Cooper (cacooper74)]

I know others have said similar but I don't understand why the automatic settings only reserve 250Mb for boot drive.
Why not make it 5G then it won't run out of space?
or perhaps 5% of the drive space ?

 I will try to boot off a cd key and adjust mine to overcome this problem.

[Andrew (am-public-o)]

For desktops, I think /boot should be 500MB; however for servers, 250MB still makes sense.

[Mathieu Trudel-Lapierre (cyphermox)]

@Kishor, please do not assign yourself to bugs unless you plan on working on the fix yourself.

I increased the minimum size of boot on new installs already (that was bug 1465050), which should help alleviate the problem; there could still be some work done to improve the error message there, but it's not necessarily a simple thing to do.

[Hobson Lane (hobs)]

REALLY disappointed in Canonical and Ubuntu. Why isn't a bug like this the very top priority of Canonical's development team and the open source community? The bug potentially affects all users and prevents those users from upgrading the kernel, even to plug security holes. Aren't security and kernel problems that affect all users of concern to anyone with the power and skills to fix them?

I'm now stuck with having to manually remove kernel files (seriously?) on an expensive laptop with a factory installed Ubuntu 14.04 OS. Even `autoremove` fails for me because gzip has no room to extract the files that it wants to delete? And of course the bug is silently ignored by appreport and consequently Ubuntu and Canonical. Shame on you...

(tp)hobson@hobs-dell:/boot$ sudo apt-get autoremove -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.
5 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up linux-image-extra-4.2.0-36-generic (4.2.0-36.41) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.2.0-36-generic /boot/vmlinuz-4.2.0-36-generic
run-parts: executing /etc/kernel/postinst.d/dkms 4.2.0-36-generic /boot/vmlinuz-4.2.0-36-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.2.0-36-generic /boot/vmlinuz-4.2.0-36-generic
update-initramfs: Generating /boot/initrd.img-4.2.0-36-generic

gzip: stdout: No space left on device
E: mkinitramfs failure find 141 cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-4.2.0-36-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-extra-4.2.0-36-generic (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-generic:
 linux-image-generic depends on linux-image-extra-4.2.0-36-generic; however:
  Package linux-image-extra-4.2.0-36-generic is not configured yet.

dpkg: error processing package linux-image-generic (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-generic:
 linux-generic depends on linux-image-generic (= 4.2.0.36.39); however:
  Package linux-image-generic is not configured yet.

dpkg: error processing package linux-generic (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-signed-image-generic:
 linux-signed-image-generic depends on linux-image-extra-4.2.0-36-generic; however:
  Package linux-image-extra-4.2.0-36-generic is not configured yet.

dpkg: error processing package linux-signed-image-generic (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems preventNo apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                                                           No apport report written because the error message indicate...

[Hobson Lane (hobs)]

For those that can no longer run autoremove (like me, above), and don't like messing around int he /boot drive without someone else giving them reassurance, here's what I did:

# figure out what the oldest kernel files are named (version) so you can delete them:

(tp)hobson@hobs-dell:/boot$ ls -al
total 224219
drwxr-xr-x 5 root root 3072 May 14 10:47 .
drwxr-xr-x 23 root root 4096 May 10 08:50 ..
-rw-r--r-- 1 root root 1312643 Feb 25 19:17 abi-4.2.0-30-generic
-rw-r--r-- 1 root root 1312645 Mar 10 16:11 abi-4.2.0-34-generic
-rw-r--r-- 1 root root 1313029 Mar 15 17:45 abi-4.2.0-35-generic
-rw-r--r-- 1 root root 1313407 Apr 18 12:49 abi-4.2.0-36-generic
-rw-r--r-- 1 root root 184888 Feb 25 19:17 config-4.2.0-30-generic
-rw-r--r-- 1 root root 184888 Mar 10 16:11 config-4.2.0-34-generic
-rw-r--r-- 1 root root 184888 Mar 15 17:45 config-4.2.0-35-generic
-rw-r--r-- 1 root root 184888 Apr 18 12:49 config-4.2.0-36-generic
-rw-r--r-- 1 root root 945 Mar 15 18:07 crontab -u root
drwx------ 3 root root 4096 Dec 31 1969 efi
drwxr-xr-x 5 root root 1024 May 10 08:51 grub
-rw-r--r-- 1 root root 9392125 Feb 12 08:29 initrd.img-4.2.0-21-generic
-rw-r--r-- 1 root root 35759751 Feb 29 09:07 initrd.img-4.2.0-30-generic
-rw-r--r-- 1 root root 35783679 Mar 15 17:57 initrd.img-4.2.0-34-generic
-rw-r--r-- 1 root root 35807230 Apr 12 08:32 initrd.img-4.2.0-35-generic
-rw-r--r-- 1 root root 35808742 May 10 08:51 initrd.img-4.2.0-36-generic
drwx------ 2 root root 12288 Nov 9 2015 lost+found
-rw-r--r-- 1 root root 182704 Aug 27 2015 memtest86+.bin
-rw-r--r-- 1 root root 184380 Aug 27 2015 memtest86+.elf
-rw-r--r-- 1 root root 184840 Aug 27 2015 memtest86+_multiboot.bin
-rw------- 1 root root 3744565 Feb 25 19:17 System.map-4.2.0-30-generic
-rw------- 1 root root 3744589 Mar 10 16:11 System.map-4.2.0-34-generic
-rw------- 1 root root 3745312 Mar 15 17:45 System.map-4.2.0-35-generic
-rw------- 1 root root 3745958 Apr 18 12:49 System.map-4.2.0-36-generic
-rw------- 1 root root 6808720 Feb 25 19:17 vmlinuz-4.2.0-30-generic
-rw------- 1 root root 6810648 Feb 29 09:07 vmlinuz-4.2.0-30-generic.efi.signed
-rw------- 1 root root 6808528 Mar 10 16:11 vmlinuz-4.2.0-34-generic
-rw------- 1 root root 6810456 Mar 14 08:58 vmlinuz-4.2.0-34-generic.efi.signed
-rw------- 1 root root 6829104 Mar 15 17:45 vmlinuz-4.2.0-35-generic
-rw------- 1 root root 6831032 Apr 5 09:02 vmlinuz-4.2.0-35-generic.efi.signed
-rw------- 1 root root 6830512 Apr 18 12:49 vmlinuz-4.2.0-36-generic
-rw------- 1 root root 6832440 May 10 08:51 vmlinuz-4.2.0-36-generic.efi.signed

# insert your oldest kernel version number here:

(tp)hobson@hobs-del:/boot$ sudo rm *4.2.0-30*

# that should give you enough breathing room for gzip and autoremove to operate:

(tp)hobson@hobs-del:/boot$ sudo apt-get autoremove -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.
5 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up linux-image-extra-4.2.0-36-generic (4.2.0-36.41)...

[David Gerstmann (gerstmann-david)]

Agreed. This is such a large omission that I am tempted to believe it is on purpose. There are workarounds to temporarily fix the problem, but they are so complicated that a novice, such as myself, must employ great effort to find the temporary fixes. This seems to be a very bad way to promote an operating system. I'm curious if this problem will be fixed in the next long term supported version.

Sent from my MetroPCS 4G Wireless Phone

<div>-------- Original message --------</div><div>From: Hobson Lane <email address hidden> </div><div>Date:05/14/2016 10:50 AM (GMT-08:00) </div><div>To: <email address hidden> </div><div>Cc: </div><div>Subject: [Bug 798414] Re: update-initramfs should produce a more helpful error
  when there isn't enough free space </div><div>
</div>REALLY disappointed in Canonical and Ubuntu. Why isn't a bug like this
the very top priority of Canonical's development team and the open
source community? The bug potentially affects all users and prevents
those users from upgrading the kernel, even to plug security holes.
Aren't security and kernel problems that affect all users of concern to
anyone with the power and skills to fix them?

I'm now stuck with having to manually remove kernel files (seriously?)
on an expensive laptop with a factory installed Ubuntu 14.04 OS. Even
`autoremove` fails for me because gzip has no room to extract the files
that it wants to delete? And of course the bug is silently ignored by
appreport and consequently Ubuntu and Canonical. Shame on you...

(tp)hobson@hobs-dell:/boot$ sudo apt-get autoremove -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.
5 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up linux-image-extra-4.2.0-36-generic (4.2.0-36.41) ...
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.2.0-36-generic /boot/vmlinuz-4.2.0-36-generic
run-parts: executing /etc/kernel/postinst.d/dkms 4.2.0-36-generic /boot/vmlinuz-4.2.0-36-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.2.0-36-generic /boot/vmlinuz-4.2.0-36-generic
update-initramfs: Generating /boot/initrd.img-4.2.0-36-generic

gzip: stdout: No space left on device
E: mkinitramfs failure find 141 cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-4.2.0-36-generic with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-extra-4.2.0-36-generic (--configure):
subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-generic:
linux-image-generic depends on linux-image-extra-4.2.0-36-generic; however:
  Package linux-image-extra-4.2.0-36-generic is not configured yet.

dpkg: error processing package linux-image-generic (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-generic:
linux-generic depends on linux-image-generic (= 4.2.0.36.39); however:
  Package linux-image-generic is not configured yet.

dpkg:...

[Jarno Suni (jarnos)]

Luke Faraone, I think bug 1357093 and bug 1054927 are not duplicates of this. They are about getting automatic removal of excessive kernels done by default. This bug is about handling the case where /boot is about to fill up better. The bugs affect to different packages.

[Jarno Suni (jarnos)]

Luke Faraone, please revert the duplicates, or comment here your justification.

[Rod Smith (rodsmith)]

I agree with Jarno; these three bugs are related, but this one (at least) is not an exact duplicate of the other two. This one is explicitly and exclusively about mkinitramfs, whereas the other two are more general and can be triggered in other ways. (Those two might be duplicates of each other, but not of this one.) That said, a solution to the other two bugs is likely to make this one less likely to be a problem.

[Sebastian Nohn (sebastian-nohn)]

Interpolating the number of bugs to the number of users affected, looking into Google searches for users looking for help solving the problems caused by this, my guess is these are amongst the most annoying open bugs in Ubuntu out there.

Is there any chance that any of these bugs will be fixed in the current LTS releases?

[Jarno Suni (jarnos)]

Sebastian Nohn, https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1054927/comments/7 claims unattended-upgrades has been fixed in Xenial (that contains version 0.90). I understand it so that extra kernels should be automatically removed in Xenial. If that is not the case and /boot gets filled up, please update the bug status of bug 1054927.

[Luke Faraone (lfaraone)]

Fair enough. I've unmarked it as a duplicate.

Technically, yes, this bug is about the error message, although the "WORKAROUND" in the description is a bit of a misnomer, since it focuses on resolving the issue that resulted in the error.

Updating the copy should be easy enough; I can tackle that for Yakkety.

[Jarno Suni (jarnos)]

Fixing these will make the failure less likely to happen:
Bug 1357093
Bug 1460396
Bug 1465050

[Marcin (ubuntucolors)]

you can always bypass this, just use Terminal and sudo apt-get upgrade command

[equivalent8 (tomas-valent)]

mine df

```
 df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 3997848 0 3997848 0% /dev
tmpfs 803444 10096 793348 2% /run
/dev/dm-1 237116104 208916688 16131576 93% /
tmpfs 4017208 6892 4010316 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 4017208 0 4017208 0% /sys/fs/cgroup
/dev/nvme0n1p2 241965 117520 111953 52% /boot
/dev/nvme0n1p1 523248 3456 519792 1% /boot/efi
cgmfs 100 0 100 0% /run/cgmanager/fs
tmpfs 803444 56 803388 1% /run/user/1000
```

[Larry Merkle (xphileprof)]

After running sudo apt-get autoremove I was able to download and install updates without receiving the initramfs error message.

[Gordon (linux-web-expert)]

I'm still having this issue on Ubuntu Studio lowlatency kernel updates using the following cmds:

sudo apt-get update
sudo apt-get autoremove
sudo apt-get autoclean
sudo apt-get dist-upgrade

Then it fails, seems to recover, not entirely convinced :(

Is there a way to safely increase the boot partion ?

Using an SSD drive...

df -h
Filesystem Size Used Avail Use% Mounted on
udev 2.9G 12K 2.9G 1% /dev
tmpfs 577M 1.4M 576M 1% /run
/dev/dm-0 214G 137G 67G 68% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 0 5.0M 0% /run/lock
none 2.9G 100K 2.9G 1% /run/shm
none 100M 36K 100M 1% /run/user
/dev/sda1 236M 227M 0 100% /boot

Please help... this always occurs and has been for what seems months.

Thanks

[Jarno Suni (jarnos)]

Gordon, apt-get autoremove will not help for Ubunbu Studio 14.04 unless you have installed security updates automatically. Use e.g. command
sudo purge-old-kernels
from bikeshed package to remove extra kernels in Trusty. If that does not work, see https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels#Problems

[Jarno Suni (jarnos)]

Gordon, oh, according to the screenshot your system seems to have both generic and lowlatency kernels installed. Is that on purpose? Does "linux-version list" output all the releases? If not, see http://askubuntu.com/q/779031/21005 . Be careful with purge-old-kernels. You might want to use its --keep option to tell it how many kernels to keep.

[Gordon (linux-web-expert)]

Thx I'll look into those solutions, also trying Ubuntu live with GParted to
resize boot partition to 512 MB, in process of building image with
UNETbootin now.

Again appreciate fast response time.

Kind regards,
Gordon

On Jul 21, 2016 11:55 AM, "Jarno Suni" <email address hidden> wrote:

Gordon, oh, according to the screenshot your system seems to have both
generic and lowlatency kernels installed. Is that on purpose? Does
"linux-version list" output all the releases? If not, see
http://askubuntu.com/q/779031/21005 . Be careful with purge-old-kernels.
You might want to use its --keep option to tell it how many kernels to
keep.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/798414

Title:
  update-initramfs should produce a more helpful error when there isn't
  enough free space

Status in initramfs-tools:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  In Progress

Bug description:
  Binary package hint: initramfs-tools

  When generating a new initramfs there is no check for available free
  space, subsequently its possible for update-initramfs to fail due to a
  lack of free space. This is resulting in package installation
  failures for initramfs-tools. For example:

  Setting up initramfs-tools (0.98.8ubuntu3) ...
  update-initramfs: deferring update (trigger activated)
  Processing triggers for initramfs-tools ...
  update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic

  gzip: stdout: No space left on device
  E: mkinitramfs failure cpio 141 gzip 1
  update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
  dpkg: error processing initramfs-tools (--configure):
   subprocess installed post-installation script returned error exit status
1

  WORKAROUND:

  Remove unused kernels using computer janitor (not in repositories for
  14.04 or later) or manually free space on your partition containing
  the /boot file system.

  See instructions here
  https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions

[Alan Burgess (z-alan-4)]

Hi Gordon,

I've had this same issue for many months and have come to the conclusion
that there is no expertise within Ubuntu or if there is then no one who
is prepared to fix it and get it out to the community.

I have reluctantly had to revert 42 machines back to Windows. Windows 10
now which is miles better than XP and until Ubuntu has a professional
organisation behind it.

I'm leaving Ubuntu 14.04 on this one unit just to see it this issue ever
gets fixed.

Its been suggested we give Fedora a go and ditch any ideas of ever using
Ubuntu.

If you have any experience (good or bad) of Fedora then please share.

Many thanks

Alan

On 21/07/16 17:07, Gordon wrote:
> I'm still having this issue on Ubuntu Studio lowlatency kernel updates
> using the following cmds:
>
> sudo apt-get update
> sudo apt-get autoremove
> sudo apt-get autoclean
> sudo apt-get dist-upgrade
>
> Then it fails, seems to recover, not entirely convinced :(
>
> Is there a way to safely increase the boot partion ?
>
> Using an SSD drive...
>
> df -h
> Filesystem Size Used Avail Use% Mounted on
> udev 2.9G 12K 2.9G 1% /dev
> tmpfs 577M 1.4M 576M 1% /run
> /dev/dm-0 214G 137G 67G 68% /
> none 4.0K 0 4.0K 0% /sys/fs/cgroup
> none 5.0M 0 5.0M 0% /run/lock
> none 2.9G 100K 2.9G 1% /run/shm
> none 100M 36K 100M 1% /run/user
> /dev/sda1 236M 227M 0 100% /boot
>
>
> Please help... this always occurs and has been for what seems months.
>
> Thanks
>
> ** Attachment added: "ScreenShot of lowlatency - low disk space"
> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/798414/+attachment/4704773/+files/UbuntuStudio_Low_disk_space_on_dist-upgrade_after_autoremove_autoclean-07212016-085954.png
>

[Luke Faraone (lfaraone)]

b-vantola, please don't change the assignee unless you're actively working to fix the bug.

[Pxtl (pxtl)]

I have a text file in my home directory with the following snippet I found on an Ubuntu forum that i'm copying and pasting every time my boot dir runs out of memory:

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 have no idea what the above command does - I see some horrifying regexes and a double-nested sed call and some weird parameters and apt-get.... That's what this bug has reduced me to - copy-paste random commands into terminal. It seems to happen with the normal recommended boot partition - how are other users not hitting this all the time? Shouldn't every single user with recommended partitioning eventually run out of space and hit this total failure? Because I'm wondering about Grandma-machines where somebody just gets used to ignoring the fact that they can't update.

[Jarno Suni (jarnos)]

Pxtl, the script is explained in https://markmcb.com/2013/02/04/cleanup-unused-linux-kernels-in-ubuntu/ I do not recommend to use it, though. Rather use the instructions in the given workaround. (Even the script called purge-old-kernels isn't perfect and not usable in some more complex cases, but at least you can report bugs about it.)

[Jarno Suni (jarnos)]

Alan Burgess, have you tried to follow the workaround given in the description to manually remove old kernels and to setup automatic removal of old kernels?

[Gordon (linux-web-expert)]

Hi Jarno,

Thanks for all your advice and additional thanks to *Pxtl* for the idea of
a script, here's my own variation...

```
sudo apt-get purge `dpkg -l "linux-image-3.13.0-8*" | grep -E
"linux-image-3.13.0-8*" | awk {'print $2'} | tr '\n' ' '`
```

*Explaination*: the *dpkg* lists all the kernel images, followed by *grep*
to limit the list to just version .8* kernels and lastly *awk* and *tr*
convert the vertical list into a one-liner that is encapsulated by back
ticks that wraps into an *apt-get purge* command with a chance to review
everything before committing to Yes, use caution...

This freed up my */boot* volume, here's before and after running it over
version .7* and .8* kernels using *df -h*

/dev/sda1 236M 187M 37M 84% /boot --
BEFORE

/dev/sda1 236M 70M 154M 31% /boot --
AFTER

Finally my installed kernels as of now...

linux-image-3.13.0-24-lowlatency
linux-image-3.13.0-91-generic
linux-image-3.13.0-91-lowlatency
linux-image-3.13.0-92-generic
linux-image-3.13.0-92-lowlatency
linux-image-extra-3.13.0-77-generic
linux-image-extra-3.13.0-79-generic
linux-image-extra-3.13.0-83-generic
linux-image-extra-3.13.0-86-generic
linux-image-extra-3.13.0-87-generic
linux-image-extra-3.13.0-88-generic
linux-image-extra-3.13.0-91-generic
linux-image-extra-3.13.0-92-generic
linux-image-generic
linux-image-generic-lts-trusty
linux-image-lowlatency

It appears as if *apt-get purge* properly sorted out which *lowlatency* and
which *generic* kernels to keep.
I'd suggest this a potential workaround for now, please test and verify.
Many thanks in advance.

Kind Regards,
Gordon

On Sun, Jul 24, 2016 at 6:01 AM, Jarno Suni <email address hidden>
wrote:

> Alan Burgess, have you tried to follow the workaround given in the
> description to manually remove old kernels and to setup automatic
> removal of old kernels?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/798414
>
> Title:
> update-initramfs should produce a more helpful error when there isn't
> enough free space
>
> Status in initramfs-tools:
> Confirmed
> Status in initramfs-tools package in Ubuntu:
> In Progress
>
> Bug description:
> Binary package hint: initramfs-tools
>
> When generating a new initramfs there is no check for available free
> space, subsequently its possible for update-initramfs to fail due to a
> lack of free space. This is resulting in package installation
> failures for initramfs-tools. For example:
>
> Setting up initramfs-tools (0.98.8ubuntu3) ...
> update-initramfs: deferring update (trigger activated)
> Processing triggers for initramfs-tools ...
> update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic
>
> gzip: stdout: No space left on device
> E: mkinitramfs failure cpio 141 gzip 1
> update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
> dpkg: error processing initramfs-tools (--configure):
> subprocess installed post-installation script returned error exit
> status 1
>
> WORKAROUND:
>
> Remove unused kernels using computer janitor (not in repositories f...

[EDGAR (dgr-roman)]

como hago para entrar en boot y haser la reparticion en los espacios libres que tengo soy nuevo en esto y nose como aserlo

[Thomas A. F. Thorne (tafthorne)]

I hit this today. `df -h` confirmed my /boot was quite full (15MB left). Running `sudo purge-old-kernels` (from the bikeshed package) cleared out some things and brought the free space on /boot up to 93MB.

[Harald H. (haarektrans)]

Occured here today. Running this simple command to remove old kernels and unused packages worked around the issue:

sudo apt-get autoremove --purge

Alternatively, and to be able to remove even manually installed kernels, you could use:
sudo purge-old-kernels

To be able to use purge-old-kernels you may need to first install the the byobu package by running:
sudo apt-get install byobu

[Jarno Suni (jarnos)]

For people to whom the previously mentioned troubleshooting alternatives do not work, or who just need more advanced kernel purging this could be an option:
https://www.bountysource.com/issues/38300038-feature-request-the-command-should-work-like-this

[Vonschutter (stephan-schutter)]

This is an extremely dangerous bug since it prevents further updates. The package manager does not complete actions until this is resolved. Few non-sys admins will know how to get around this.

One possible root cause is creating too small of a boot partition at install.

[Pxtl (pxtl)]

Happened again.

[sauro peña (sauropm)]

no puedo ni apagar mi equipo despues que hice la nueva instalacion de ubuntu creo que es 16.04 algo asi bueno el problema que indica es image 04.04.y termina 39 algo asi bueno eh mandado el reporte ya soy nuevo y nose como utilizar muy bien el terminar

[klingklong (scofield-cg)]

how can i change?

[Teemu Leisti (teemu-leisti)]

I was again purging old kernels via the Synaptic package manager manually when I ran into this bug. As others have remarked above, the root cause of having to purge kernels manually when /boot runs out of space is pretty bad; an operating system that purports to be, and mostly is, easy-to-use, should be able to handle that situation far better, by purging old kernels automatically, or at most after one confirmation dialog.

[Anders Hall (a.hall)]

This hits me constantly. Why is this bug present years on end and three major Ubuntu versions? The workaround is easy enough, still for many users it is rocket science and will break the update procedure (I two other persons that cant fix it themselves). I.e, thus is a critical problem. Make a test in the installation procedure and remove the oldest unused kernel, if disk space is low, before installing the new version.

[Jarno Suni (jarnos)]

"No space left on device" error might occur not only when disk space in /boot is low, but also when there is lack of free inodes in system. linux-headers* packages have a lot of files, so this may happen during installing a new kernel. The script mentioned in comment #130 can operate in most cases even in case of lack of free inodes.

[Joachim Fagerholm (joachim-fagerholm)]

This bug is a disgrace. It has been around for years and sabotages many non-tech users life. If I was able to fix it I would try. Unfortunately I am not that skilled, can only fix the symptoms not contribute to fixing the problem itself. But I would think that someone on a higher skill level could do a service to the community here, fairly easily? apt-get autoremove and autoclean takes care of it on newer versions, didn't on 10.04. But they are apparently never run automatically? And /boot could really be more in tune with the size of the disk it is created on by the installation. I have had this trouble on Ubuntu 10.04, 12.04 and now 14.04.

[Alex (alex-wreschnig)]

Happened to me yet again, on a new system, running 16.10. Why is this still a thing? It affects every single person who uses the OS since if you don't consciously take steps to prevent it it's guaranteed to happen. And it means Ubuntu is fundamentally unsuited for general use because every layperson who uses it is going to eventually get to a point where they cannot install new packages. It's downright embarrassing. I don't understand, either, how this is only medium importance.

I mean, lord, compare it to this high-importance bug:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1554795

Not to say that subjecting users to an arbitrary timeout (with typos!) is a good thing, but this bug affects way more users than that bug does and it also has the potential to wreck systems for novice users. And undoubtedly has, over the past five-plus years it's been in existence.

[Jarno Suni (jarnos)]

"a more helpful error" that the title of this bug report calls for would not free you from the need to remove kernels manually.

I made a script called linux-purge to make it easy to remove extra kernels even in tricky conditions: https://www.bountysource.com/issues/38300038-feature-request-the-command-should-work-like-this (It is designed to handle dependency problems and even problem running out of inodes - that may occur when installing a kernel - when using --fix option.)

As for preventing system from getting full of kernels automatically, unattended-upgrades provides an adequate solution for most cases. You can configure it in Ubuntu 16.04 like this:
Add line

Unattended-Upgrade::Remove-Unused-Dependencies "true";

in /etc/apt/apt.conf.d/50unattended-upgrades

(since unattended-upgrades is enabled by default in 16.04; the configuration acts as if running "apt-get autoremove" periodically.)

The default setting in 16.04 is

Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

but that does not work in some cases (Bug #1624644); the former setting overrides it.

Alternatively, putting "linux-purge --yes --keep 1" as a cron job or alike could do automatic kernel purging, (if no other process has locked dpkg at the time of calling it).
It has some differences to the unattended-upgrades way:
- It works in 12.04 and 14.04, too. (unattended-upgrades cannot remove manually installed kernels that will be around, if user installs kernel using e.g. update-manager; Bug #1439769.)
- The number of kernels to keep is configurable. It keeps the given number of nearest older kernels of each installed kernel update series, e.g. linux-generic and linux-generic-lts-xenial, not necessarily the installed kernels with greatest versions. (You could use --auto-only to keep
manually installed kernels, too, but you probably would not want to use it in 12.04 and 14.04.)
- Current kernel will never be removed. (Bug #1615381)
- It removes configuration files, too. (i.e. it purges)
- It only removes versioned kernel packages whose name start by linux-.

[richud (richud.com)]

It is bugs like this that make me question whether I am doing the right thing converting people to using Ubuntu...

[Thomas A. F. Thorne (tafthorne)]

@jarnos mentions having generated a script to remove extra kernels. There is already a purge-old-kernels command line tool lingering in the bikeshed package.

[Thomas Hamacher (dafox)]

This annoying bug still exists after more than 5 years, even though there are documented workarounds and scripts for purging old kernels available. Is there a chance this bug will ever get fixed?

[Roshan (rhapu-o)]

E: Sub-process /usr/bin/dpkg returned an error code (1)

[s frahm (sfrahm)]

Ubuntu 16.04 (ubuntu 4.4.0-64) crashed yet again during upgrade to 4.4.0-66 from this same recurring 5+ year old bug - Pray tell, why can't Ubuntu just tell me there is not enough room to upgrade the kernel (it used to) and then perhaps even offer to fix it automagically with some kind of an automated or scripted version of - $ sudo purge-old-kernels instead of just crashing my whole enchilada? I simply just don't understand the Ubuntu cultural or technical limitations that have kept this from happening. First I have to install Janitor with Ubuntu Tweaks on 12.04 - 14.04 LTS and delete all but the two latest older versions and now with 16.04 I must install Byobu Terminal (which thing I like very much anyway on most linux flavors lately) and manually type - $ sudo purge-old-kernels 5x - each time I attempt an upgrade of a base install and 4 ea. KVM virtual machines. Oops, I forgot the one on the hypervisor... CRASH! Arrrggghhhh! Grub / advanced / recover to an older kernel - $ sudo apt-get install -f Thanks to the entire community for such an otherwise wonderful thing that Ubuntu, Lubuntu, etc. is! (...Hmm, ask the Webmin folks to add a script that does this perhaps?) Thanks!

[Jarno Suni (jarnos)]

sfrahm, I do you mean Bug #1460396.

[s frahm (sfrahm)]

Yes sir (jarnos), thank you. This same recurring Bug #1460396 by many names. Is there a patch like this that also works on 16.04 Lubuntu LTS ?? Every time I have researched it over the years, there are variations on this theme. This should be a core functionality of each LTS package upon launch at minimum. What I am trying to get at, are the possibilities of even more helpful suggestions and options upon install, such as how large would you like /root to be? (say 1-5 GB) and how many old kernel versions would you like to keep (2-3 minimum as a safe default) Yes, pruning old kernels automagically could be dangerous, but more so is crashing 1/2 completed upgrades IMHO. Thanks to all!

[Jarno Suni (jarnos)]

sfrahm, were you installing updates by Software Updater, when this happened? If so, you could report a bug by `ubuntu-bug update-manager` in terminal. Tell it is likely a regression; in 14.04 it does not let you start update, if there is not enough room for kernels (at least always), but displays an error dialog instead. Please link the bug report here, if you make it.

If you were not using Software Updater at the time it happened, but the error occurred during automatic update, or during use of apt or apt-get, you can not blame update-manager.

IIRC the default size of /boot partition has been increased somewhat during past years. How big is your /boot (not /root) partition in 16.04 (df -H /boot --output=size)? If you want an option to choose even larger /boot partition during installation, please report a bug against the installer https://wiki.ubuntu.com/Ubiquity

Unfortunately removing old kernels does still not work well by default in 16.04. You can read about some options in comment #140.

[Jarno Suni (jarnos)]

This error may happen even when purging a kernel by dpkg:
https://paste.ubuntu.com/24280725/

[Jarno Suni (jarnos)]

I added a separate bug report for that case: Bug #1678187

[Piyush Kaila (pgkaila)]

I think this askUbuntu thread may help you.
http://askubuntu.com/questions/345588/what-is-the-safest-way-to-clean-up-boot-partition

[Tamera Gromala (tameragromala)]

i have an older powerful dell xps with lots of free space.. i believe my partitions are holding me up... i need to allocate more room for the program I believe... trying to figure out how... not totally a Ubuntu knower... but I can learn. :)

[Jarno Suni (jarnos)]

I think check for enough space could be done in dpkg. It might be just hard to estimate what is enough space, since the required space for initrd.img files depends on whether linux-image-extra packages are used, whether dkms is used and whether backup initrd.img files are generated. Maybe some environment variable could be used for the limit.

[Michael Baker (mbaker5153)]

On booting I am told that a system program has encountered an error and asked if I want to send a report. On saying yes I'm told that the bug has already been reported and that it is "update-initramfs should produce a more helpful error when there isn't enough free space".
This is so far from what is happening that it is infuriating.
The basis of the problem is that /boot is not being cleaned up automatically.
This was a bug which was supposedly fixed in 16.04 UTS, but apparently not.
As a retired software engineer I know that I can clean up /boot manually, and have done so many times.
However I shouldn't have to.
Please stop classifying the /boot partition being full as "update-initramfs should produce a more helpful error when there isn't enough free space".
This bug (/boot not being cleaned up automatically) should be given the highest possible importance.
It must be a complete turn of to any ubuntu user who does not have computer science skills (and to many who do).

[Bill Meier (wmeier)]

Why not just write a little GUI app for us , so that we "command line
illiterates" can take care of this. We need to select what we want
deleted, just getting rid of the old, I understand, may not be what is
wanted.

Bill

On 05/05/2017 03:13 AM, Michael Baker wrote:
> On booting I am told that a system program has encountered an error and asked if I want to send a report. On saying yes I'm told that the bug has already been reported and that it is "update-initramfs should produce a more helpful error when there isn't enough free space".
> This is so far from what is happening that it is infuriating.
> The basis of the problem is that /boot is not being cleaned up automatically.
> This was a bug which was supposedly fixed in 16.04 UTS, but apparently not.
> As a retired software engineer I know that I can clean up /boot manually, and have done so many times.
> However I shouldn't have to.
> Please stop classifying the /boot partition being full as "update-initramfs should produce a more helpful error when there isn't enough free space".
> This bug (/boot not being cleaned up automatically) should be given the highest possible importance.
> It must be a complete turn of to any ubuntu user who does not have computer science skills (and to many who do).
>

[PcB Computer Support (pc-t)]

give more space for /boot 1gb ?

PcB-iPhone Communication

Am 05.05.2017 um 13:09 schrieb Bill Meier <email address hidden>:

Why not just write a little GUI app for us , so that we "command line
illiterates" can take care of this. We need to select what we want
deleted, just getting rid of the old, I understand, may not be what is
wanted.

Bill

> On 05/05/2017 03:13 AM, Michael Baker wrote:
> On booting I am told that a system program has encountered an error and asked if I want to send a report. On saying yes I'm told that the bug has already been reported and that it is "update-initramfs should produce a more helpful error when there isn't enough free space".
> This is so far from what is happening that it is infuriating.
> The basis of the problem is that /boot is not being cleaned up automatically.
> This was a bug which was supposedly fixed in 16.04 UTS, but apparently not.
> As a retired software engineer I know that I can clean up /boot manually, and have done so many times.
> However I shouldn't have to.
> Please stop classifying the /boot partition being full as "update-initramfs should produce a more helpful error when there isn't enough free space".
> This bug (/boot not being cleaned up automatically) should be given the highest possible importance.
> It must be a complete turn of to any ubuntu user who does not have computer science skills (and to many who do).

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/798414

Title:
 update-initramfs should produce a more helpful error when there isn't
 enough free space

Status in initramfs-tools:
 Confirmed
Status in Software Updater:
 New
Status in dpkg package in Ubuntu:
 Invalid
Status in initramfs-tools package in Ubuntu:
 In Progress

Bug description:
 Binary package hint: initramfs-tools

 When generating a new initramfs there is no check for available free
 space, subsequently its possible for update-initramfs to fail due to a
 lack of free space. This is resulting in package installation
 failures for initramfs-tools. For example:

 Setting up initramfs-tools (0.98.8ubuntu3) ...
 update-initramfs: deferring update (trigger activated)
 Processing triggers for initramfs-tools ...
 update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic

 gzip: stdout: No space left on device
 E: mkinitramfs failure cpio 141 gzip 1
 update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
 dpkg: error processing initramfs-tools (--configure):
  subprocess installed post-installation script returned error exit status 1

 WORKAROUND:

 Remove unused kernels using computer janitor (not in repositories for
 14.04 or later) or manually free space on your partition containing
 the /boot file system.

 See instructions here
 https://help.ubuntu.com/community/RemoveOldKernels

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions

[Jarno Suni (jarnos)]

Michael Baker, the bug report Bug #1357093 that you referred to has been re-reported as Bug #1675079 and Bug #1624644

If you disable automatic installation of updates, and install them by Software Updater only, it will prevent you from installing kernel updates, retaining the system in intact state, if there is too little space left, and let you remove extra kernels by "sudo apt autoremove --purge" (in 16.04-), right?

Whatever front-end is used to install kernels, be it apt, unattended-upgrades whatnot, it should check if there is enough space for the kernel in /boot, to prevent system from becoming broken by the installation. It might be difficult in general, as initrd.img files size may vary depending on dkms, linux-image-extra whatnot and there may be backup initrd.img files generated, too.

[Jarno Suni (jarnos)]

Though even Software Updater could be more informative on how to free more space on /boot: Bug #1460396

[Jarno Suni (jarnos)]

Bill Meier, I think GUI application is not necessary. Text-based application may have checklist, too, so it is pretty easy to make a selection. Initramfs-tools may not run the application, but it could give hint to run one in its error message. The script I was talking about in #140 is such a script: 'sudo linux-purge --fix' would do that (interactively with you). The advantage of text-based application is that it can be used via ssh remotely. Your server might not even have GUI. In case of this bug, fixing of broken packages is always needed, so removing some kernels is not enough.

[Jarno Suni (jarnos)]

It would be easier to remove excessive kernels after this issue, if Bug #1678187 was fixed.

[rocky220 (rocky220)]

yes I relize now my second partition was no large enough, thanks
  Tibor

[Vonschutter (stephan-schutter)]

This is a critical error as it will result in kernel security updates not being applied. Less than 1% of users are able to resolve this issue on their own and will likely continue to operate unprotected.

[Sebastian Nohn (sebastian-nohn)]

dpkg -l linux-{image,headers}-* | awk '/^ii/{print $2}' | egrep '[0-9]+\.[0-9]+\.[0-9]+' | grep -v $(uname -r | cut -d- -f-2) | xargs sudo apt-get -y purge

[Jason Mast (jmast1)]

While it is helpful for new users to have to google shell commands and identify solutions to problems, this simply occurs too often. The solution is the same every time. It is repetitive and annoying,

the script could store the new and old information in different locations to avoid the lack of space, the boot could be made larger by default, options could be presented to the user rather than simply failing, backup information for old kernals could be stored elsewhere (and only the most recent moved to boot for compatibility) ... etc.

a sample dialog would be
"there is not enough space for the boot information, there are too many items being retained in /boot, but it is strongly suggested that you maintain some backup kernals as updates can cause issues with new or old hardware. Please choose the number of old backups to maintain and the frequency with which they should be replaced"
then have a dialog that lists options like (daily weekly monthly yearly and no backups) and an option to store them tarred in another location that does not fill up ... also it should list the size of the individual groups of files (by date) ... and it should explain that this is a kernal backup not a file backup

also boot should be bigger

and there should be a semipermanent configuration change listed on the forum rather than the delete old kernals solution - which is just a bandaid in that you will just have to repeatedly do it, because sometimes i just want to turn the thing on and play minecraft (and my timesink of choice is not system administration)

Anyway,the point of "automatic updates" is they happen automatically, and you dont have to mess with them, this bug forces you to mess with them

[Bill Meier (wmeier)]

I still think a simpler solution, one that all users, novice or newbie,
could use is a GUI that lists the pertinent information and allows
deletion of any older and unused kernels. This may offend some purists,
but to me, the idea is to make linux easy to use and maintain for those
that finally make the break from MicroSoft..

On 07/12/2017 02:14 PM, Jason Mast wrote:
> While it is helpful for new users to have to google shell commands and
> identify solutions to problems, this simply occurs too often. The
> solution is the same every time. It is repetitive and annoying,
>
> the script could store the new and old information in different
> locations to avoid the lack of space, the boot could be made larger by
> default, options could be presented to the user rather than simply
> failing, backup information for old kernals could be stored elsewhere
> (and only the most recent moved to boot for compatibility) ... etc.
>
> a sample dialog would be
> "there is not enough space for the boot information, there are too many items being retained in /boot, but it is strongly suggested that you maintain some backup kernals as updates can cause issues with new or old hardware. Please choose the number of old backups to maintain and the frequency with which they should be replaced"
> then have a dialog that lists options like (daily weekly monthly yearly and no backups) and an option to store them tarred in another location that does not fill up ... also it should list the size of the individual groups of files (by date) ... and it should explain that this is a kernal backup not a file backup
>
> also boot should be bigger
>
> and there should be a semipermanent configuration change listed on the
> forum rather than the delete old kernals solution - which is just a
> bandaid in that you will just have to repeatedly do it, because
> sometimes i just want to turn the thing on and play minecraft (and my
> timesink of choice is not system administration)
>
> Anyway,the point of "automatic updates" is they happen automatically,
> and you dont have to mess with them, this bug forces you to mess with
> them
>

[Jarno Suni (jarnos)]

I think the patch presented at https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1678187/comments/8
might give more helpful error message, since it avoids filling /boot as long as possible, thus the system is unlikely to run out of space while running mkinitramfs, but finds out, if the system lacks free space, and if it does, it tells the URL of the documentation page concerning removing old kernels.

P.S. The URL could be https://help.ubuntu.com/community/LowDiskOnBoot alternatively. (Luke W Faraone uses that in his merge proposal, and it redirects to the same document currently.)

[Jarno Suni (jarnos)]

Marked as invalid against Software Updater (i.e. update-manager) since there is a separate report for it: Bug #1460396

[Jarno Suni (jarnos)]

Similarly, it would be great, if unattended-upgrade, apt and whatnot package tool software could predict that the requested install will not fit in system and act accordingly. Then the error in post-installation script would not happen then. The size could be hard to know in general case. If I have understood correctly, Software Updater uses information about older kernels as basis for calculating such a limit.

[Jarno Suni (jarnos)]

/boot may become full already in unpacking stage when installing a new kernel by dpkg. I think the error message could be more helpful in that case, too. The following video demonstrates such a case. It also demonstrates how the aforementioned linux-purge script can be used to fix system
https://youtu.be/gozw6A3qwCY

[Jarno Suni (jarnos)]

Another example where /boot gets full even before running update-initramfs:
https://askubuntu.com/q/946875/21005

[Thomas Schweikle (tps)]

Ubuntu keeps to many old kernel-images and initrd within /boot. Space is exausted and it fails to delete old unused kernels before creating a new initrd failing building an initrd for the newly installed kernel.

A workaround is to delete all old unused kernels and then try it again. It will succeed.

[Said Bakr (said-fox)]

The problem message stated that /boot has no enough free space and by checking the partition with Disk Usage Analyzer it states that free space is 6.6 MB only.

After using sudo apt-get autoremove --purge as suugested in https://help.ubuntu.com/community/RemoveOldKernels , it becomes 137.9 MB free.

[Steve Holton (sph0lt0n)]

IMPACT:

Some systems report the problem detected (requesting a bug report andtriggering a visit to this page) even when /boot has available free space:

sholton@sholton-VirtualBox:~$ df -H /boot
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 487M 127M 330M 28% /boot

sholton@sholton-VirtualBox:~$ sudo apt autoremove --purge
[sudo] password for sholton:
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Is there a related bug which indicates a system problem even when the original problem has been corrected?

[Timo Collinger (timo-collinger)]

I am not up-to high level changes/updates , it's "Beyond" my capabilities.

[Jarno Suni (jarnos)]

Steve Holton, maybe you are using Ubuntu 14.04 and have some manually installed kernels, see Bug #1089195.
Do updated instructions at https://help.ubuntu.com/community/RemoveOldKernels help to fix your system? (I suggest trying linux-purge, which I have written.)

[Scott Alan Barker (barkerir)]

 UBUNTU I DON'T use that system anymore 4 or 5 years ago I'M TIRED of having headaches. Keep your BUGZILLA  & WORMS with you. HaHa    On Wednesday, December 27, 2017, 9:09:59 AM EST, <email address hidden> <email address hidden> wrote:

 ** Changed in: initramfs-tools (Ubuntu)
      Status: Confirmed => Fix Released

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/798414

Title:
  update-initramfs should produce a more helpful error message when
  there isn't enough  free space

Status in initramfs-tools:
  Confirmed
Status in Ubuntu Software Center:
  Invalid
Status in dpkg package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: initramfs-tools

  When installing a kernel, /boot may become full during execution of
  post-installation script typically when update-initramfs is creating
  or updating an initrd.img file. This is resulting in kernel
  installation error.  For example:

  Setting up initramfs-tools (0.98.8ubuntu3) ...
  update-initramfs: deferring update (trigger activated)
  Processing triggers for initramfs-tools ...
  update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic

  gzip: stdout: No space left on device
  E: mkinitramfs failure cpio 141 gzip 1
  update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
  dpkg: error processing initramfs-tools (--configure):
   subprocess installed post-installation script returned error exit status 1

  Ideal behavior:

  Give a more helpful error message when this unfortunate situation
  occurs so that user can fix the broken system and keep it going.

  Workaround:

  As the bug reporting system forwards user to this bug report, such instructions can be given here:
  https://help.ubuntu.com/community/RemoveOldKernels

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions

[natalieaoneal (natalieaoneal)]

/boot was full, so I moved one file 'initrd.img-4.10.0-27-generic' from /boot to /tmp and ran:

sudo apt autoremove

This prompted the crash that I reported.

[natalieaoneal (natalieaoneal)]

Added note: sudo apt install byobu;sudo purge-old-kernels
seems to be resolving the /boot space issue.

[Thomas Schweikle (tps)]

The boot space problem is not resolved by purge-old-kernels, since this command does not remove old initrd from kernels not installed any more. purge-old-kernels shall remove any initrd from kernels it removes!

[liz Phillips (iamliz-phillips-z)]

Is there a way of unsubscribing from the emails ? I am afraid they are way
beyond my ability level, but I cannot unsubscribe from the emails.
Thank you in advance!
Liz Phillips

[pwaring (launchpad-pwaring)]

Liz: There are two options towards the top-right of the page, underneath the list of bug duplicates:

Mute bug mail - Click this to stop any emails from this bug (you'll remain subscribed so it will show in your list of bugs on Launchpad)

Edit bug mail - Click this to control which emails you get, e.g. you can stop getting comments but continue to be notified of changes to the bug status.

[liz Phillips (iamliz-phillips-z)]

Many thanks!
Liz

On 27 Feb 2018 11:57, "pwaring" <email address hidden> wrote:

Liz: There are two options towards the top-right of the page, underneath
the list of bug duplicates:

Mute bug mail - Click this to stop any emails from this bug (you'll
remain subscribed so it will show in your list of bugs on Launchpad)

Edit bug mail - Click this to control which emails you get, e.g. you can
stop getting comments but continue to be notified of changes to the bug
status.

--
You received this bug notification because you are subscribed to a
duplicate bug report (733765).
https://bugs.launchpad.net/bugs/798414

Title:
  update-initramfs should produce a more helpful error message when
  there isn't enough free space

Status in initramfs-tools:
  Confirmed
Status in Ubuntu Software Center:
  Invalid
Status in dpkg package in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: initramfs-tools

  When installing a kernel, /boot may become full during execution of
  post-installation script typically when update-initramfs is creating
  or updating an initrd.img file. This is resulting in kernel
  installation error. For example:

  Setting up initramfs-tools (0.98.8ubuntu3) ...
  update-initramfs: deferring update (trigger activated)
  Processing triggers for initramfs-tools ...
  update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic

  gzip: stdout: No space left on device
  E: mkinitramfs failure cpio 141 gzip 1
  update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
  dpkg: error processing initramfs-tools (--configure):
   subprocess installed post-installation script returned error exit status
1

  Ideal behavior:

  Give a more helpful error message when this unfortunate situation
  occurs so that user can fix the broken system and keep it going.

  Workaround:

  As the bug reporting system forwards user to this bug report, such
instructions can be given here:
  https://help.ubuntu.com/community/RemoveOldKernels

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions

[Jarno Suni (jarnos)]

natalieaoneal, in Artful purge-old-kernels simply runs "sudo apt-get autoremove". See Bug #1686138

[M G (mgudarzi)]

I just cleaned up my /boot (old kernels and stuff) and Baaaang! worked like a charm.

[Jarno Suni (jarnos)]

M G, which method you used?

[Indraneel Basu Majumdar (indraneel-bm)]

this is still too difficult for a newbie to linux with no programming expertise to understand and apply: can it be made simpler by version as to what commands do we need to execute and what steps do we need to take. Thank you for your understanding

[M G (mgudarzi)]

check /boot to see what are your old kernels that you're not necessarily using. the system keeps two latest kernels. so if you're upgrading your kernel to 4.13.0-38, you don't need 4.13.0-36 or older anymore( unless you want a specific kernel for testing or something ), so you can delete em.

/boot$[sudo] rm -rf *4.13.0-36 (or older ones, depending on what you have **don't delete the ones you use or need**)

after that:

sudo apt-get update && sudo apt-get dist-upgrade

sudo apt-get auto remove

these should do it.

please be careful with rm -rf(it can be pretty devastating if you type wrong things in there)

[M G (mgudarzi)]

oh, you the correct first command is :
/boot$[sudo] rm -rf *4.13.0-36*
(or older ones, depending on what you have **really, don't delete the ones you use or need**)

[Tex Arcana (tex.arcana)]

I just ran into this bug, tried a suggestion from here (https://askubuntu.com/questions/89710/how-do-i-free-up-more-space-in-boot) which resulted in multiple errors, and me being sent here.

It seems to me that this should be taken care of automatically by the kernel with the upgrading process.

========================================================
Terminal output of the above suggested method:
========================================================

XXXXXXXXXX@XXXXXXXXXXX-System-Product-NameXXXXXXXXX-XXX:~$ uname -r
4.15.0-29-generic
XXXXXXXXXX@XXXXXXXXXXX-System-Product-NameXXXXXXXXXX-XXX:~$ dpkg -l linux-{image,headers}-"[0-9]*" | awk '/^ii/{ print $2}' | grep -v -e `uname -r | cut -f1,2 -d"-"` | grep -e '[0-9]'
linux-headers-4.13.0-36
linux-headers-4.13.0-36-generic
linux-headers-4.13.0-38
linux-headers-4.13.0-38-generic
linux-headers-4.13.0-39
linux-headers-4.13.0-39-generic
linux-headers-4.13.0-45
linux-headers-4.13.0-45-generic
linux-headers-4.15.0-24
linux-headers-4.15.0-24-generic
linux-headers-4.15.0-30
linux-headers-4.15.0-30-generic
linux-image-4.13.0-36-generic
linux-image-4.13.0-38-generic
linux-image-4.13.0-39-generic
linux-image-4.13.0-45-generic
linux-image-4.15.0-24-generic
linux-image-4.15.0-30-generic
XXXXXXXXX@XXXXXXXXX-System-Product-NameXXXXXXXXXXXX-XXX:~$ dpkg -l linux-{image,headers}-"[0-9]*" | awk '/^ii/{ print $2}' | grep -v -e `uname -r | cut -f1,2 -d"-"` | grep -e '[0-9]' | xargs sudo apt-get -y purge
[sudo] password for XXXXXXXXXXXXXXX:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  amd64-microcode intel-microcode iucode-tool libllvm5.0 libllvm5.0:i386
  linux-modules-4.15.0-24-generic
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  linux-generic-hwe-16.04* linux-headers-4.13.0-36*
  linux-headers-4.13.0-36-generic* linux-headers-4.13.0-38*
  linux-headers-4.13.0-38-generic* linux-headers-4.13.0-39*
  linux-headers-4.13.0-39-generic* linux-headers-4.13.0-45*
  linux-headers-4.13.0-45-generic* linux-headers-4.15.0-24*
  linux-headers-4.15.0-24-generic* linux-headers-4.15.0-30*
  linux-headers-4.15.0-30-generic* linux-headers-generic-hwe-16.04*
  linux-image-4.13.0-36-generic* linux-image-4.13.0-38-generic*
  linux-image-4.13.0-39-generic* linux-image-4.13.0-45-generic*
  linux-image-4.15.0-24-generic* linux-image-4.15.0-30-generic*
  linux-image-extra-4.13.0-36-generic* linux-image-extra-4.13.0-38-generic*
  linux-image-extra-4.13.0-39-generic* linux-image-extra-4.13.0-45-generic*
  linux-image-generic-hwe-16.04* linux-modules-extra-4.15.0-24-generic*
  linux-modules-extra-4.15.0-30-generic*
0 upgraded, 0 newly installed, 27 to remove and 13 not upgraded.
After this operation, 1,830 MB disk space will be freed.
(Reading database ... 424923 files and directories currently installed.)
Removing linux-generic-hwe-16.04 (4.15.0.30.52) ...
Removing linux-headers-4.13.0-36-generic (4.13.0-36.40~16.04.1) ...
Removing linux-headers-4.13.0-36 (4.13.0-36.40~16.04.1) ...
Removing linux-headers-4.13.0-38-generic (4.13.0-38.43~16.04.1) ...
Removing linux-...

[Jarno Suni (jarnos)]

Tex, the command you used failed because of Bug #1678187. However it succeeded to purge many kernels and related packages. But package linux-image-extra-4.13.0-36-generic was not successfully purged technically. What does command 'dpkg -l linux-image-extra-4.13.0-36-generic' print? Anyway, you can now purge the package by 'sudo dpkg --purge linux-image-extra-4.13.0-36-generic', right?

I suppose your original command purged too many packages, as it removed the linux-generic-hwe-16.04 package. You may reinstall it by 'sudo apt-get install --install-recommends linux-generic-hwe-16.04', if you want to continue to get newer kernels via updates. (https://wiki.ubuntu.com/Kernel/LTSEnablementStack#Ubuntu_16.04_LTS_-_Xenial_Xerus)

[C W (cwoooodruf)]

The default boot partition size in Ubuntu 16 is way too small so having some way to remove the oldest kernel is required I think. Its very hard to change it once the disk is in use.

[Jarno Suni (jarnos)]

cwoooodruf, luckily, there are some ways.

[BlaWhickte (blawhickte)]

THANKS FOR YOUR REPLIED. IT WAS FIXED

Jarno Suni <email address hidden> 于2019年1月1日周二 下午8:39写道：

> cwoooodruf, luckily, there are some ways.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/798414
>
> Title:
> update-initramfs should produce a more helpful error message when
> there isn't enough free space--or provide an automatic tool for
> removal of old files
>
> Status in initramfs-tools:
> New
> Status in Ubuntu Software Center:
> Invalid
> Status in Ubuntu:
> Fix Released
> Status in dpkg package in Ubuntu:
> Invalid
> Status in initramfs-tools package in Ubuntu:
> Fix Released
>
> Bug description:
> Binary package hint: initramfs-tools
>
> When installing a kernel, /boot may become full during execution of
> post-installation script typically when update-initramfs is creating
> or updating an initrd.img file. This is resulting in kernel
> installation error. For example:
>
> Setting up initramfs-tools (0.98.8ubuntu3) ...
> update-initramfs: deferring update (trigger activated)
> Processing triggers for initramfs-tools ...
> update-initramfs: Generating /boot/initrd.img-2.6.38-8-generic
>
> gzip: stdout: No space left on device
> E: mkinitramfs failure cpio 141 gzip 1
> update-initramfs: failed for /boot/initrd.img-2.6.38-8-generic
> dpkg: error processing initramfs-tools (--configure):
> subprocess installed post-installation script returned error exit
> status 1
>
> Ideal behavior:
>
> Give a more helpful error message when this unfortunate situation
> occurs so that user can fix the broken system and keep it going.
>
> Workaround:
>
> As the bug reporting system forwards user to this bug report, such
> instructions can be given here:
> https://help.ubuntu.com/community/RemoveOldKernels
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/initramfs-tools/+bug/798414/+subscriptions
>

[Mathew Hodson (mhodson)]

A better fix for this issue is available in Bionic and later and also backported to Xenial with bug 1675079.

unattended-upgrades and update-manager will now remove unused kernel packages when there are other updates to be installed.

I'm closing this initramfs-tools task since a fix specifically for this initramfs-tools package isn't needed now.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/798414

[Raghvendra Giri (crusader5)]

The solution is listed in ubuntu documentation.

first check space of /boot

>: df -h

>: sudo apt-get autoremove

this should freeup some space and 90% times this will resolve your issue.

if you have manually installed and still the old files are not purged follow the link below

https://help.ubuntu.com/community/RemoveOldKernels

this still works for ubunt 22.04 /boot folder issues resolution, cleaning /boot folder removing older files

[Raghvendra Giri (crusader5)]

If you are doing manual partitioning keep at least 1gb space for /boot partition.
update for above post