On Thu May 11 2000 at 01:24, Tom Oehser wrote:
> > Could you please make a 2.2.x boot set. We really like
> > tomsrtbt and have learned to add/subtract stuff -- but the hurdle to
> > adding a 2.2 kernel is a bit steep.
>
> No. It is _NOT_ steep. It is one of the *easiest* customizations to do.
Agreed. (Of course this applies to the case of people who know how to
compile a kernel :)
> In fact, replacing the kernel is often *easier* and *saves more space*
> than trying to mess with modules! After all, you can compile a kernel
> with *exactly* what you need, *without* stuff you don't use, and a 2.2.x
> kernel will *save* you space! I frequently recommend that users build a
> 2.2.x kernel that matches their hardware, and blow away the 2.0.x modules.
Well, what's wrong with compiling the kernel with the options
needed at boot time, then drop any other modules you might need at
runtime onto another floppy and insmod/modprobe them from there.
> Moreover, this case is a perfect example of a job that does NOT call for
> 2.2.x. (1) The normal NFS server stuff works on 2.0.x, (2) NFS serving
> is not one of my design goals, anyway, and, (3) the in-kernel NFS stuff is
> not necessarily stable, anyway, and (4), in-kernel NFS is a performance
> thing, tomsrtbt explicitely is *never* concerned with performance.
While the kernel nfs/nfsd driver module works just great, for
tomsrtbt purposes the way to go would be with a libc5-compiled
portmap/nfsd/mountd binaries (made available from another floppy
disk). If nfs v3 is needed, then you would have to do this with
2.3.x or 2.4.x kernel with knfsd.
Personally I have raised the issue of NFS in the past... I needed
to use tomsrtbt to do a backup tape restore back onto box, but do
it onto an NFS-mounted filesystem.
(For various reasons, I could not run dump/restore directly onto
the box in question, so doing it via nfs was one possible
solution. In this case I could not do it with tomsrtbt due to
the lack of an nfs server, but I did do it that way using other
bootup/recovery/network tools).
> I am open to any good reasons why 2.2.x is necessary. I am working on the
> 2.0.39 version right now, the 2.0.39 kernel fixes all of the stupid ext2fs
> incompatabilities. In general: 2.0.39 is still the *BEST* compromise of
> space and function. The cases where 2.2.x has real advantages are still
> rare enough, and, the 2.2.x customization is *easy* enough.
I agree, 2.0.x is still quite suitable for putting onto a "simple"
rescue disk. (Especially with the ext2 sparse filesystem hiccups
resolved). Only for drivers for newer hardware should a
post-2.0.x kernel be needed... there would be no other advantage.
> No. Tomsrtbt is "the most Linux on 1 floppy", that means, 1 floppy, and,
> it also means, 1 version. My design goal stands. The niche that tomsrtbt
> fits in is that I am trying to make the best *compromise*, and keep it
> relatively *easy to customize*. I may well go to 2.2.x or libc6 at some
> point, but I will probably NEVER have more that 1 version that fits on 1
> floppy.
That's a valid point of view, but at the same time I can't see the
problem having more than one version available for download.
Why not one "standard" version, then some "variations" set up for
different purposes? Like one with an nfs server included? I've
been trying for a long time to get Tom to build tomsrtbt as
libc6-based (with no luck:-) and having multiple versions (and
even multiple "development" versions) available might be a way to
achieve this.
But this is Tom's baby, and it is his call.
> Some of the things I *am* working on:
cool
> Reviewing busybox as used in tomsrtbt and various awk tools, mostly to fix
> a lot of problems like the current "rm" works with "rm -r -f" but not with
> "rm -rf", etc., secondarily to make stuff smaller.
I've noticed several updates for busybox on freshmeat.net over the
past few months. Perhaps if you do a search there you might find
the current versions.
BTW, dump and restore is now under active maintenance again, and
while the libc5 versions that Tom has available still work fine,
incompatabilities might become an issue in the future.
> I am working on a "foolproof libc5 compilation environment". This is
> going to be MUCH easier, and bombproof, but will be a larger
> download. The idea will basically be a distribution of gcc, binutils,
> headers, and basic tools, that you run through chroot. That is, un-tar
> the package into /libc-5-environment, then do "chroot libc-5-environment",
> then you can build and compile and customize to your hearts content,
> without *any* worries about incompatabilities and conflicts with your
> normal libc6 environment.
While I fully understand why you are sticking hard with libc5, it
is outdated, unsupported, and buggy. Ok, it works, and it is
smaller than libc6.
I've resorted to creating and mounting more ram disks, putting the
libc6 .so's into it (either from a local hard drive or from a
floppy), and then "enabling" them with symlinks into /lib. It
works. Perhaps this would be a better alternative for people who
absolutely need to use libc6-linked binaries with tomsrtbt. But
this is DIYS (do it yourself :-)
> I am still way behind on a lot of stuff and am not spending a big lot of
> time on it, but I am making progress, and hope to release something soon,
> especially as more distributions are defaulting to ext2fs options that
> 1.7.185 can't handle.
Hey mate, what you have created is legend all over the internet.
It works (well, it mostly works:) It certainly does everything
you have designed it to do, and it can be tweaked to do a lot more
beyond that.
Keep up the good work. The world is eagerly waiting for your next
big revision...
Cheers
Tony
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
Tony Nugent <[EMAIL PROTECTED]> Systems Administrator, RHCE
GrowZone OnLine (a project of) GrowZone Development Network
POBox 475 Toowoomba Oueensland Australia 4350 Ph: 07 4637 8322
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
