Ubuntu
partman-auto-crypto package

possible to run out of space on /boot partition when installed using auto recipe & full-disk-encryption

Bug #1067106 reported by Mark Russell on 2012-10-15

This bug report is a duplicate of: Bug #1675079: 16.04 LTS Partition /boot fills up with Kernel images, gets underwear in a twist. Edit Remove

This bug affects 10 people

	Status	Importance	Assigned to
partman-auto-crypto (Ubuntu)	Confirmed	Medium	Unassigned
Quantal	Won't Fix	Undecided	Unassigned
Saucy	Won't Fix	Undecided	Unassigned

Bug Description

When choosing full disk encryption in the quantal version of Ubiquity, the resulting /boot partition seems small.

In my test installation /boot came to 228MB.

Assuming that each kernel+initrd comes to about 30MB, that doesn't leave much space for old kernels/initrds as kernel upgrades pile-up.

Many users do not know how to clear old kernels. A full /boot will mean that no further apt transactions can occur until older kernels are removed and the newer kernel installation is completed. Users will then be missing out on security updates, hardware enablements, and installing new packages.

See original description

Revision history for this message

Mark Russell (marrusl) wrote on 2012-10-15:

I'm assuming this is too late for Quantal. I'm suggesting this change for R. Thanks.

tags:

removed: quantal

Mark Russell (marrusl) on 2012-10-15

description:

updated

Dimitri John Ledkov (xnox) on 2012-10-15

summary:	- /boot partition should be larger when using auto full-disk-encryption + possible to run out of space on /boot partition when installed using + auto recipe & full-disk-encryption
description:	updated

Revision history for this message

Dimitri John Ledkov (xnox) wrote on 2012-10-15:

Please do not include suggestions in the bug report =)

Arbitrary increasing the partition size will not help, as it is possible to dist-upgrade without removing old kernels (via apt-get dist-upgrade). It's a short term fix.

One solution is to use grub to mount encrypted partition directly, then there won't be need for separate /boot partition at all. See bug / feature request bug 1062623 .

Another solution is the blueprint to auto-remove old kernels.

Both of these are long-term sustainable.

Changed in partman-auto-crypto (Ubuntu Quantal):
status:	New → Won't Fix
Changed in partman-auto-crypto (Ubuntu):
status:	New → Confirmed
importance:	Undecided → Medium

Revision history for this message

Launchpad Janitor (janitor) wrote on 2013-03-19:

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

Revision history for this message

Mark Russell (marrusl) wrote on 2013-05-09:

Kernel autoremoval helps, but does not cover the situation where you are using unattended upgrades to push security fixes. Unattended update doesn't run apt-get autoremove. Enabling grub to boot from LUKS would cover all cases.

Mark Russell (marrusl) on 2013-09-22

description:

updated

Revision history for this message

C Filorux (breakfast) wrote on 2013-10-22:

The essence of the bug here is that the system accumulates a pile of kernel versions that are entirely unused. (When this happens, the partition fills up, and things break.) Stated another way, the system breaks deterministically by failing to clean up unused kernel versions that it installed itself. This bug is not confined to full disk encryption, but affects all configurations with a limited /boot partition.

This wasteful behaviour is bad, even if there is plenty disk space due to being able to boot from LUKS with some future (eagerly awaited) grub amazingness.

Revision history for this message

justcomplaining (justcomplaining) wrote on 2014-06-26:

Same here. Roughly 130MB. No update possible because of that. There seem to be unecessary old versions of some files in the directory, but "apt-get autoremove" doesn't help here.

abi-3.13.0-24-generic memtest86+.bin
abi-3.13.0-27-generic memtest86+.elf
abi-3.13.0-29-generic memtest86+_multiboot.bin
config-3.13.0-24-generic System.map-3.13.0-24-generic
config-3.13.0-27-generic System.map-3.13.0-27-generic
config-3.13.0-29-generic System.map-3.13.0-29-generic
efi vmlinuz-3.13.0-24-generic
grub vmlinuz-3.13.0-24-generic.efi.signed
initrd.img-3.13.0-24-generic vmlinuz-3.13.0-27-generic
initrd.img-3.13.0-27-generic vmlinuz-3.13.0-27-generic.efi.signed
initrd.img-3.13.0-29-generic vmlinuz-3.13.0-29-generic
lost+found vmlinuz-3.13.0-29-generic.efi.signed

Revision history for this message

justcomplaining (justcomplaining) wrote on 2014-06-26:

It's roughly 230MB of course. Also, the bug seems to be quite similar to #237035

Revision history for this message

mark johnson (mark.johnson) wrote on 2014-10-10:

This script gets a list of all linux-image-* that have added files to /boot except for the latest and (if different) currently running kernel, them removes the rest.

If this was part of the post-install script for kernel packages, then you'd only have 2 kernels installed at once, and /boot would never fill up.

https://gist.github.com/marxjohnson/5f0f0607255951ee0e7a

Revision history for this message

Dimitri John Ledkov (xnox) wrote on 2014-10-11: Re: [Bug 1067106] Re: possible to run out of space on /boot partition when installed using auto recipe & full-disk-encryption

On 10 October 2014 11:24, mark johnson <email address hidden> wrote:
> This script gets a list of all linux-image-* that have added files to
> /boot except for the latest and (if different) currently running kernel,
> them removes the rest.
>
> If this was part of the post-install script for kernel packages, then
> you'd only have 2 kernels installed at once, and /boot would never fill
> up.
>
> https://gist.github.com/marxjohnson/5f0f0607255951ee0e7a
>

The dpkg database is locked, when a given's package postinst is run,
thus one cannot remove packages as part of installation of another
one.
We already have scripts in place to mark old kernels for auto-removal,
however we do not enable autoremoval by default.
Thus it's easier to enable unattended upgrades and set
Unattended-Upgrade::Remove-Unused-Dependencies to true.

--
Regards,

Dimitri.

Revision history for this message

Rolf Leggewie (r0lf) wrote on 2014-12-05:

#10

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

Changed in partman-auto-crypto (Ubuntu Saucy):
status:	Confirmed → Won't Fix

Revision history for this message

Adam Niedling (krychek) wrote on 2015-09-29:

#11

This isn't a duplicate of bug #1267059. It's just a mere workaround.

"Please do not include suggestions in the bug report =)"

Why not? That's the whole point of expected behaviour!
I still have to remove old kernels manually all the time so I won't run out of space and break my system.

What exactly has been done to remedy this problem? Has the default size of the /boot partition been increased? Is the auto removal of old kernels turned on by default in new installations?