Removing a linux-image-extra package fails, if /boot is about full

Bug #1678187 reported by Jarno Suni on 2017-03-31
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Undecided
Unassigned

Bug Description

System calls /etc/kernel/postinst.d/initramfs-tools when purging/removing a linux-image-extra package. That calls "update-initramfs -c" which needs significant amount of additional disk space in /boot temporarily. But there is no space left, if /boot is full.

Likewise /etc/kernel/postinst.d/dkms may call "update-initramfs -u".

The fix could be to create the new initrg.img file in different partition before replacing the old one by it in update-initramfs. So the update-initramfs script should be fixed. But there may not be such a partition..
Anyway the likely case when space runs out is when there is a separate /boot partition.

Alternatively the init scripts should remove the respective /boot/initrd.img-<version> file when removing/installing the linux-image-extra package. That could also be done by
update-initramfs -d -k <version>
That may be worse way, as then initrd.img file is missing for longer period of time and system integrity may suffer in case of e.g. power cut.

Related question: http://askubuntu.com/q/898499/21005
The output of 'dpkg --purge' presented there shows that corresponding linux-image package may get successfully removed while the linux-image-extra is left broken. If the linux-image-extra package will be removed later, the post-installation script will create an initrd.img file for a non-installed kernel! Same would happen, if removing would be done by apt-get purge.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: initramfs-tools 0.103ubuntu4.7
ProcVersionSignature: Ubuntu 4.4.0-71.92~14.04.1-generic 4.4.49
Uname: Linux 4.4.0-71-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.23
Architecture: amd64
CurrentDesktop: XFCE
Date: Fri Mar 31 17:42:35 2017
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-09-21 (922 days ago)
InstallationMedia: Ubuntu-Studio 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.1)
PackageArchitecture: all
SourcePackage: initramfs-tools
UpgradeStatus: No upgrade log present (probably fresh install)

Jarno Suni (jarnos) wrote :
Jarno Suni (jarnos) on 2017-04-07
summary: - update-initramfs requires more space in /boot when removing a linux-
- image-extra package
+ dpkg fails to remove a linux-image-extra package, if /boot is about full
Jarno Suni (jarnos) on 2017-04-24
description: updated

What triggers a postinst script when removing a linux-image-extra package by dpkg?

Adam Conrad (adconrad) on 2017-04-24
Changed in dpkg (Ubuntu):
status: New → Invalid
Jarno Suni (jarnos) wrote :

dpkg may also fail to install a linux-image-extra package, because "update-initramfs -c" needs more space for initrd.img in /boot temporarily, even if the new initrd.img would fit when the old one has been removed.

Jarno Suni (jarnos) on 2017-05-02
description: updated
Jarno Suni (jarnos) on 2017-05-04
description: updated
Jarno Suni (jarnos) wrote :

I managed to change update-initramfs in my computer so that it uses a temporary location (temporarily) for new initrd.img file thus behaving better in case of separate /boot partition and low disk space there.

Jarno Suni (jarnos) on 2017-05-11
summary: - dpkg fails to remove a linux-image-extra package, if /boot is about full
+ Removing a linux-image-extra package fails, if /boot is about full
description: updated
Jarno Suni (jarnos) on 2017-05-19
description: updated
Jarno Suni (jarnos) wrote :

Maybe also dkms may need more space on /boot when updating and backing up initrd.img?

Jarno Suni (jarnos) on 2017-05-20
description: updated
Jarno Suni (jarnos) on 2017-05-22
description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in initramfs-tools (Ubuntu):
status: New → Confirmed
spike speigel (frail-knight) wrote :

Not sure if using dkms, but if so may be related to bug 1515513

The attachment "patch concerning generate_initramfs function in update_initramfs" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Jarno Suni (jarnos) wrote :

This patch is better, because it takes into account the size of possible existing initramfs file when calculating the needed available free space.

tags: added: full-boot
Brian Murray (brian-murray) wrote :

I tried recreating this in Ubuntu 17.04 by having three kernels installed on a /boot partition with only 11M of free space left. I then used 'sudo apt autoremove' which removed my oldest kernel, including linux-image-extra-4.10.0-19-generic, and did not run into any issues. Is this issue specific to only removing the linux-image-extra package or does it only affect Ubuntu 16.04.?

Could you please provide some detailed steps to recreate this bug? Thanks in advance.

Brian Murray (brian-murray) wrote :

Using the same procedure I was unable to recreate this on Ubuntu 16.04.

Changed in initramfs-tools (Ubuntu):
status: Confirmed → Incomplete
Jarno Suni (jarnos) wrote :

Tested in 16.04

Lower free space at /boot to 10MB by the following one-liner:

sudo dd if=/dev/zero of=/boot/tmpfile bs=1MB count=$(($(stat -f --format="%f*%S" /boot)/1000000-10))

Then remove a linux-image-extra package by apt, e.g.

sudo apt purge linux-image-extra-4.10.0-19-generic

Check status of the package:

dpkg -l linux-image-extra-4.10.0-19-generic

(If you run

sudo apt purge linux-image-4.10.0-19-generic

There is an error, too, but the requested package will be removed. Running 'sudo apt install' thereafter finishes removing the linux-image-extra package.)

Remember to remove the created temporary file:

sudo rm /boot/tmpfile

Brian Murray (brian-murray) wrote :

I've recreated this on Ubuntu 16.04 now, it seems that the missing bit was creating a sufficiently small enough amount of free space on my /boot partition.

While running 'sudo apt install' did finish the removal and I was able to continue using apt, I did notice that I had a leftover / abandoned initrd.img-4.4.0-31-generic.

Jarno Suni (jarnos) wrote :

Then not incomplete anymore?

Changed in initramfs-tools (Ubuntu):
status: Incomplete → Confirmed
Brian Murray (brian-murray) wrote :

I think source of the problem here is bug 1501844 and removing a linux-image-extra package causes update-initramfs to be run. If the kernel package maintainer scripts were written differently then removing linux-image and linux-image-extra would not have a problem if /boot was full, but removing linux-image-extra by itself would still be an issue as update-initramfs would be run.

Jarno Suni (jarnos) wrote :

There is no bug with that number.

Jarno Suni (jarnos) wrote :

For some reason with my patch mv may fail even if I try to make sure mv will not be run, if there is not enough space on /boot:

Setting up linux-generic-lts-xenial (4.4.0.97.81) ...
Processing triggers for initramfs-tools (0.103ubuntu4.8) ...
update-initramfs: Generating /boot/initrd.img-4.4.0-97-generic
W: TMPDIR is mounted noexec, will not cache run scripts.
mv: error writing '/boot/initrd.img-4.4.0-97-generic': No space left on device
mv: failed to extend '/boot/initrd.img-4.4.0-97-generic': No space left on device
update-initramfs: failed for /boot/initrd.img-4.4.0-97-generic with mv returning 1.
Backup file /boot/initrd.img-4.4.0-97-generic.dpkg-bak remains.
dpkg: error processing package initramfs-tools (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

Jarno Suni (jarnos) wrote :

As for the patch, the following test shows that a file stored in /boot may require significantly more available space than the same file in /var/tmp, even if blocksize in (partition containing) /var/tmp is bigger. I don't know what is the best way to estimate how much available space is needed for storing a file in /boot.

$ echo $TMPDIR

$ echo $(( $(stat -f --format='%S' /boot ) ))
1024
$ echo $(( $(stat -f --format='%S' /var/tmp/ ) ))
4096
sudo dd if=/dev/zero of=/boot/file bs=K count=35553
35553+0 records in
35553+0 records out
36406272 bytes (36 MB) copied, 0,334945 s, 109 MB/s
$ sudo dd if=/dev/zero of=/var/tmp/file bs=K count=35553
35553+0 records in
35553+0 records out
36406272 bytes (36 MB) copied, 0,171743 s, 212 MB/s
$ echo $(( $(stat --format='%b*%B' /var/tmp/file ) ))
36409344
$ echo $(( $(stat --format='%b*%B' /boot/file ) ))
36549632

Jarno Suni (jarnos) wrote :

A new attempt to estimate required space in /boot.

no longer affects: dpkg (Ubuntu)
Launchpad Janitor (janitor) wrote :

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

Changed in ubuntu:
status: New → Confirmed
affects: initramfs-tools → ubuntu
no longer affects: ubuntu
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers