Apparently Tom Oehser <[EMAIL PROTECTED]> wrote:
>> 1.) Is there an 'easy way' to implement noblink in
>> the kernel?
> Huh? What is 'noblink'?
I wondered that, too. My first thought was that he might mean
"no blanking" (console blanking). Of course that would be
'setterm -blank 0' on a mainstream distribution. Does your
root/boot currently include setterm? If not, I'm sure that
one could dig up the appropriate escape sequences for most of
what setterm does and code them into a lua script. (I don't
know if setterm needs to do ioctl()'s for something like setting
the console blanking, and I don't know if supports calling arbitrary
ioctl()s --- hmmm I don't know hardly nothing that related to this
question).
>> 2.) Is the peanut-gcc .. comatible with your RtBt?
> If you mean, 'can I run "peanut-gcc" under tomsrtbt', probably not,
> tomsrtbt is not intended to ever support c compilation, it is for rescue
> and recovery, and supports Lua as a language if you need one. If you
> mean, 'can I compile a program for tomsrtbt with peanut-gcc', probably
> yes, as long as you are linking with -static or against the libc-5
> libraries.
>> 3.) Can I use the SuSe 7.1 for your RtBt?
> Huh? Tomsrtbt is its own distribution. That question is like asking 'can
> I use the RedHat with the SuSE'. You can create a tomsrtbt floppy from
> SuSE, which you then boot, and are no longer in SuSE. You can probably
> perform recovery tasks on a hard drive or filesystem that has SuSE while
> booted to tomsrtbt, but you are not 'using SuSE' at that point. Please
> clarify what you mean by the question.
> -Tom
Here's a case where the question: "Can I use Tom's Root/Boot to
recover and/or audit systems on which the Foo distribution is
installed?" actually does have some interesting wrinkles.
Clearly Tom's can handle most installations that are simply using the
ext2 and/or minix filesystems.
However, S.u.S.E. has been including reiserfs for it's last couple
versions; other distributions are likely to add reiserfs support in
the near future. (I expect that all of the major "mainstream"
distributions will be offer reiserfs support in their next versions
--- as they add 2.4.x kernel support). Of course this will be
optional. Hopefully users will be sensible and will maintain their
root filesystems (and /usr) under ext2fs. Ideally the distribution
installation scripts would recommend that root and /usr be ext2fs
(and even go so far as to recommend synchronous mounting for the
rootfs and read-only for /usr --- something which I routinely hack
into my configurations).
The key implication here is that reiserfs isn't all that important
for rootfs and /usr (particularly when root is mounted -o sync and
/usr and /boot are usually in -o ro and only changed to -o sync
during package installation, maintenance and upgrades).
The main features that will attract people to using reiserfs are
its support for journaling, and its the performance characteristics
that result from the tree stuctures in its internals.
Whether people widely choose to use reiserfs for their primary
filesystem type is going to depend on a number of factors. The
fact that reiserfs is in the 2.4 kernels now gives it a huge
edge over XFS, JFS, ext3 (the next generation of ext2) and other
journaling Linux filesystems. "Time-to-Market" is decisive.
However, the mainstream distribution interfaces will be the major
factor in mass market adoption.
So, it seems that reiserfs support will be very important to
Tom's Root/Boot at some point in the future (probably in six to
eight months). (Luckily reiserfs patches are maintained for the
2.2 kernels; though I don't know if they have patches going back
to 2.0). (Hmmm.... search, search, search: I guess this has
already been discussed on this list, and reiserfs is not backported
to 2.0 --- that sucks).
Regarding kernel bloat and compiling smaller kernels. bzip2 support
helps quite a bit. However, I don't see quite the bloat that
Tom talks about. Here's my /boot/vmli* (with the leading ls -l
fields trimmed, and sorted by size). Ironically my one old 2.0.x
kernel is almost my largest one (however, it definitely doesn't
have the same options as the others). Most of these are sort of
mostly compiled with the similar options. A couple of them have
FreeS/WAN ipsec patches, I think they're named accordingly.
(Sorry, not a good basis for comparison; but it's what I have
handy).
432068 Nov 12 2000 vmlinuz-2.2.18pre21
481852 Mar 5 2000 vmlinuz-2.2.14-jtd-1
485925 Jun 14 2000 vmlinuz-2.2.17-pre1+usb+ipsec
485958 Jun 14 2000 vmlinuz-2.2.17-pre1
573563 Nov 12 2000 vmlinuz-2.4.0-t11p3
599521 Sep 22 2000 vmlinuz-2.4.0-test8p9.4.old
602738 Sep 26 2000 vmlinuz-2.4.0-t8p4
604524 Jul 16 2000 vmlinuz-2.4.0-test4
617918 Jun 12 2000 vmlinuz-2.4.0-test1-ac10+ipsec
621548 Jun 10 2000 vmlinuz-2.4.0-test1-ac10+ipsec.old
630266 Sep 26 2000 vmlinuz-2.4.0-test8p9.4
636976 Oct 5 2000 vmlinuz-2.4.0-t9ja
636976 Oct 5 2000 vmlinuz-2.4.0-t9ja.old
641551 Jun 13 2000 vmlinuz-2.4.0-test1
642546 Apr 28 15:17 vmlinuz-2.4.4
642824 Jun 12 2000 vmlinuz-2.2.16usb
644393 Jun 13 2000 vmlinuz-2.4.0-test1-ac18.old
644395 Jun 14 2000 vmlinuz-2.4.0-test1-ac18
666730 Nov 11 2000 vmlinuz-2.4.0-t10
671740 Nov 11 2000 vmlinuz-2.4.0-t11p3.old
684993 Feb 21 12:43 vmlinuz-2.4.1
752473 Apr 4 2000 vmlinuz-2.0.38
819198 Mar 16 2000 vmlinuz-2.2.12
Here the effort hasn't been to trim these down. However they are
pretty heavily modularized.
BTW: the IPSec patches don't seem to add too much to the code
size, so that may be the easiest way to get crypto networking
support in lieu of ssh (obviously requires IPSec support at the
far end and some key management cruft back in user space ---
but it might still be easier then any sort of ssh/SSL approach
--- and one the SA (security association) is set between a pair of
hosts (transport mode) or the tunnel is established then *all*
network traffic between those nodes or through that tunnel is
automatically encrypted. So NFS, rsh, telnet and FTP are all O.K
and your wget, curl, web stuff can be secure without SSL support
(but just to the other end of that tunnel or SA).
Anyway, I also found that announcement for RIP (recovery is possible)
in your archives. So that might get reiserfs people back to life.
I think the introduction of RAID (hardware and software) LVM, and
the various journaling filesystems to Linux re-iterates the need
for another old sysadmin trick I tend to use: the creation and
maintanance of an 'altroot' filesystem; one which is not normally
mounted (mounted for syncing; then unmounted against) but which
is a place for one to use in the case where the kernel and boot
loader are undamaged (/boot as a separate fs --- it's a good idea)
and you can use the root=... parm to get to your rescue.
That's also handy with rescue floppies, where you can just fit
your kernel and boot loader (syslinux) on the floppy, so you can
pass it a root= to get to all your userspace tools.
Anyway, that's some random musings about using Tom's Root/Boot
with mainstream (or general purpose, if you prefer) Linux
installations. The hard part will be squeezing in support for the
newer file systems.
--
Jim Dennis
