Re: Test-DFS for PowerPC

[Sven Luther <sven.luther@wanadoo.fr>]

On Mon, Jun 07, 2004 at 10:27:27AM -0500, John Goerzen wrote:
> On Mon, Jun 07, 2004 at 05:06:27PM +0200, Sven Luther wrote:
> > reimplementation using the discover database), as the debian-installer
> > does.
> 
> Well, the purposes of DFS and of debian-installer are a little
> different.
> 
> DFS explicitly does *not* do hardware autodetection on boot, though it
> prints out a message on boot telling the user how to run discover or
> hotplug.  The reason is that, as a recovery tool, you may not want to
> attempt this discovery (and that could especially be the case if, for
> instance, your network controller is fried and the kernel hangs trying
> to bring it up).

Ok, this makes sense, but how are you gonna handle the case were a given
kernel is not suitable for a given subarch ? I would recomend you to use
the 2.4.25 powerpc .config as a base for your kernel then.

> Another goal is to make the kernel be one that somebody can slap onto
> their hard disk in an emergency and be able to boot from their hard disk
> again.  I actually initially was going to not use modules at all to make
> it easier, but when I realized that some Ethernet module's probing code
> hangs machines, I abandoned that course :-)  However, I still think that
> mkinitrd or some such solution is too complex and error-prone for this
> use.

Well, on chrp/prep you don't hve this problem, since the initrd is
builtinto the kernel anyway, so ...

> The stock Debian kernels are unsuitable for a number of reasons.  One is
> that they do not have enough filesystems, LVM/RAID, etc. compiled in, so
> they are unsuitable for emergency use in a lot of situations (requiring
> an initrd just to be able to grok the root fs in these cases).

I have trouble believing this, as we mostly build _all_ modules
available. True they are not builtin, but this is not the case
everywhere.

> I am not terribly troubled by a 5MB kernel size for this application,
> actually.  I don't know a lot about PowerPC subarchs, but on Alpha we do
> have subarchs but can compile a "generic" kernel that runs everywhere,
> which is what I have done.  I'm not all that concerned, in general,
> about running on machines old enough that they can't run a 5MB kernel
> and bash at the same time.

The main problem is that i think most alpha are very similar, while
there is a world of difference between a pmac and a prep for example, in
the hardware they use, especially the legacy stuff. My pegasos for
example, which is a chrp, has a standard via southbridge, so it does
need all the drivers normally used on x86 via-rhine for network,
via82cxxx for ide, serial driver, atkbd, and so on, while those are
useless (or harmfull depending on where you get your source tree) on
pmac hardware.

> DFS kernels also omit things that are not necessary for
> installation/repair work.  For instance, sound and video4linux are
> completely disabled.  The DFS kernels are here to give people a live,
> working system to use to repair or install Debian and build a custom
> kernel from there.

Which could easily be handled by creating an initrd of the default
powerpc kernel, with only those modules that are needed.

> > Actually, i believe that the initrd of the default debian kernel should
> > use discover too, and not the non-robust mess that is produced by
> > mkinitrd right now. And then, having an ocaml reimplementation of
> 
> Yes, mkinitrd mostly sucks.  OTOH neither discover nor hotplug are
> complete solutions.  Both miss certain hardware.

Yep, but if there are many things trying to do the same stuff, there is
more chances for incoherences and maintainance cost.

> > If ytou don't do that, and which to support more than just the subarches
> > that are most common, you will need to do agiant kernel like we did for
> > 2.4.25 (the debian kernel is over 5Mo big i believe).
> 
> Can you clarify how the powerpc subarchs work so I can get a better
> understanding of the problem?  Is it possible to compile a kernel that
> runs on all subarchs?

Well, as long as you don't include G5s or power3/power4 IBM boxes, yes.
The powerpc kernel in 2.4.25 package is one such example. Naturally
there is the problem of the legacy stuff, the pmac in general take it
quite badly for having random drivers pook at random memory space in the
isa address space.


But then, i think that there are also other limits, like the 4Mo size
limit of pmac tftp booting, or maybe the prep boot partition, and not to
speak of the oldworld miboot images.

All in all i believe that the 2.6.6 debian package initrd is a good
idea, you use the already built kernel, and use it together with a
tailored to your need initrd. It would be copying 2 files instead of
just one, unless you build kernels with builtin initrd like i do, and i
don't see how this would be a problem, especially if by doing this you
gain easy support for all those subarches which would be a pain to
support without it.


Friendly,


Sven Luther