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 > root. > 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 debian-installer configuration. 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. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
