Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/purge-old-kenrnels
Created: 2006-06-07 by SivanGreen
Contributors: SivanGreen
Packages affected: update-manager/adept_updater, dist-upgrader
NOTE: This specification is being merged into SystemCleanUpTool as another use case.
Summary
This specification discusses adding support to the GUI packaging tools to suggest removal of old installed kernels once a new kernel has been installed on a system.
Rationale
Having too many unused old installed kernels can lead to shortage of free space on a limited /boot fs, clutter in the boot loader's menu and confusion for the average desktop user. Having support for cleaning up the unused kernels on the system will assist in freeing the otherwise unusefully used space and will result in less confusion for the desktop user of GUI upgrade and update tools.
Use cases
- John is a dapper user. A recent kernel upgrade has been released to cater for a security bug. After rebooting to his new kernel, the system informs him that he has some left over kernel packages that could be removed and asks him if he wants to do so. If he acknowledges, all of the kernels that he no-longer needs are removed, leaving him with a clean /boot with only the currently running kernel and the newly installed one.
- Ben is a kernel maintainer. Out of all the kernel packages he had uploaded during the release cycle of ubuntu $CODENAME he wants to see the statistics on which of the version seems to be most stable and boot/work for most of the users. He logs in the kernel package statistics page in Launchpad and sees that although he released an upgraded kernel package (2.6.17) the previous one (2.6.16) has booted for most people on the i386 arch and thus he may consider having this version as the one to be released when the distribution release is due. - Adam noted this might never be feasible but could be maybe hooked into popcon.
Scope
- We should concentrate in this spec on the "dist-upgrade" case from the GUI packaging tools point of view (the average desktop user) to avoid getting in the way of the power users. We also should not try to solve the problem for people tracking the development release.
- The packages affected are update-manager/adept_updater and the dist-upgrade tool.
We might want to check possibility of seperating this functionlity and incorporate it into FreeDiskSpaceWizard specification.
- We should make sure never to touch a kernel package created by the user.
Design
- The removal suggestion will be integrated into tools like the dist-upgrader (and maybe the update-manager/adept_updater application).
- When installing a new kernel (through the GUI packaging tools) mark the packages of:
- The currently running kernel.
- The new kernel that was just installed.
- Checking if the user has any other kernels installed other then those in the afformentioned list.
- If he does not, do nothing.
- If he does have, gather a list of all those kernel packages.
- Popup a desktop notification to the user "You have un-used kernels installed on the system. Would you like me to clean them up?".
- If the user confirms, then present a dialog displaying the list of kernels that was constructed in steps 2-4 , in the a window that will contain a columnd table, each row representing a kernel package:
- Row 1: Kernel Version. (e.g. "2.6.15-25-686")
- Row 2: Kernel Package Name. (e.g "linux-image-2.6.15-25-686").
Row 3: A check box indicating if this kernel package is to be removed, or left installed. (checked->keep, unchecked->remove)
- All items in the list are by default unchecked (meaning , tool will remove all kenrels on the remove-list)
- The user can choose to keep any of the kernls on the list by checking the checkbox next to the name/version.
- Pressing "Commit" , will calculate the kenrels packages to be removed from the check list, remove the kernel packages, and notify the user of success, or error if any issues were encountered while removing.
Implementation
- Since update-manager has not been designed to allow package removals in its UI, we need to think how to integrate such functionality into its UI.
- We need to teach update-manager to ask synaptic for removal of packages.
- Update-manager to track record of the two keep-by-default packages (current and newly installed)
Code
dsilvers: Presumably there's stuff to go in here
Data preservation and migration
- Make sure the user always have at least one running kenrel and one that he can revert to if for any reason the newly installed kernel fails to boot.
- Make sure kernels that a user had asked not to remove are kept including all of their respective modules and are bootable.
Outstanding issues