calculation of needed free space in /boot is inaccurate and causes refusal to upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-release-upgrader (Ubuntu) |
Fix Released
|
High
|
Steve Langasek | ||
Xenial |
Fix Released
|
High
|
Steve Langasek | ||
Yakkety |
Fix Released
|
High
|
Steve Langasek | ||
update-manager (Ubuntu) |
Fix Released
|
Low
|
Steve Langasek | ||
Xenial |
Won't Fix
|
Low
|
Unassigned | ||
Yakkety |
Won't Fix
|
Low
|
Unassigned |
Bug Description
[SRU Justification]
In some configurations, update-manager will refuse to upgrade kernel packages, citing lack of space in /boot even though there is enough space in /boot and if the upgrade is done with 'apt dist-upgrade', it succeeds. Affected users may as a result fail to have security updates applied to their system, unless they know how to run apt from the commandline or have unattended upgrades enabled.
[Test case]
1. Check the space currently used on /boot with du -sh.
2. Create a partition 120MB larger than the space used on /boot.
3. Copy the contents of your /boot directory into this partition.
4. Mount this partition as /boot.
5. Configure your system so that a newer kernel ABI is available (e.g., by enabling -proposed; or by waiting for the next kernel update to publish; or by downgrading the kernel using apt-get and rebooting).
6. Run update-manager.
7. Verify that update-manager refuses to upgrade, citing a lack of space in /boot.
8. Install python3-distupgrade and ubuntu-
9. Re-run update-manager.
10. Verify that update-manager proceeds with the upgrade, and that the upgrade succeeds, with no failure due to lack of disk space on /boot.
11. Repeat steps 2-9 with a partition that is only 60MB larger than the space used on /boot.
12. Verify that update-manager still refuses to proceed with the upgrade, with the packages from -proposed.
[Regression potential]
Since this changes the limit at which update-manager refuses to upgrade due to lack of free space, if the new calculation of the minimum required free space is too low, users may see update-manager proceed with the upgrade, then fail at the dpkg stage, requiring manual recovery.
[Original report]
I have a /boot partition which is sized just right to accommodate 3 kernels, plus a little bit of overhead.
$ df -h /boot/
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 280M 144M 118M 56% /boot
$
Previously, update-manager had no problem letting me upgrade kernels. With the latest kernel update in 16.10, I got an error message that I needed more free space on this filesystem.
After bypassing update-manager with 'sudo apt dist-upgrade', the filesystem's usage looks like this:
$ df -h /boot/
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 280M 206M 56M 79% /boot
$
So update-manager is getting the disk usage requirement for /boot off by a factor of 2 (at least? I didn't save the error message from the dialog).
It's better to refuse to upgrade than to fail mid-upgrade due to disk space, but not if that means getting stuck forever with an old kernel unnecessarily.
ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: update-manager 1:16.10.7
ProcVersionSign
Uname: Linux 4.8.0-27-generic x86_64
ApportVersion: 2.20.3-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Nov 30 12:10:25 2016
GsettingsChanges:
b'com.
b'com.
b'com.
b'com.
b'com.
InstallationDate: Installed on 2010-09-24 (2259 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitec
SourcePackage: update-manager
UpgradeStatus: Upgraded to yakkety on 2016-10-28 (32 days ago)
tags: | added: rls-z-incoming |
Changed in update-manager (Ubuntu): | |
assignee: | nobody → Steve Langasek (vorlon) |
status: | New → In Progress |
Changed in ubuntu-release-upgrader (Ubuntu Xenial): | |
status: | New → In Progress |
assignee: | nobody → Steve Langasek (vorlon) |
description: | updated |
Changed in ubuntu-release-upgrader (Ubuntu Yakkety): | |
importance: | Undecided → High |
status: | New → In Progress |
assignee: | nobody → Steve Langasek (vorlon) |
Changed in ubuntu-release-upgrader (Ubuntu): | |
importance: | Undecided → High |
Changed in ubuntu-release-upgrader (Ubuntu Xenial): | |
importance: | Undecided → High |
tags: |
added: verification-done-xenial removed: verification-needed |
tags: | removed: rls-z-incoming |
Changed in update-manager (Ubuntu): | |
status: | Triaged → Fix Committed |
Changed in update-manager (Ubuntu): | |
importance: | Undecided → Low |
Changed in update-manager (Ubuntu Yakkety): | |
importance: | Undecided → Low |
Changed in update-manager (Ubuntu Xenial): | |
importance: | Undecided → Low |
I think part of the issue here is the function estimate_ kernel_ size_in_ boot, from utils.py, which does the following:
92 def estimate_ kernel_ size_in_ boot(): "/boot/ *%s*" % kver):
93 """ estimate the amount of space that the current kernel takes in /boot """
94 size = 0
95 kver = os.uname()[2]
96 for f in glob.glob(
97 size += os.path.getsize(f)
98 return size
The glob ends up including vmlinuz and initrd, which is fine but then DistUpgradeCache.py multiples size by 2. We actually don't need enough free space to accomadate for two of every kernel file in boot though.