Karmic i386 flavour changes
tim.gardner at canonical.com
Wed Jun 17 03:48:47 BST 2009
Colin Watson wrote:
> On Tue, Jun 16, 2009 at 05:27:22PM -0600, Tim Gardner wrote:
>> Colin Watson wrote:
>>> The trickier issue is that in order for this to be a useful choice, we
>>> now need to cram two kernels onto our CDs, otherwise either (a) non-PAE
>>> users are just screwed or (b) PAE users don't get any advantage unless
>>> they install via netboot or a DVD. Has this been discussed? I don't see
>>> a record of it in the specification.
>> If space is limited, then I think it's enough to carry just the PAE
>> kernel on the Live and Alternate CDs (but refuse to install or upgrade a
>> non-PAE capable CPU). I believe the use cases for non-PAE capable CPUs
>> are few, e.g., Geode and VIA C3 type CPUs in embedded or headless
>> motherboards. It should be enough to provide a netboot or DVD install
>> solution in that case.
> Well, up to you guys. We already have a small sample of the kinds of
> machines used by real people that are likely to be affected by this,
> since the server CD buggily forces PAE and doesn't check right now, so
> people whose machines don't boot after that file bugs about it. Here are
> the bug reports I can find at short notice:
> These reports include mentions of multiple virtualisation environments
> that don't support PAE; I believe VirtualBox has now been fixed, but
> Parallels still seems to be an issue here.
>>> is what I was referring to obliquely at UDS. Maybe somebody should poke
>>> Kyle and find out if he has the patch set to hand.
>> In an earlier thread in that conversation Kyle essentially echoes my
>> opinion wherein he wonders how many non-PAE use cases there are. I'm not
>> very interested in carrying a patchset to runtime detect and implement
>> the second level of page tables necessary to dynamically support PAE. I
>> know that most of the code is already there protected by ifdef's, but in
>> my opinion the number of use cases simply doesn't warrant the effort.
> It's your team, but I see a reasonable number and I do think it would be
> worth it. I'm not asking that we carry a patchset for it - I'd obviously
> rather see it merged upstream just as SMP alternatives already has been.
> I doubt we're the only distribution with users who would be interested
> in this.
> I think this is going to be a real issue. Not a double-digit percentage
> problem by any means, but each time we decide we don't care about a few
> percent of users here or a couple of percent of users there it does tend
> to add up somewhat.
> Of course it might be possible and worthwhile to arrange for the
> installer to require network access in such cases and grab the
> appropriate kernel from the network. The installer really isn't set up
> to be able to do that at the relevant stage at the moment, so I'd prefer
> to avoid it, but it's not impossible. That approach wouldn't be
> unworkable for the desktop CD, though.
> Also, Robert Hooker pointed out on #ubuntu-kernel that
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/386787 is a bit of
> a showstopper for switching the default to PAE right now.
Perhaps the kernel flavour install decision should be predicated on pae
as well as the amount of RAM. For example:
) PAE and > 4GB RAM - install linux-image-generic
) PAE and <= 4GB RAM - install linux-image-legacy
) !PAE - install linux-image-legacy
Of course, this assumes the Live or Alternate CDs can hold both kernel
The upgrade algorithm would therefore be:
Jaunty server --> Karmic generic
Jaunty generic --> Karmic legacy
Tim Gardner tim.gardner at canonical.com
More information about the Ubuntu-installer