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: > > 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/[email protected]/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. >
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 packages. The upgrade algorithm would therefore be: Jaunty server --> Karmic generic Jaunty generic --> Karmic legacy rtg -- Tim Gardner [email protected] -- Ubuntu-installer mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-installer
