Re: New per subarch 2.4.22 powerpc kernels, please test.
On Sun, Oct 05, 2003 at 02:50:04PM +0200, Gaudenz Steinlin wrote:
> On Sun, 2003-10-05 at 14:33, Sven Luther wrote:
> > On Sun, Oct 05, 2003 at 02:15:20PM +0200, Gaudenz Steinlin wrote:
> > > On Sat, 2003-10-04 at 18:43, Sven Luther wrote:
> > > > On Sat, Oct 04, 2003 at 08:48:28AM -0700, Chris Tillman wrote:
> > > > > On Sat, Oct 04, 2003 at 01:31:55PM +0200, Sven Luther wrote:
> > > > >
> > > > > Thanks, Sven. I gzipped vmlinus-2.4.22-powerpc-pmac, and it
> > > > > is 1675729 in size, thus cannot fit on a 1.44 floppy. Is there
> > > >
> > > > Yep, i feared thus, i will maybe make a new configuration run, but this
> > > > would mean that the modules udeb are not compatible. Maybe removing more
> > > > stuff from the kernel and putting it in a initrd as modules would be a
> > > > solution, i hear there is lot of place on the debian-installer image,
> > > > but this may only be on x86, not sure thus.
> > > If in any way possible, it would be better not to have two different
> > > kernels for oldworld and newworld. I think someone with some knowledge
> > > about what hardware exists for mac hardware should go over all
> > > configuration options and tell which parts that are actually compiled
> > > into the kernel aren't of any use. (Chris could you do that?)
> > > Sven: would it be possible to make a more modularized kernel? AFAIK ide
> > > and usb (and scsi?) are not modules. The standard i386 kernel is far
> > > more modularized and uses an initrd also for "normal" booting. This
> > > could be the way to go.
> > Well, sure it could be possible, but you have to choose the options,
> > i cannot really do it, since i don't have pmac hardware. Keep in mind
> > that this is the same kernel which is used for prep/chrp/pegasos/rs6k
> > also though.
> Oh, then I missunderstood you. I thought that the kernel is built
> seperatly for every subarch.
Nope, i make only two builds (normal kernel + udebs and smp one). Still
we can probably modularize lot of stuff.
> > Now, at Oldenburg someone asked me to have firewire builtin, and not as
> > modules, so we have to choose which way we want to go.
> I would propose to modularize as much as possible. But as I never built
> a fully modularized kernel I don't know if there are any drawbacks.
> Probably we should discuss this on debian-powerpc.
Well, the main problem is that lot of stuff is needed for booting, but
some of it you may work around with the initrd approach, but i am not
familiar with it.
> > What are the steps needed to build an initrd from the kernel sources, do
> > someone have an idea ? Does kernel-package do it, or do we in some way
> > create a tarball with the modules in it, that will be copied over to the
> > debian-installer to create the initrd ?
> No, we need udebs for every module that has to go into the installer
> For arches which need the initrd built into the kernel it works the
> other way around. First you build the initrd and the you compile the
> kernel with this initrd embedded.
Well, i think that this is a problem anyway, for the arches which need a
builtin initrd, so we could do this in a different way. We build the
normal kernel-image with the kernel and some of the modules (there are
aaround 8Mo of them compressed, so there is no way they are all going to
fit in a initrd), this is done during the kernel-patch-2.4.x-powerpc
build phase. Then i produce, not the kernel-image udebs, but a
kernel-build tree (needed anyway for people wanting to build standalone
modules later on) which is then a dependency of debian installer, and
which is then used to get the initial modules which may be in an udeb
already, but maybe directly from the kernel-build tree, and build a
zImage.initrd from it, which then goes moved where we like during the
This would mean a 300 Mo kernel-build package, but i suppose this is ok,
as it seems i386 does it that way, and some changes to the
debian-installer build system.
Additionaly, this is the only way to build debian-installer on
arches/subarches which need a builtin initrd, like chrp for example.