Karmic i386 flavour changes

[Colin Watson]

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:

  https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/78071
  https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/151942
  https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/227869
  https://bugs.launchpad.net/ubuntu/+source/base-installer/+bug/329000

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.

>> BTW,
>> http://www.mail-archive.com/fedora-kernel-list@redhat.com/msg01682.html
>> 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.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]