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

Bug #798414 reported by Brian Murray on 2011-06-16
This bug affects 353 people
Affects Status Importance Assigned to Milestone
Ubuntu Software Center
Invalid
Undecided
Unassigned
initramfs-tools
Undecided
Unassigned
dpkg (Ubuntu)
Undecided
Unassigned
initramfs-tools (Ubuntu)
Medium
Deon Joubert

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

Related branches

description: updated
kireol (kireol) wrote :

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) 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.

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
>

summary: - update-initramfs does not check for free space
+ update-initramfs should produce a more helpful error when there isn't
+ enough free space
Changed in initramfs-tools (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Ubuntu Foundations Team (ubuntu-foundations-team)

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

before sudo aptitude autoremove

Christian Mertes (cmertes) wrote :

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) wrote :

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) wrote :

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) wrote :
Download full text (3.5 KiB)

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...

Read more...

Changed in initramfs-tools (Ubuntu):
status: Triaged → Incomplete
Steve Langasek (vorlon) on 2013-03-01
Changed in initramfs-tools (Ubuntu):
status: Incomplete → Triaged

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.

Changed in initramfs-tools (Ubuntu):
assignee: Ubuntu Foundations Team (ubuntu-foundations-team) → nobody
Redoubts (redoubts) wrote :

@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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

markling (markling) wrote :

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) wrote :

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) wrote :

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

Tim Fisher (k2trf) wrote :

@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) 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...

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.

@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.

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :
Download full text (6.9 KiB)

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...

Read more...

markling (markling) wrote :

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) wrote :

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) wrote :

"sudo apt-get autoremove" works for me.

Thanks!

Redoubts (redoubts) wrote :

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) wrote :

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

Changed in wine (Ubuntu):
status: New → Confirmed
no longer affects: wine (Ubuntu)
affects: initramfs-tools (Ubuntu) → initramfs-tools-ubuntu-touch (Ubuntu)
affects: initramfs-tools-ubuntu-touch (Ubuntu) → initramfs-tools (Ubuntu)
David Burrows (d-m123) wrote :

I need help with Ubuntu and Skip ,downloads etc.

@Mark Russell:

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

Norbert (nrbrtx) on 2014-07-18
tags: added: precise trusty
Mick (4mer-sin-r) wrote :

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) wrote :

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"

Changed in initramfs-tools (Ubuntu):
status: Triaged → Incomplete
Changed in initramfs-tools:
status: New → Incomplete
Changed in initramfs-tools (Ubuntu):
status: Incomplete → Triaged
Changed in initramfs-tools:
status: Incomplete → Confirmed
Kamal Wanas (kamalwanas) on 2014-12-02
Changed in initramfs-tools:
assignee: nobody → Kamal Wanas (kamalwanas)
status: Confirmed → Fix Committed
Changed in initramfs-tools (Ubuntu):
status: Triaged → Fix Committed
Richard Hansen (rhansen) on 2014-12-06
Changed in initramfs-tools:
assignee: Kamal Wanas (kamalwanas) → nobody
status: Fix Committed → Confirmed
Changed in initramfs-tools (Ubuntu):
status: Fix Committed → Confirmed
Bill Meier (wmeier) wrote :

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.

Kamal Wanas (kamalwanas) on 2014-12-18
Changed in initramfs-tools:
status: Confirmed → Fix Released
Changed in initramfs-tools (Ubuntu):
status: Confirmed → Fix Released
Jonathan Harker (jesusaurus) wrote :

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?

felix (abnercontreras11) on 2014-12-25
affects: initramfs-tools (Ubuntu) → cloud-initramfs-tools (Ubuntu)
Richard Hansen (rhansen) on 2014-12-31
affects: cloud-initramfs-tools (Ubuntu) → initramfs-tools (Ubuntu)
Adolfo Jayme (fitojb) on 2015-01-05
Changed in initramfs-tools (Ubuntu):
status: Fix Released → Triaged
felix (abnercontreras11) on 2015-01-08
Changed in initramfs-tools (Ubuntu):
status: Triaged → Incomplete
status: Incomplete → Confirmed
status: Confirmed → Incomplete
William Grant (wgrant) on 2015-01-08
Changed in initramfs-tools (Ubuntu):
status: Incomplete → Triaged
vanvan (bartel-vanessa) on 2015-02-05
Changed in initramfs-tools:
assignee: nobody → vanvan (bartel-vanessa)
Richard Hansen (rhansen) on 2015-02-07
Changed in initramfs-tools:
assignee: vanvan (bartel-vanessa) → nobody
Javier Arias (jareche1) on 2015-04-05
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Javier Arias (jareche1)
affects: initramfs-tools → ubuntu
Richard Hansen (rhansen) on 2015-05-18
affects: ubuntu → initramfs-tools
affects: initramfs-tools → null-and-void
Changed in initramfs-tools:
status: New → Confirmed
Changed in initramfs-tools (Ubuntu):
assignee: Javier Arias (jareche1) → nobody
aurelio76 (oskarbronski) on 2015-06-12
Changed in initramfs-tools (Ubuntu):
assignee: nobody → aurelio76 (oskarbronski)
Changed in initramfs-tools (Ubuntu):
assignee: aurelio76 (oskarbronski) → nobody
Lucy (lucy8711) on 2015-07-01
Changed in initramfs-tools (Ubuntu):
status: Triaged → Incomplete
Richard Hansen (rhansen) on 2015-07-01
Changed in initramfs-tools (Ubuntu):
status: Incomplete → Confirmed
omesalim (omesalim) on 2015-07-08
Changed in initramfs-tools (Ubuntu):
assignee: nobody → omesalim (omesalim)
Csaba (antalcsaba) on 2015-08-12
affects: null-and-void → ubuntu
Changed in ubuntu:
assignee: nobody → PcB (pc-t)
Taluk (terlukropuk23) on 2015-10-07
Changed in initramfs-tools:
assignee: nobody → Taluk (terlukropuk23)
Csaba (antalcsaba) on 2015-11-05
Changed in initramfs-tools:
assignee: Taluk (terlukropuk23) → nobody
Luke Faraone (lfaraone) on 2015-11-16
no longer affects: ubuntu
Changed in initramfs-tools (Ubuntu):
assignee: omesalim (omesalim) → nobody
Ads20000 (ads20000) on 2015-11-25
description: updated
Changed in initramfs-tools:
status: Confirmed → Fix Released
Changed in initramfs-tools (Ubuntu):
status: Confirmed → Fix Released
Changed in initramfs-tools (Ubuntu):
assignee: nobody → PIAOWAKA WINDWOLF (wayshowerwolf)
Changed in initramfs-tools (Ubuntu):
assignee: PIAOWAKA WINDWOLF (wayshowerwolf) → nobody
status: Fix Released → Triaged
Joe (jrhodgeneo74) on 2015-12-08
Changed in initramfs-tools:
assignee: nobody → Joe (jrhodgeneo74)
Richard Hansen (rhansen) on 2015-12-08
Changed in initramfs-tools:
assignee: Joe (jrhodgeneo74) → nobody
no longer affects: initramfs-tools
Changed in initramfs-tools:
status: New → Confirmed
Changed in initramfs-tools:
status: Confirmed → New
Changed in initramfs-tools (Ubuntu):
status: Triaged → Confirmed
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Kishor Kansara (kansarakishor)
Changed in initramfs-tools (Ubuntu):
assignee: Kishor Kansara (kansarakishor) → nobody
status: Confirmed → Triaged
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Kishor Kansara (kansarakishor)
Richard Hansen (rhansen) on 2016-05-02
Changed in initramfs-tools (Ubuntu):
assignee: Kishor Kansara (kansarakishor) → nobody
Changed in initramfs-tools:
status: New → Confirmed
Changed in initramfs-tools:
assignee: nobody → Timothy Ricks (timothy-ricks)
Luke Faraone (lfaraone) on 2016-05-24
Changed in initramfs-tools:
assignee: Timothy Ricks (timothy-ricks) → nobody
Luke Faraone (lfaraone) on 2016-05-26
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Luke Faraone (lfaraone)
status: Triaged → In Progress
Changed in initramfs-tools (Ubuntu):
assignee: Luke Faraone (lfaraone) → Boguslav Vantola (b-vantola)
Jarno Suni (jarnos) on 2016-07-21
description: updated
Luke Faraone (lfaraone) on 2016-07-22
Changed in initramfs-tools (Ubuntu):
assignee: Boguslav Vantola (b-vantola) → Luke Faraone (lfaraone)
Changed in initramfs-tools:
assignee: nobody → Kishor Kansara (kansarakishor)
Changed in initramfs-tools:
assignee: Kishor Kansara (kansarakishor) → nobody
Changed in initramfs-tools (Ubuntu):
assignee: Luke Faraone (lfaraone) → nobody
sauro peña (sauropm) on 2016-10-24
Changed in initramfs-tools:
assignee: nobody → sauro peña (sauropm)
Luke Faraone (lfaraone) on 2016-10-25
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Luke Faraone (lfaraone)
Changed in initramfs-tools:
assignee: sauro peña (sauropm) → nobody
Jarno Suni (jarnos) on 2016-12-02
description: updated
96 comments hidden view all 176 comments
Jarno Suni (jarnos) wrote :

"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.

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) wrote :

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) wrote :

"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-.

gintassi (gintassi) on 2017-01-18
Changed in initramfs-tools:
assignee: nobody → gintassi (gintassi)
Changed in initramfs-tools (Ubuntu):
assignee: Luke Faraone (lfaraone) → gintassi (gintassi)
Luke Faraone (lfaraone) on 2017-01-19
Changed in initramfs-tools:
assignee: gintassi (gintassi) → nobody
Changed in initramfs-tools (Ubuntu):
assignee: gintassi (gintassi) → Luke Faraone (lfaraone)
richud (richud.com) wrote :

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

@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) wrote :

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) wrote :

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

1 comments hidden view all 176 comments
s frahm (sfrahm) wrote :

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) wrote :

sfrahm, I do you mean Bug #1460396.

s frahm (sfrahm) wrote :

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) wrote :

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.

Changed in initramfs-tools:
status: Confirmed → Incomplete
status: Incomplete → Opinion
William Grant (wgrant) on 2017-03-28
Changed in initramfs-tools:
status: Opinion → Confirmed
Jarno Suni (jarnos) wrote :

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

Jarno Suni (jarnos) wrote :

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

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) wrote :

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.

Adam Conrad (adconrad) on 2017-04-24
Changed in dpkg (Ubuntu):
status: New → Invalid
Michael Baker (mbaker5153) 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).

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) wrote :

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

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) wrote :

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

Jarno Suni (jarnos) wrote :

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) wrote :

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

Jarno Suni (jarnos) on 2017-05-20
description: updated
summary: - update-initramfs should produce a more helpful error when there isn't
- enough free space
+ update-initramfs should produce a more helpful error message when there
+ isn't enough free space
rocky220 (rocky220) wrote :

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

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.

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) 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

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
>

Tikshala (tikshala917) on 2017-07-30
Changed in initramfs-tools (Ubuntu):
assignee: Luke Faraone (lfaraone) → nobody
status: In Progress → Incomplete
Changed in initramfs-tools (Ubuntu):
status: Incomplete → Confirmed
status: Confirmed → Incomplete
Steve Langasek (vorlon) on 2017-08-02
Changed in initramfs-tools (Ubuntu):
status: Incomplete → Confirmed
Jarno Suni (jarnos) wrote :

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) wrote :

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

Changed in update-manager:
status: New → Invalid
Jarno Suni (jarnos) wrote :

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.

lizehao (lllwonder) on 2017-08-08
Changed in initramfs-tools (Ubuntu):
assignee: nobody → lizehao (lllwonder)
Jarno Suni (jarnos) wrote :

/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) wrote :

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

affects: update-manager → software-center
Thomas Schweikle (tps) wrote :

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.

Deon Joubert (02deon-j) on 2017-11-16
Changed in initramfs-tools (Ubuntu):
assignee: lizehao (lllwonder) → Deon Joubert (02deon-j)
Said Bakr (said-fox) wrote :

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) wrote :

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?

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

Jarno Suni (jarnos) wrote :

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.)

Changed in initramfs-tools:
status: Confirmed → Incomplete
status: Incomplete → Opinion
Colin Watson (cjwatson) on 2017-12-15
Changed in initramfs-tools:
status: Opinion → Confirmed
Displaying first 40 and last 40 comments. View all 176 comments or add a comment.