[RFC] Upgrade path for Precise i386 non-pae generic flavor
Tim Gardner
tim.gardner at canonical.com
Thu May 17 12:40:35 UTC 2012
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]
virtual [i386 amd64]-> generic [i386 amd64]
generic [i386 amd64] -> generic [i386 amd64]
generic-pae [i386] -> generic [i386]
lowlatency-pae [i386] -> lowlatency [i386]
lowlatency [i386 amd64] -> lowlatency [i386 amd64]
The recommended upgrade method is to use update-manager-core, e.g.,
'sudo do-release-upgrade'. That is a programmatic way of inserting new
packages that have no prior relationship, or removing packages that have
been obsoleted.
We don't really have to worry about the meta package mess we have in
Quantal right now. Lets just code for what we've speced for Quantal and
the reaper will eventually cleanup all of the obsoleted meta packages
(as well as kernel packages when virtual and generic-pae disappear).
rtg
--
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team
mailing list