dapper->hardy->intrepid upgrade path leaves user with unmaintained kernel
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
High
|
Andy Whitcroft | ||
Hardy |
Invalid
|
Undecided
|
Unassigned | ||
Intrepid |
Invalid
|
High
|
Unassigned | ||
Karmic |
Fix Released
|
High
|
Andy Whitcroft | ||
update-manager (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Hardy |
Invalid
|
Undecided
|
Unassigned | ||
Intrepid |
Invalid
|
High
|
Unassigned | ||
Karmic |
Fix Released
|
High
|
Unassigned |
Bug Description
[I'm not sure whether this should be handled by the kernel or by update-manager on upgrades]
On 32bit intel platforms, dapper (6.06) installs the linux-image-386 kernel (e.g.linux-
However, if a subsequent upgrade from hardy to intrepid is performed, the linux-image-i386 will still be kept. But in intrepid, this variant has been pushed out of the kernel-team maintained linux source package and is instead built out of linux-ports, which lags behind the maintained kernel in both version (it's currently 2.6.25-2.3 as opposed to the supported 2.6.27-13.29 version) and attention for security updates.
This is a less than ideal upgrade path for a user that has strictly followed the installation and upgrade defaults (0 additional installed packages or configuration changes).
Related branches
Changed in linux (Ubuntu): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in update-manager (Ubuntu): | |
importance: | Undecided → High |
status: | New → Triaged |
tags: | added: regression-release |
Changed in linux (Ubuntu Intrepid): | |
assignee: | nobody → Andy Whitcroft (apw) |
Changed in update-manager (Ubuntu Intrepid): | |
status: | New → Incomplete |
importance: | Undecided → High |
Changed in linux (Ubuntu Karmic): | |
status: | In Progress → Fix Released |
Changed in update-manager (Ubuntu Karmic): | |
milestone: | karmic-alpha-5 → karmic-alpha-6 |
I do not know enough details about the kernel flavors for a good solution, but here are my alternatives:
a) We could have a special case in update-manager that checks /proc/cpuinfo and based on what it reads (and what the kernel team thinks is appropriate) switch users from linux-386 to linux-generic.
b) Make the linux-386 package a transitional package for linux-generic and rename the current linux-386 to linux-legacy ( or -old or -oldmachines ...).