Ubuntu
update-manager package

Upgrade failed because /boot ran out of disk space

Bug #120489 reported by Kevin Smith on 2007-06-15

This bug report is a duplicate of: Bug #132311: Improve Update Manager's /boot space requirement calculation. Edit Remove

Affects		Status	Importance	Assigned to	Milestone
	update-manager (Ubuntu)	New	Undecided	Unassigned

Bug Description

Binary package hint: debian-installer

I upgraded to 7.04 (Feisty Fawn), but the upgrade failed in the middle because /boot filled up. I had about 5 kernels (I had diligently upgraded when update-manager suggested, but had never thought to remove old versions), and the folks who pre-installed Ubuntu on my laptop created a very small /boot partition.

During the recovery, at one point it *did* say I couldn't continue because /boot was full. It sure would have been nice if the upgrader had checked that before I started the process. It took me a while to get the system working again, and there is no way a non-technical user could have recovered on their own.

Summary: Before upgrading, installer should check to make sure there is "enough" space available on /boot

Revision history for this message

David C. Curtis (dccurtis) wrote on 2008-07-02:

A duplicate bug report has been confirmed here:

https://bugs.launchpad.net/ubuntu/+source/kernel-package/+bug/199086

Revision history for this message

Kevin Smith (ubuntu-qualitycode) wrote on 2008-07-03:

This bug is *NOT* quite a duplicate, as far as I can tell.

The other bug (199086) discusses methods of trimming the list of kernels either because the list is too long, or because update-manager fails during a normal kernel upgrade. This bug is because a VERSION UPGRADE fails in the middle, and MAKES THE SYSTEM UNUSABLE and unrecoverable by anyone without high technical skills.

Whether or not the kernel list is pruned, the version upgrade process needs to avoid leaving the system in an unusable state. Which, as far as I can tell, would mean checking /boot before the upgrade even starts.

Revision history for this message

David C. Curtis (dccurtis) wrote on 2008-07-03:

I see your point, the causality of both this and 199086 are the same, /boot is full, preventing kernel-package from installing (which is what I was going on). I assumed that the fix to both problems would be the same. If you want this bug report to stand alone again, fine by me.

But it does seem that the Kernel Team is working on a scheme to auto-remove kernels using a 'last-good-boot' mechanism, thereby fixing both of these bugs by never allowing /boot to fill up. https://wiki.ubuntu.com/KernelTeam/removing-old-kernels.

I guess the question is, if this fix gets implemented, can it be disabled? And if so do you still need a fail-safe check of free space in /boot either by kernel-package or by update-manager? Both?

Also can this bug, duplicate or not, be considered triaged? Can be considered confirmed?

Revision history for this message

Kevin Smith (ubuntu-qualitycode) wrote on 2009-11-11:

During a version upgrade, it is critical to check the space on /boot before starting, because a failure will be catastrophic (as it was for me). It is not enough to delete old kernel versions, because:

1. It is possible that /boot could be just slightly larger than the size of the one current kernel, or
2. /boot could be huge but could be full of other non-kernel files.

So an "auto remove" will not really fix this issue. Therefore, as far as I can tell, this bug should not be merged with 199086, There may be some other bug out there that it is a duplicate of, but I haven't seen it yet.

I have no idea if it should be marked triaged or confirmed. I just know that it actually happened to me, as described, in 2007, and I'm trying to avoid it happening to anyone else.