Re: The Kernel (fwd)

[Rick Jones <rickya@siservices.net>]

George Bonser wrote:
> 
> It makes EXTREME sense to me ... I have a scsi system.  If get some
> corruption in that partition, I would not be able to repair it!

As I understand it, and I have never used SCSI so correct me if I'm
wrong, when using initrd lilo reads the image in the same way that it
reads the kernel image at boot time.  Since you can read the kernel
without the SCSI drivers you can also read the initrd image without the
drivers.

This means that the possability of the initrd image being corupted is no
more than the possability of the kernel image being corrupted.  Most
likely they will both be shot if one is anyway, since they will have to
reside in the same area of the disk for lilo to read them anyway.

> Some things should not be configured as modules ... things essential to
> being able to shut yor system down are among them.

This is true, but the kernel can be compiled so that mod and kernel
versions don't have to match to boot, which is the only realistic
problem that a user might run into.  The odds are that any coruption in
initrd is going to be a sign of coruption of the entire partition and a
re-install will be eminent.  That's where recovery flop's come into
play.

> The point is this ... there are too many possible points of failure in my
> opinion for an initrd boot to handle a modularized disk driver to suit me.
> As long as I can get linux loaded, I am ok with the current scheme.

I would like to point out that even though you are the distro leader,
the purpose of these lists is to develop SEUL in accordance with valid
suggestions from the majority on these lists.  I am the UI leader and
will not disreguard input from the majority concerning UI simply because
it's not what I want.

If you don't want to fool with developing an initrd boot then ask for a
volunteer to do it for you so you can move on to other areas.  Once
he/she finishes it you can determine if it makes the grade or needs
further revamping.

  In an
> initrd boot, if the script has been hosed by me or something else or the
> root image file is corrupted or the modules directory on the main
> partition is bad for some reason, I can not even run fsck to fix it, I am
> dead in the water.  I do NOT want to have the disk drivers that I need to
> run my system not available when I need them most ... to fix a screwup.

Again, this would indicate a serious problem which, for one thing, our
target users wouldn't be able to fix anyway.  It would be best in that
situation for them to be forced to use a recovery flop that can be setup
to guide them through the recovery from a safety net instead of throwing
them into a s**t-storm of problems head first.

> Besides ... lets get right down to it ... what difference is <1 meg going
> to amke any how and have you MEASURED the performance hit?  How many
> bogomips difference does it make?  I suspect that it will be miniscule.
> You might notice it on a 386 with 4mb of ram but a doubt that you will at
> all on a P166 (the slowest processor Intel is manufacturing right now)
> with 32MB of RAM (standard on systems for sale for Win95).
> 
> As a matter of fact, I do not think you will see ANY performance hit ...
> the code is simply never called again after an initial probe (that
> granted, DOES take a few miliseconds).
> 
> I think we risk breaking many people's systems or making it MUCH more
> difficult to recover them without showing all that much of a performance
> gain.

You're absolutely right.  The performance hit is negligable.  That is a
non-issue as far as I'm concerned.  

> Uhm ... no.  I installed COL-Standard and needed the modules disk ... on
> two different systems even.  If I recall, it was for the lp driver and a
> couple of other things ... my Vortex net card, I think.

Serial drivers also if I remember correctly, among others.

> Deian's problem quite frankly is dselect.  Once beginners get past that
> learning curve, it is a very good distribution. I have not ever seen a
> distro as well integrated.

Very true.  It also lies in those config scripts as well.  A more
intuitive/user freindly interface to such tasks is needed to make an
intermediate or novice comfortable.

> I really do not understand this "thing" you have about thinking the debian
> kernel has to be recompiled.

It does.  It's a negligable performance hit, granted, but why would *I*
not compile a new kernel when I can.  I don't like have that extra stuff
in memory when it's easy enough to get rid of it.  Reguardless of the
performance hit.

> I still think there are larger issues that need attention before we get
> around to doing this.

Such as?  Where else would you start then at the begining, the boot
process?  If you don't want comments on a phase of development you
aren't working on then help us out by telling us what phase you are
working on.  What are the larger issues you are working on that need our
attention *before* we discuss booting the thing?

I think you should post some kind of outline so that we can follow
progress and post pertainant comments/suggestions instead of posting
things, evidently, out of the scope of what you are actually doing and
getting shrugged off with some generic response about there being larger
issues at this time.