new kernel-powerpc upload.
Hello,
I have heard by Joey Hess that there were some reservation about my new
powerpc kernel ulpoad. Also, he asked you to hold it back until today,
when the debain-installer beta1 was released. This has now passed, and i
write to you this email, to get an idea of your reservations, to explain
what i have done and why it is necessary, and to get these new kernels
in the archive, so we can work on support for non newworld-pmac powerpc
subarches.
A bit of history first. Previously, there were one kernel package per
subarch, this still persist for the apus subarch, but some time back,
the prep, chrp and pmac kernels where folded into one kernel patch only,
called kernel-patch-2.4.x-powerpc. This kernel-patch packages has two
config files, one for normal powerpc and the other for the smp version.
Saddly, this kernel contains the .coff image used for OF booting pmacs
and the plain vmlinux used for the subarches which support yaboot. These
image will not work on all the other subarches, prep, chrp, chrp-rs6k
and especially not on the chrp/pegasos boards i use for development.
Also these kernel-images are too big to fit on a floppy disk, and can
thus not be used with an old-world pmac using miboot.
To solve this problem i have done two things :
1) added a new kernel config called powerpc-small for use with
oldworld miboot booting pmacs. It will use a initrd containing some
essential modules, like the x86 kernels seem to be doing. This may
even replace the traditional powerpc config once we get more
experience with it.
2) From the old kernel-image-2.4.22-powerpc, i split one package
containing the modules (kernel-modules-2.4.22-powerpc) and one
kernel-image package for each subarch (powerpc-pmac, powerpc-chrp,
powerpc-chrp-rs6k, powerpc-prep). These are the exact same kernel,
just having the added wrapper stuff needed to boot on chrp, chrp-rs6k
and prep. The powerpc-pmac is the same as the old powerpc
kernel-image, and in fact also provide it.
These two modification are the cause of an explosion of the number of
packages (from 2 kernel-images previously, to 3*5 packages now) but it
is somewhat unavoidable if we want to support the other powerpc
subarches. Notice that this is different from what Manoj suggested to
me, which would simply have created 4 kernel-images, each holding its
own copy of the 8Mo+ modules, which would have wasted more or less
3*3*8=72Mo of disk space on the archive.
Furthermore, to be able to install debian on the alternative subarches,
we need to embedd the debian-installer initrd in the kernels. Since the
debian-installer initrd needs to include some of the kernel modules, it
is not possible build first the initrd and then to build the kernel, nor
vice-versa. Which is why i have created the kernel-build packages, which
should allow to build kernel with initrd, and maybe also later include
the needed magic to build third party kernel modules later on. There is
an error in the uploaded packages, since they contain also the already
built kernels for all subarch flavors, but the debian-installer powerpc
folk urged me to upload it quickly, in order to be able to already
modify the linux-kernel-di debian-installer component and get ride of
the kernel-udeb packages (extracting the kernels and modules directly
from the .debs). Fixing this should bring the kernel-build packages to
a more reasonable 3-4Mo per kernel-build package.
It should be possible to build the per subarch kernel-images from this
kernel-build package too, doing the necessary per subarch magic in the
postinst, but i don't believe it is worth it, and in any case hardly
possible before the sarge release.
Ok, i have explained as best i could, if there is still something
obscure, or some reproach you have with this packages, please tell me
about it in timely fashion, as this needs to be fixed before sarge is
released, and since the packages needs over 5 hours to build on my box,
and 1-2 hours to upload, future modification will take some time, and it
will still need to get support in the debian-installer and some user
testing before it can be declared ready, and the scheduled date of the
debian/sarge release is approaching quickly now.
Friendly,
Sven Luther
Reply to: