I have just published the first version of the Pavuk IDF installation
guide for FC 13:

http://www.pavuk.com/Site/Documents_...install_v1.pdf

This guide is step-by-step, but presumes some familiarity with the
Linux file system and commands. The server, linux.pavuk.com, is
running on a basic server board with a P4 processor at 2.8Ghz with 1GB
RAM and a mirrored RAID0 SATA set. Installation on notebook computers
is not supported due to problems related to hardware polling that
prevent stunnel from maintaining data pipes into Pavuk. It has also
not been tested on virtual hosts yet. Performance this minimal server
is exceptional.


Regards to all,

Bill

I just installed D3 9.0 on Centos 5 and am having trouble with my
pseudo floppies. The following lines are in my /usr/lib/pick/pick0
file

tape /dev/fd0H1440 500 f lq # tape 0
tape /dev/fd0H720 500 f ld # tape 1
tape /usr/lib/pick/ab 500 p lx # tape 2
tape /usr/lib/pick/dt 500 p lx # tape 3
tape /d3backups/filesave 1000000 p lx # tape 4
tape /d3backups/sunday 1000000 p lx # tape 5
tape /d3backups/monday 1000000 p lx # tape 6
tape /d3backups/tuesday 1000000 p lx # tape 7
tape /d3backups/wednesday 1000000 p lx # tape 8
tape /d3backups/thursday 1000000 p lx # tape 9
tape /d3backups/friday 1000000 p lx # tape 10
tape /d3backups/saturday 1000000 p lx # tape 11

When I start the D3 machine and do set-device, I only get the first 4
lines as options. Joe at Zumasysy suggested that the program was
reading from another pick0 file on my system, but I'm positive there
is no other pick0 file. All the files referenced exist and I ran
chmod 666 against them all in case it was an ownership problem.

On Sep 30, 4:22*pm, bruce ackman <bru... (AT) lewissupplyva (DOT) com> wrote:
type WHICH at tcl to verify the location and name of the "pick0" file
being read at boot

On a system that was just released a few days ago, your chance of
getting a good response based on field experience is almost nil.

I recommend calling your VAR, or TigerLogic Support. There's no doubt
you're paying someone for support - use it. If you post the solution
here I'm sure a number of people would appreciate it.

You should also start a new thread for a topic unrelated to the one to
which you responded.

Good luck.
T


bruce ackman wrote:

"bruce ackman" <brucea (AT) lewissupplyva (DOT) com> wrote

Try runnning pick with user root instead of user pick as an experiment.
Try having the tape1 and tape4 lines take each other's place in pick0 to see what
changes in your list-device, and to verify the pick0 is being sucked from where you
think it is. BTW when I run WHICH it just says pick0, no directory path given...
Personally all my alternate-pick0 problems were from having one in current directory
when I brought up pick with d3 -0, but I suppose /usr/lib/pick/pick0 and any folder
on the echo $PATH command path might be considered as well.
<<Login to root and do updatedb ; locate pick0 to seek out lurker pick0 files >>

FWIW I've had v9 running over Centos 5.5 x64 with 3.5Gb RAM allocated
to D3 with similar configuration to yours and tapes worked without any
problems (and soooooo nice not to have to remember, aka Google search,
how & where to link compress to gzip)

Gave it a bit of a beating running under HyperV with our THRASH
routines ... will be reloading to retest on raw iron & again under
ESXi to get a better measure of virtualization overhead, & differences
between pre-expaned vs expanding volumes etc