[RFC] Upgrade path for Precise i386 non-pae generic flavor

Leann Ogasawara leann.ogasawara at canonical.com
Thu May 17 13:40:50 UTC 2012

On 05/17/2012 05:40 AM, Tim Gardner wrote:
> On 05/16/2012 03:21 PM, Leann Ogasawara wrote:
>> Hi All,
>> I'd like to discuss and get feedback regarding the best solution for
>> smoothly upgrading PAE capable systems currently running a non-pae
>> kernel and then collapsing the generic-pae flavor back to a generic
>> flavor.  I've broken this down into 2 phases, which I'll describe below.
>> Phase 1 is smoothly upgrading PAE capable systems running the Precise
>> i386 non-pae generic kernel to the Quantal i386 generic-pae kernel.
>> I've attached a patch which I believe will do the job, but would like
>> some review and feedback.  I would add that I have tested this patch on
>> an i386 PAE capable system which was running the Precise i386 non-pae
>> generic kernel.  It properly allowed updating to the Quantal generic-pae
>> kernel.  I also ran a quick test on an amd64 system to check I hadn't
>> regressed anything in terms of updating.  The only test I'm missing is
>> for the scenario of a non-pae system attempting to update.  The
>> expectation is that the update would abort.  I unfortunately don't have
>> access to this type of system.  I would like to get confirmation for
>> this scenario before proceeding.
>> Phase 2 is transitioning the current generic-pae flavor in Quantal to
>> become a generic flavor.   I unfortunately don't believe it's possible
>> to do both phase 1 and 2 in the same development cycle as we could find
>> ourselves in a scenario of having recursive install dependencies.  In
>> order to do both, I believe it will have to span two development
>> cycles.  I'm happy to be wrong here if someone can point it out to me.
>> My current proposal is we do phase 1 in 12.10 (ie Quantal) and phase 2
>> in 13.04 (ie R).  Comments appreciated.
>> Thanks,
>> Leann
> I don't think it needs to be that complicated. The goal is to transition
> Precise meta packages to Quantal in one upgrade step. We only need to
> support that one scenario, e.g., Precise ->  Quantal, because I think its
> policy that we only support upgrades from LTS to LTS, then LTS to
> intermediate releases.
> server [i386 amd64] ->  generic [i386 amd64]

I think this was already handled when we did away with the server flavor 
in Precise.

> virtual [i386 amd64]->  generic [i386 amd64]

Have we confirmed we are able to collapse the virtual flavor for Quantal?

> generic [i386 amd64] ->  generic [i386 amd64]
> generic-pae [i386] ->  generic [i386]

So if I'm thinking out load, the first step for us is to re-instate the 
i386 generic flavor in Quantal which will be identical to the current 
generic-pae flavor in Quantal.  Once that is in place we could then 
re-direct the Quantal generic-pae meta package to the generic meta 
package and at the same time re-instate the i386 generic meta package in 
Quantal.  Then we'll rely on update-manager-core to reap the obsoleted 
packages (ie generic-pae meta packages)

> lowlatency-pae [i386] ->  lowlatency [i386]
> lowlatency [i386 amd64] ->  lowlatency [i386 amd64]

This is implying that we're taking back ownership of the lowlatency 
kernel flavor.  Have we committed to doing that?


More information about the kernel-team mailing list