Re: Barcode support outside of chg-scsi
Jason - Yes - [amanda@ford amanda]$ amtape daily slot 13 amtape: could not load slot 0: illegal request But with the change in code this now works. Much thanks for pointing this out. --doug At 08:04 AM 2/2/2001 -0500, you wrote: >On Fri, 02 Feb 2001, Doug Munsinger wrote: > > > I'm testing that test case - so far I hadn't had any trouble with that, > but > > my testing may have stepped around it. > >I didn't notice it until I did an 'amtape slot #'. I was only testing >with next, prev, current, etc for the longest time. > > >-- >Jason Hollinden > >SMG Systems Admin Doug Munsinger egenera, Inc. [EMAIL PROTECTED] 563 Main Street, Bolton, MA 01740 Tel: 508-786-9444 ext. 2612 OR 508-481-5493 fax: 978 779-9730
Re: Barcode support outside of chg-scsi
Jason -
having just been through "changer hell" I'm copying some mail I just sent
to Joe Rhett re: chg-zd-mtx and barcodes -
MAYBE it will help resolve what you are going through now.
I fought with chg-scsi and chg-zd-mtx for about a week before dropping back
and getting chg-manual to fully work first.
Here's what I just finished:
Hope this helps.
--doug
___
Joe -
I downloaded the improved mtx script from the link you gave in this post -
MUCH THANKS as the site also gave specific instructions for placing
at /client-src/chg-zd-mtx.sh.in
and then run configure. This came very close to working as is.
The timing worked well as I was already re-installing 2.4.2p1 upgrades
anyway...
I found two flaws in the code for my specific tape drive and changer.
I have an Ecrix VXA autopak library with a single Ecrix VXA tape unit
installed - with a barcode reader.
I managed to get chg-manual running consistently and getting good backups
first, which let me know that the tape drive and amanda were doing well,
before attempting for a second time to get the changer to cooperate.
I also installed mtx 1.2.10 and tested and verified this would work... So
at least I could get an e-mail that the tape needed changing and then log
in and accomplish that from home...
What I changed to make the chg-zd-mtx script work was to add a TIMEOUT
variable to use in a sleep command in loadslot as follows:
# Now rewind and check
echo " -> rewind $loadslot" >> $DBGFILE
echo " -> sleeping TIMEOUT: $TIMEOUT
seconds..." >> $DBGFILE
sleep $TIMEOUT
echo " -> rewind..." >> $DBGFILE
$MT $MTF $tape rewind
echo "$loadslot" > $slotfile
echo "$loadslot $tape"
exit 0
Otherwise I would consistently get
"/dev/nst0: Input/output error"
on any rewind or tape change by the script
This MOSTLY allowed the script to work, except -
I have a barcode reader.
The result of an mtx status command with a barcode reader is different than
without - at least when the tapes have barcodes -
here's what the mtx -f /dev/sg1 status result looks like (with barcode)
Data Transfer Element 0:Full (Storage Element 11 Loaded):VolumeTag = 09
Storage Element 1:Full :VolumeTag=00
Storage Element 2:Full :VolumeTag=01
Storage Element 3:Full :VolumeTag=02
Storage Element 4:Full :VolumeTag=03
Storage Element 5:Full
Storage Element 6:Full
Storage Element 7:Full
Storage Element 8:Full
Storage Element 9:Full
Storage Element 10:Full
Storage Element 11:Empty
Storage Element 12:Full
Storage Element 13:Full
Storage Element 14:Full
Storage Element 15:Full
which caused the sed command to give back:
[amanda@ford amanda]$ mtx -f /dev/sg1 status | sed -n 's/Data Transfer
Element 0:Empty/-1/p;s/Data Transfer Element 0:Full (Storage Element \(.\)
Loaded)/\1/p'
1:VolumeTag = 00
which won't work...
here's the change:
readstatus() {
EMP_FULL=`$MTX status | grep "Data Transfer Element" | awk '{
print $4 }' | awk -F: '{print $2 }'`
if [ $EMP_FULL = "Empty" ]; then
usedslot="-1"
fi
if [ $EMP_FULL = "Full" ]; then
usedslot=`$MTX status | grep "Data Transfer Element" | awk
'{ print $7 }'`
fi
I'll include the full script below this.
I thought this might come in handy and might also be something you would
want to include in the upkeep of chg-zd-mtx.
--doug
Doug Munsinger
egenera, Inc.
[EMAIL PROTECTED]
563 Main Street, Bolton, MA 01740
Tel: 508-786-9444 ext. 2612
OR 508-481-5493
fax: 978 779-9730
At 03:54 PM 1/31/2001 -0800, Joe Rhett wrote:
>Are you using the latest MTX version?
>
>Is the problem mtx itself? (Can you run "mtx load x", "mtx unload x" etc?
>
>Or is the problem with the changer script? Are you using the latest
>version? You can get it at
> http://www.noc.isite.net/?Projects
>
>On Wed, Jan 31, 2001 at 07:32:44PM -, [EMAIL PROTECTED]
>wrote:
> > I'm new to amanda and really can use some help installing a new
> > changer. The new unit is a Overland Minilibrary (15-slot) with 1
> > DLT-7000 drive. Our old unit is working fine but our filesystems have
> > grown a lot. The new unit is a model 7115.
> >
> > The problem appears to be my mtx configuration. Any help is greatly
> > appreciated!!!
> >
> > Sam Lauro
>
>--
>Joe Rhett
Re: Need some help with a new changer
Joe -
I downloaded the improved mtx script from the link you gave in this post -
MUCH THANKS as the site also gave specific instructions for placing
at /client-src/chg-zd-mtx.sh.in
and then run configure. This came very close to working as is.
The timing worked well as I was already re-installing 2.4.2p1 upgrades
anyway...
I found two flaws in the code for my specific tape drive and changer.
I have an Ecrix VXA autopak library with a single Ecrix VXA tape unit
installed - with a barcode reader.
I managed to get chg-manual running consistently and getting good backups
first, which let me know that the tape drive and amanda were doing well,
before attempting for a second time to get the changer to cooperate.
I also installed mtx 1.2.10 and tested and verified this would work... So
at least I could get an e-mail that the tape needed changing and then log
in and accomplish that from home...
What I changed to make the chg-zd-mtx script work was to add a TIMEOUT
variable to use in a sleep command in loadslot as follows:
# Now rewind and check
echo " -> rewind $loadslot" >> $DBGFILE
echo " -> sleeping TIMEOUT: $TIMEOUT
seconds..." >> $DBGFILE
sleep $TIMEOUT
echo " -> rewind..." >> $DBGFILE
$MT $MTF $tape rewind
echo "$loadslot" > $slotfile
echo "$loadslot $tape"
exit 0
Otherwise I would consistently get
"/dev/nst0: Input/output error"
on any rewind or tape change by the script
This MOSTLY allowed the script to work, except -
I have a barcode reader.
The result of an mtx status command with a barcode reader is different than
without - at least when the tapes have barcodes -
here's what the mtx -f /dev/sg1 status result looks like (with barcode)
Data Transfer Element 0:Full (Storage Element 11 Loaded):VolumeTag = 09
Storage Element 1:Full :VolumeTag=00
Storage Element 2:Full :VolumeTag=01
Storage Element 3:Full :VolumeTag=02
Storage Element 4:Full :VolumeTag=03
Storage Element 5:Full
Storage Element 6:Full
Storage Element 7:Full
Storage Element 8:Full
Storage Element 9:Full
Storage Element 10:Full
Storage Element 11:Empty
Storage Element 12:Full
Storage Element 13:Full
Storage Element 14:Full
Storage Element 15:Full
which caused the sed command to give back:
[amanda@ford amanda]$ mtx -f /dev/sg1 status | sed -n 's/Data Transfer
Element 0:Empty/-1/p;s/Data Transfer Element 0:Full (Storage Element \(.\)
Loaded)/\1/p'
1:VolumeTag = 00
which won't work...
here's the change:
readstatus() {
EMP_FULL=`$MTX status | grep "Data Transfer Element" | awk '{
print $4 }' | awk -F: '{print $2 }'`
if [ $EMP_FULL = "Empty" ]; then
usedslot="-1"
fi
if [ $EMP_FULL = "Full" ]; then
usedslot=`$MTX status | grep "Data Transfer Element" | awk
'{ print $7 }'`
fi
I'll include the full script below this.
I thought this might come in handy and might also be something you would
want to include in the upkeep of chg-zd-mtx.
--doug
Doug Munsinger
egenera, Inc.
[EMAIL PROTECTED]
563 Main Street, Bolton, MA 01740
Tel: 508-786-9444 ext. 2612
OR 508-481-5493
fax: 978 779-9730
At 03:54 PM 1/31/2001 -0800, Joe Rhett wrote:
>Are you using the latest MTX version?
>
>Is the problem mtx itself? (Can you run "mtx load x", "mtx unload x" etc?
>
>Or is the problem with the changer script? Are you using the latest
>version? You can get it at
> http://www.noc.isite.net/?Projects
>
>On Wed, Jan 31, 2001 at 07:32:44PM -, [EMAIL PROTECTED]
>wrote:
> > I'm new to amanda and really can use some help installing a new
> > changer. The new unit is a Overland Minilibrary (15-slot) with 1
> > DLT-7000 drive. Our old unit is working fine but our filesystems have
> > grown a lot. The new unit is a model 7115.
> >
> > The problem appears to be my mtx configuration. Any help is greatly
> > appreciated!!!
> >
> > Sam Lauro
>
>--
>Joe Rhett Chief Technology Officer
>[EMAIL PROTECTED] ISite Services, Inc.
>
>PGP keys and contact information: http://www.noc.isite.net/Staff/
Full revised chg-zd-mtx script:
#!/bin/sh
#
# Exit Status:
# 0 Alles Ok
# 1 Illegal Request
# 2 Fatal Error
#
# Contributed by Eric DOUTRELEAU <[EMAIL PROTECTED]>
# This is supposed to work with Zubkoff/Dandelion version of mtx
#
# Modified by Joe Rhett &l
chg-mtx error - no such file or directory
ult"
exit 2
else
loadslot next
fi
else
# Don't assume the drive is ready until we stop
getting tape offline
readyError="offline"
while [ -n "$readyError" ]; do
readyStatus=`$MT $MTF $tape status 2>&1`
echo " -> readyStatus =
$readyStatus" >> $DBGFILE
readyError=`echo $readyStatus | grep
"offline"`
done
# Now rewind and check
echo " -> rewind $loadslot" >> $DBGFILE
$MT $MTF $tape rewind
echo "$loadslot" > $slotfile
echo "$loadslot $tape"
exit 0
fi
}
info() {
readstatus
echo "INFO -> current slot $usedslot, last slot $lastslot,
can go backwards 1" >> $DBGFILE
if [ $usedslot -lt 0 ]; then
echo "0 $lastslot 1"
else
echo "$usedslot $lastslot 1"
fi
exit 0
}
# Program invocation begins here
echo "\n`date` Invoked with args '$@'" >> $DBGFILE
while [ $# -ge 1 ];do
case $1 in
-slot)
shift
loadslot $*
;;
-info)
shift
info
;;
-reset)
shift
reset
;;
-eject)
shift
eject
;;
*)
echo "Unknown option $1"
exit 2
;;
esac
done
Doug Munsinger
egenera, Inc.
[EMAIL PROTECTED]
563 Main Street, Bolton, MA 01740
Tel: 508-786-9444 ext. 2612
OR 508-481-5493
fax: 978 779-9730
Re: amtape update command fails to read tapes on chacking changer - changer.debug
0 ASCQ 00 Sense key 05 Illegal Request # START SCSI_TestUnitReady # START DecodeSCSI SCSI_ExecuteCommand : TEST UNIT READY 00 00 00 00 00 00 # STOP DecodeSCSI GenericRewind : Ready after 0 sec, true = 0 LogSense # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 40 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 41 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 6E 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 70 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 71 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 73 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 75 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 77 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 78 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 52 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 41 00 00 00 00 08 00 00 # STOP DecodeSCSI # START DecodeSCSI SCSI_ExecuteCommand : LOG SENSE 4D 00 60 00 00 00 00 08 00 00 # STOP DecodeSCSI # START LookupElement # STOP LookupElement (DTE) # START LookupElement # STOP LookupElement (STE) CheckMove : checking if move from 82 to 2 is legal CheckMove : DT2ST # START SCSI_Move # START DecodeSCSI SCSI_ExecuteCommand : MOVE MEDIUM A5 00 00 00 00 52 00 02 00 00 00 00 # STOP DecodeSCSI __ At 05:14 PM 1/23/2001 -0500, you wrote: > >1. tape device or changer issue? ... > >I'd strongly suspect a problem with the changer code rather than with >the drive. > > >At the end of this I'll place the amanda.conf and changer.conf files... > >I suspect we also need to see /tmp/amanda/changer*debug. That's where >all the good stuff is :-). > > >2. Timing issue? Is there a parameter in the changer.conf that could be > >set to eliminate this? An edit that could be made in the source code? > >Yes. Let us know when you find it :-). > > >I've also had the changer hang hard when an amanda job failed and aborted > >because of a config file error. ... > >Posting the matching /tmp/amanda/changer*debug file that matches is >probably the best way to proceed. > > >--doug > >John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] Doug Munsinger egenera, Inc. [EMAIL PROTECTED] 563 Main Street, Bolton, MA 01740 Tel: 508-786-9444 ext. 2612 OR 508-481-5493 fax: 978 779-9730
Re: barcode reader update to labelfile?
I think I found my own answer to this question. I found that the labelfile will be created by amlabel as each tape is labeled... --doug At 01:42 PM 1/23/2001 -0500, you wrote: >An additional question - >the Ecrix VXA autopak has a bar code reader which amanda initially used >and set up /usr/local/etc/amanda/daily/labelfile with tape labels and >barcodes - > >Can I force amanda to re-examine this library and re-write the labelfile? >Which command? >Or just wipe out the existing file? > >--doug > > > > > >Doug Munsinger > >egenera, Inc. >[EMAIL PROTECTED] >563 Main Street, Bolton, MA 01740 >Tel: 508-786-9444 ext. 2612 >OR 508-481-5493 >fax: 978 779-9730 Doug Munsinger egenera, Inc. [EMAIL PROTECTED] 563 Main Street, Bolton, MA 01740 Tel: 508-786-9444 ext. 2612 OR 508-481-5493 fax: 978 779-9730
barcode reader update to labelfile?
An additional question - the Ecrix VXA autopak has a bar code reader which amanda initially used and set up /usr/local/etc/amanda/daily/labelfile with tape labels and barcodes - Can I force amanda to re-examine this library and re-write the labelfile? Which command? Or just wipe out the existing file? --doug Doug Munsinger egenera, Inc. [EMAIL PROTECTED] 563 Main Street, Bolton, MA 01740 Tel: 508-786-9444 ext. 2612 OR 508-481-5493 fax: 978 779-9730
amtape update command fails to read tapes on chacking changer
ime.
# Unfortunately, this is not currently
# implemented. Use `dumpcycle 0'
# instead.
# "skip" - skip all dumps. Useful for sharing a single
# disklist in several configurations.
# "incronly" - do only incremental dumps. This is similar
# to strategy 'nofull', but will increase
# the dump level as usual. Full dumps will
# only be performed when an 'amadmin force'
# has been issued
# Default: [strategy standard]
#
# Note that you may specify previously defined dumptypes as a shorthand way
# of defining parameters.
define dumptype global {
comment "Global definitions"
# This is quite useful for setting global parameters, so you don't have
# to type them everywhere. All dumptype definitions in this sample file
# do include these definitions, either directly or indirectly.
# There's nothing special about the name `global'; if you create any
# dumptype that does not contain the word `global' or the name of any
# other dumptype that contains it, these definitions won't apply.
# Note that these definitions may be overridden in other
# dumptypes, if the redefinitions appear *after* the `global'
# dumptype name.
# You may want to use this for globally enabling or disabling
# indexing, recording, etc. Some examples:
# index yes
# record no
}
define dumptype always-full {
global
comment "Full dump of this filesystem always"
compress none
priority high
dumpcycle 0
}
define dumptype egen-root-tar {
global
program "GNUTAR"
comment "egenera - low priority client side compression"
compress client fast
maxdumps 2
index
exclude list "/usr/local/lib/amanda/exclude.gtar"
priority low
}
define dumptype egen-user-tar {
global
program "GNUTAR"
comment "egenera - medium priority client compression"
compress client fast
maxdumps 2
index
exclude list "/usr/local/lib/amanda/exclude.gtar"
priority medium
}
define dumptype egen-high-tar {
global
program "GNUTAR"
comment "egenera - high priority client compression"
compress client fast
maxdumps 2
index
exclude list "/usr/local/lib/amanda/exclude.gtar"
priority high
}
define dumptype egen-full-tar {
global
program "GNUTAR"
comment "egenera - full backup high priority client compression"
compress client fast
maxdumps 2
index
exclude list "/usr/local/lib/amanda/exclude.gtar"
priority high
dumpcycle 0
}
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/usr/local/lib/amanda/exclude.gtar"
priority low
}
define dumptype user-tar {
root-tar
comment "user partitions dumped with tar"
priority medium
}
define dumptype high-tar {
root-tar
comment "partitions dumped with tar"
priority high
}
define dumptype comp-root-tar {
root-tar
comment "Root partitions with compression"
compress client fast
}
define dumptype comp-user-tar {
user-tar
compress client fast
}
define dumptype holding-disk {
global
comment "The master-host holding disk itself"
holdingdisk no # do not use the holding disk
priority medium
}
define dumptype comp-user {
global
comment "Non-root partitions on reasonably fast machines"
compress client fast
priority medium
}
define dumptype nocomp-user {
comp-user
comment "Non-root partitions on slow machines"
compress none
}
define dumptype comp-root {
global
comment "Root partitions with compression"
compress client fast
priority low
}
define dumptype nocomp-root {
comp-root
comment "Root partitions without compression"
compress none
}
define dumptype comp-high {
global
comment "very important partitions on fast machines"
compress client best
priority high
}
define dumptype nocomp-high {
comp-high
comment "very important partitions on slow machines"
compress none
}
define dumptype nocomp-test {
global
comment "test dump without compression, no /etc/dumpdates recording"
compress none
record no
priority medium
}
define dumptype comp-test {
nocomp-test
comment "t
Re: RedHat 7.0
Actually it is worse than that - RedHat 7 on a fresh install doesn't use inetd at all, but replaces it with xinetd, and /etc/xinetd.conf. Not sure what the upgrade would have done, but you may no longer be running inetd at all. The xinetd.conf file as installed by RedHat sucks - it has no commented-out examples of each service, instead is almost completely blank. The man page seems to be enough to work with, but I have not yet got it functioning fully with amanda - there is a conversion utility (inetdconvert or something like that) which may convert your old inetd.conf to a working xinetd.conf. So far I have amcheck communicating with amanda client using xinetd.conf, but a complete failure on the actual backup communication. I have not debugged it any further and won't because I am moving anything 7.0 back to 6.2 asap anyway, having concluded for myself that 7.0 is a horrible release and one more like this I will be running turbo linux or BSD., not redhat. --doug At 07:25 PM 1/15/2001 -0600, Marc W. Mengel wrote: >On Tue, 16 Jan 2001, Chris Baker wrote: > > Can anyone help me, since I have upgraded two of my machines to RedHat 7.0 > > I am getting errors with amanda stating in its Mail Report that the > servers > > FAILED!: > > > > - > > FAILURE AND STRANGE DUMP SUMMARY: > > web /export lev 0 FAILED [Request to web timed out.] > > web /home lev 0 FAILED [Request to web timed out.] > > web /etc lev 0 FAILED [Request to web timed out.] > > ns2 /etc lev 1 FAILED [no estimate or historical data] > > - > > > > Anyone got any suggestions?, I am running Amanda v2.4.1 > >First, this should probably have gone to amanda-users, and not >amanda-hackers, but that nit aside, my guess is the upgrade >"upgraded" your /etc/inetd.conf file and you will need to put >back the entries for amandad, etc. > >Please direct further discussion on this to [EMAIL PROTECTED], >and not to amanda-hackers. > >Marc Mengel <[EMAIL PROTECTED]> Doug Munsinger egenera, Inc. [EMAIL PROTECTED] 563 Main Street, Bolton, MA 01740 Tel: 508-786-9444 ext. 2612 OR 508-481-5493 fax: 978 779-9730
