Re: distribution of 2.4.x source for PPC (Re: Install on UATA)
Ethan Benson wrote:
>
> On Thu, Jun 28, 2001 at 05:16:50AM -0700, Andrew Sharp wrote:
> >
> > Ner. It uses a gzip'd coff linked kernel. And bizarrely you do
> > have to make it part of the package because you are supposed to be
> > able to make bootable floppies from those kernel-image packages.
> > And the miboot thingy is the only way on oldworlds, as you know.
>
> kernel-images have NEVER been able to make bootable floppies on
I didn't mean to say they did. What I meant was that the kernel for
making the miboot boot floppy is supposed to be part of the
kernel-image package for pmac-old. The kernel for the miboot floppy
is really the exact same kernel, except gzipped and in coff format.
> > > or perhaps teach yaboot/quik/silo to boot the OF images...
> >
> > Nah. It would probably be less work to just have a huge
> > proliferation of packages. One for pmac-old, one for pmac-new (we
>
> see the recent flamewar about the 3 dozen varieties of i386
> kernel-image packages....
flamers be damned. they can find time to argue about that harmless
stuff, they can find the time to figure out some simple, one kernel
solution to the multiple ppc arch's puzzle palace. wow, I'm so
clever. Not.
> > really should not keep treating these two like one arch, it's so
> > confusing, especially for newbies), one for prep, one for chrp ...
> > then you just download the one you want. It would mean less
> > downloading for most people (which I am guessing are pmac-new) since
> > they only need the yaboot kernel in the package. No boot floppy
> > issues for those lucky bastards.
>
> i tend to agree that oldworld may need its own kernel-image package,
> but i am not really enchanted with that idea either.... i am less
> enchanted with having more useless cruft in /boot though.
>
> the problem is kernel-package AFAIK doesn't have much of a mechenism
> to deal with all this, we would probably have to implement a bunch of
> fake targets like --mibootcruft --coffcruft --openfirmware --silo
>
> the latter being a simple vmlinux that is optionally gzipped (thats
> how sparc does it and thats how we will do it too as soon as silo
> supports powerpc).
Oops, guess what. The sparc world has it's head up its
you-know-what right now too! Try getting a 2.4.x kernel to work on
sparc32. They can't seem to get a kernel to work on v8 SPARC
machines, and guess what? Hardly anyone seems to care beyond being
sympathetic. Seems all the kernel developers have ultraSPARCs and
can't be bothered with us old folk. Tsk-tsk.
a
Reply to: