[lug] ftape distress

[Harris, James A (Jim)]

Thanks for the insightful information.  I've been considering recompiling my
kernel anyway, so this gives me more reason to try.  I'm going to grab the
latest source, ftape source and tools and give it a whirl.

I'll post my results when I have them.
Thanks!

-----Original Message-----
From: Doug Shaw [mailto:shawd at pcisys.net]
Sent: Tuesday, February 15, 2000 10:44 PM
To: lug at lug.boulder.co.us
Subject: Re: [lug] ftape distress

The 2.2 kernels got funky when working with ftape.  I beat my head on the
problem so much that I nearly suffered brain damage.  If I recall correctly
- and don't quote this as gospel - the 2.2 kernel series has some ftape
support within the kernel itself that needs to be enabled (it may even be
the official ftape 4.x source, I don't recall).  You may need to recompile
the kernel to get it working; I rarely use stock kernels and don't know
quite what support they come built with by default.

ftape 4.x - and/or the kernel's ftape support - generates two modules,
zftape and zft-compressor, that need to be loaded to access /dev/qft?.  I
think that these supercede the standard ftape.o module(s).  I recall having
the problem where accesses to /dev/qft? would fail without the modules
loaded.  If memory serves, this support cannot be included in a monolithic
kernel, so you'll have to use them as modules if you want to use them at
all.

As for /dev/tape not existing, forget about that until you can access the
tape successfully using the actual device name (probably /dev/qft0).  Once
you've got the tape working, you can set up a link from /dev/tape to
/dev/qft0 (ln -s /dev/qft0 /dev/tape).

Doug