Incorrect instructions leave automatic updates blocked when /boot is full

Bug #1477455 reported by Stuart Bishop
58
This bug affects 14 people
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Fix Released
Medium
Unassigned
Xenial
Fix Released
Medium
Brian Murray
Zesty
Fix Released
Medium
Brian Murray
Artful
Fix Released
Medium
Unassigned

Bug Description

[Impact]
A system's /boot mount point can fill up for many reasons and update-manager's free space check will cause update-manager to exit. A generic error message is presented which does not provide specific information to remedy the situation and subsequently can leave systems insecure.

[Test Case]
0) Ensure your system does not have the latest kernel installed
1) Create a file to be used as a /boot partition (dd if=/dev/zero of=fake-boot bs=1024 count=204800)
2) mkfs -t ext3 fake-boot
3) copy your real /boot somewhere
4) sudo mount -t ext3 fake-boot /boot
5) copy the files from step 3 to /boot
6) fill up /boot so there is less 60MB free space
7) run update-manager
8) Click "Install Now"

With the current version of update-manager you'll see an error message with instructions to "empty your trash and remove temporary packages." With the version of update-manager in -proposed you'll receive a message regarding using "sudo apt autoremove".

[Regression Potential]
We are just changing the strings used in the error message, which will introduce untranslated strings but that is better than leaving people with systems that cannot update.

Original Description
--------------------
What happens:

Default installations regularly fail package updates when /boot fills up. While the ultimate cause of this bug lies elsewhere, update-manager gives the user incorrect instructions when the failure occurs:

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

These instructions do not work, and software updates from this point on fail. The user is left vulnerable, unless they have knowledgeable assistance or are technically capable enough to research and fix the problem themselves.

What should happen:

update-manager should provide valid instructions for dealing with this well known problem, or better yet perform the operation itself. It is responsible for keeping the users machine up to date, and needs to handle this and similar failures.

ProblemType: BugDistroRelease: Ubuntu 15.04
Package: update-manager 1:15.04.7
ProcVersionSignature: Ubuntu 3.19.0-22.22-generic 3.19.8-ckt1
Uname: Linux 3.19.0-22-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.17.2-0ubuntu1.1
Architecture: amd64
CurrentDesktop: Unity
Date: Thu Jul 23 15:35:46 2015
GsettingsChanges:
 b'com.ubuntu.update-manager' b'show-details' b'true'
 b'com.ubuntu.update-manager' b'window-height' b'706'
 b'com.ubuntu.update-manager' b'first-run' b'false'
 b'com.ubuntu.update-manager' b'window-width' b'701'
 b'com.ubuntu.update-manager' b'launch-time' b'1437636623'
InstallationDate: Installed on 2015-03-13 (131 days ago)
InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1)
PackageArchitecture: allSourcePackage: update-manager
UpgradeStatus: Upgraded to vivid on 2015-03-16 (128 days ago)

Related branches

Revision history for this message
Stuart Bishop (stub) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in update-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Alberto Salvia Novella (es20490446e) wrote :

Once this bug is fixed in the Linux package, it will never come back. So making a special case in the Update Manager for this possibility will be over-engineering.

Changed in update-manager (Ubuntu):
status: Confirmed → Won't Fix
Revision history for this message
Steve Langasek (vorlon) wrote :

This message still exists and is still not helpful for cases where /boot does not have enough space.

Changed in update-manager (Ubuntu):
status: Won't Fix → Triaged
tags: added: rls-aa-incoming
tags: removed: rls-aa-incoming
Changed in update-manager (Ubuntu):
importance: Undecided → Medium
summary: - Incorrect instructions leave automatic updates blocked
+ Incorrect instructions leave automatic updates blocked when /boot is
+ full
Revision history for this message
Tyler Dinsmoor (pappad) wrote :

Hello. I submitted this bug in 2015. See bug #1460396. In that report I included a short patch for update-manager which would allow checking for enough space for a new kernel, but it got little attention.

Although @Alberto mentioned patching update-manager would be over-engineering, it's better to at least add a check, than to do nothing.. Since 2015..

My solution makes sure there is enough room for the current kernel size + 10MB headroom in case of a large increase.

It does no harm to make a simple check prior to an upgrade and prompt the user that they may not have enough room for the upgrade, and to go to a URL with instructions on how to run an apt autoremove, or to use synaptic to remove specific old kernels, etc. No harm. It's better to give a recommendation instead of letting users who are just that, users, fend for themselves.

Revision history for this message
Jarno Suni (jarnos) wrote :

Tyler Dinsmoor,
currently update-manager does not let you run update, if /boot is full, so I do not see where you patch is needed. It is just that update-manager can not recover from this issue or properly advice user to do something that helps.

Using synaptic or apt autoremove might not work in such a case currently. linux-purge is designed to work better then. (https://launchpad.net/linux-purge)

description: updated
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:17.10.10

---------------
update-manager (1:17.10.10) artful; urgency=medium

  * UpdateManager/UpdatesAvailable.py: Provide instructions when mount points
    have insufficient free space for the upgrade to complete. (LP: #1477455)

 -- Brian Murray <email address hidden> Wed, 20 Sep 2017 12:28:03 -0700

Changed in update-manager (Ubuntu Artful):
status: Triaged → Fix Released
Changed in update-manager (Ubuntu Xenial):
status: New → In Progress
Changed in update-manager (Ubuntu Zesty):
status: New → In Progress
Changed in update-manager (Ubuntu Xenial):
importance: Undecided → Medium
Changed in update-manager (Ubuntu Zesty):
importance: Undecided → Medium
Changed in update-manager (Ubuntu Xenial):
assignee: nobody → Brian Murray (brian-murray)
Changed in update-manager (Ubuntu Zesty):
assignee: nobody → Brian Murray (brian-murray)
Revision history for this message
Jarno Suni (jarnos) wrote :

I see the change here:
http://launchpadlibrarian.net/337696593/update-manager_1%3A17.10.9_1%3A17.10.10.diff.gz
As for /boot, the instruction for freeing space is to use 'sudo apt autoremove'. But that just might not work due to broken dependencies or Bug #1678187. On the other hand, it might remove more packages than desired according to https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1624644/comments/11
Anyway, I think
sudo apt-get install --fix-broken --auto-remove linux-generic
might work better than
sudo apt autoremove
or
sudo apt-get install --fix-broken,
if linux-generic is the package that has broken dependencies (which is the most common case).

tags: added: id-5982561eb1d9aa0d07be953f
tags: added: id-59c2cd399a13d92db1cb4711
Revision history for this message
Brian Murray (brian-murray) wrote :

Using 'sudo apt autoremove' to free up space in /boot, may not be enough to resolve the issue for everyone. One recommendation to free up more space in /boot is to switch from gzip compression for initrd.img by editing /etc/initramfs-toosl/initramfs.conf to xz compression. I think that should also be included in the SRU which suggests 'sudo apt autoremove'.

The wording I've come up with is 'Consider switching to COMPRESS=xz in initramfs.conf.'. Does that seem okay Matthew?

Revision history for this message
Tyler Dinsmoor (pappad) wrote :

Brian,

Just wanted to note the average user isn't going to understand that message.

Revision history for this message
Jarno Suni (jarnos) wrote :

Brian, how does changing the setting help when /boot is full? Will existing initrd.img files be created with better compression automatically?

Revision history for this message
Jarno Suni (jarnos) wrote :

Brian,
The file is /etc/initramfs-tools/initramfs.conf
I tested with "COMPRESS=xz", but when I boot a kernel for which the setting has been applied, (encrypted) swap does not work (in Ubuntu 14.04).

Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Stuart, or anyone else affected,

Accepted update-manager into zesty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/update-manager/1:17.04.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-zesty to verification-done-zesty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-zesty. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in update-manager (Ubuntu Zesty):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-zesty
Changed in update-manager (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed-xenial
Revision history for this message
Brian Murray (brian-murray) wrote :

Hello Stuart, or anyone else affected,

Accepted update-manager into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/update-manager/1:16.04.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Revision history for this message
Brian Murray (brian-murray) wrote :

I followed the test case from the bug description using the version of update-manager in zesty-proposed, 17.04.8, and can confirm that a new error message was displayed which suggested using 'sudo apt autoremove' to clean up old kernels.

tags: added: verification-done-zesty
removed: verification-needed-zesty
Revision history for this message
Brian Murray (brian-murray) wrote :

I followed the test case from the bug description using the version of update-manager in zesty-proposed, 16.04.10, and can confirm that a new error message was displayed which suggested using 'sudo apt autoremove' to clean up old kernels.

tags: added: verification-done-xenial
removed: verification-needed-xenial
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:17.04.8

---------------
update-manager (1:17.04.8) zesty; urgency=medium

  * UpdateManager/UpdatesAvailable.py: Provide instructions when mount points
    have insufficient free space for the upgrade to complete. (LP: #1477455)
  * test_update_origin.py: fix the extended origin matcher test as it was
    making wrong assumptions, not checking if packages actually had ANY package
    in -security. This should fix the current autopkgtest failures.
    (LP: #1717360)

 -- Brian Murray <email address hidden> Wed, 20 Sep 2017 14:36:07 -0700

Changed in update-manager (Ubuntu Zesty):
status: Fix Committed → Fix Released
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Update Released

The verification of the Stable Release Update for update-manager has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package update-manager - 1:16.04.10

---------------
update-manager (1:16.04.10) xenial; urgency=medium

  * UpdateManager/UpdatesAvailable.py: Provide instructions when mount points
    have insufficient free space for the upgrade to complete. (LP: #1477455)
  * test_update_origin.py: fix the extended origin matcher test as it was
    making wrong assumptions, not checking if packages actually had ANY package
    in -security. This should fix the current autopkgtest failures.
    (LP: #1717360)

 -- Brian Murray <email address hidden> Wed, 20 Sep 2017 14:39:17 -0700

Changed in update-manager (Ubuntu Xenial):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.