dapper->hardy->intrepid upgrade path leaves user with unmaintained kernel

Bug #353534 reported by Steve Beattie
26
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-image-2.6.15-26-386) by default. When doing an upgrade from dapper to hardy via update-manager -c, this variant of the kernel is kept, such that post upgrade (currently), the linux-image-2.6.15-26-386 is the installed kernel. This is suboptimal (linux-image-generic is the default on new installs and would be preferred for most) but okay, as it's built off of the same source as the regular kernel images in hardy, linux-image-generic and linux-image-server.

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
Revision history for this message
Michael Vogt (mvo) wrote :

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 ...).

Revision history for this message
Andy Whitcroft (apw) wrote :

I would agree that (a) sounds like a good way forward. We would need to try and identify anything which is i686 and above capable and move those to -generic. The starting point would be to fix the Jaunty update-manager perhaps? The kernel team can help find the key to choose which cpu's can be moved. We would need someone who knows update-manager to implement the change.

Revision history for this message
Stefan Bader (smb) wrote :

From the configuration Dapper knew 3 flavours there
- 386 (CONFIG_M486 set)
- 686 (CONFIG_M686 set) and
- k7 (CONFIG_MK7 set)

In Hardy we have
- 386 (CONFIG_M486 set)
- generic (CONFIG_M586 set)

So the one question is, can we selectively move those which can go to 586 to generic and keep the ones who need 486 on the -386 kernel. And also to get the -i386 kernel in Jaunty better in sync with the generic kernel (as the -386 is in ports now). For Jaunty the sync is better but still the -386 kernel is a ports kernel.

-

Steve Beattie (sbeattie)
Changed in update-manager (Ubuntu):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Michael Vogt (mvo) wrote :

If you want this fixed in update-manager I need instructions how to detect (in a programmatic way) what kernel is suitable for what /proc/cpuinfo - i.e. what cpu family/model/model name or flags to map to what kernel.

I want to avoid switching users to a kernel that won't boot afterwards.

Changed in update-manager (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Andy Whitcroft (apw) wrote :

In the karmic UDS discussions kernel selection based on the CPU capabilities was discussed. It is highly likley that that work will fix this issue for machines that end up on Karmic.

    https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-karmic-flavours

Changed in linux (Ubuntu):
assignee: nobody → Andy Whitcroft (apw)
status: Triaged → In Progress
Revision history for this message
Andy Whitcroft (apw) wrote :

From the kernel side we need to identify how you detect the capabilities required to select an appropriate kernel. This work will be recorded on the wiki page below:

    https://wiki.ubuntu.com/KernelTeam/CPUFlavour

Matt Zimmerman (mdz)
tags: added: regression-release
Revision history for this message
Matt Zimmerman (mdz) wrote :

Per apw, this is no longer a maintenance issue in Karmic because the -386 and -generic kernels are both maintained, and identical apart from the CPU and memory size configuration.

summary: - dapper->hardy->intrepid upgrade path leaves user with unsupported kernel
+ dapper->hardy->intrepid upgrade path leaves user with unmaintained
+ kernel
Changed in linux (Ubuntu Hardy):
status: New → Invalid
Changed in linux (Ubuntu Intrepid):
status: New → Triaged
importance: Undecided → High
Changed in update-manager (Ubuntu Hardy):
status: New → Invalid
Matt Zimmerman (mdz)
Changed in linux (Ubuntu Intrepid):
assignee: nobody → Andy Whitcroft (apw)
Changed in update-manager (Ubuntu Intrepid):
status: New → Incomplete
importance: Undecided → High
Matt Zimmerman (mdz)
Changed in linux (Ubuntu Karmic):
status: In Progress → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote :

should this bug also be 'invalid' for update-manager in karmic, then?

Revision history for this message
Michael Vogt (mvo) wrote :

This was discussed in the release meeting today and we decided to include base-instaler as a sub-module to update-manager and let it do kernel selection on upgrade.

Changed in update-manager (Ubuntu Karmic):
status: Incomplete → Triaged
milestone: none → karmic-alpha-5
Steve Langasek (vorlon)
Changed in update-manager (Ubuntu Karmic):
milestone: karmic-alpha-5 → karmic-alpha-6
Revision history for this message
Michael Vogt (mvo) wrote :

Fixed in the 0.125 upload

Changed in update-manager (Ubuntu Karmic):
status: Triaged → Fix Released
Revision history for this message
Steve Beattie (sbeattie) wrote :

Michael, I think this is still an issue, though less of one if the i386 kernel is now co-maintained with the rest of the kernels. During lucid alpha 3 testing, I performed a dapper->hardy->lucid upgrade test, after which the system had both the generic and i386 kernels installed. Due to grub ordering (what determines this?), the i386 kernel was set as the default to boot into. I can get specific hardware info if necessary, but the machine in question is fully capable of running the regular default kernel for the i386 arch.

Revision history for this message
Alex Valavanis (valavanisalex) wrote :

Intrepid Ibex reached end-of-life on 30 April 2010 so I am closing the report. The bug has been fixed in newer releases of Ubuntu.

Changed in linux (Ubuntu Intrepid):
assignee: Andy Whitcroft (apw) → nobody
status: Triaged → Invalid
Changed in update-manager (Ubuntu Intrepid):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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