Re: Amanda and Onstream DI-30
"Jason Clark" [EMAIL PROTECTED] writes: Well, I've looked through the archives and it appears that some people are having success with this driver. I am not one of them. I'm currently running redhat 6.2 with a 2.2.16 kernel. I can get the drive to work with the ide-tape module patched according to onstream and access it as /dev/ht0 and /dev/nht0 and it works. I can use mt and give commands to the drive write data restore data etc... Any how when I do an backup with amanda it doesn't work. It seems to write but it won't restore. Use a newer kernel and have a look at http://linux1.onstream.nl/ Gernot. -- Gernot Schreib [EMAIL PROTECTED] http://www.stochastik.uni-passau.de/~schreib
Stuck at amdump
Hi all, amdump appears to work but I don't believe any files are being written to tape, extracting from the tape with a dd gets only the header. amcheck runs with no errors. The warning/errors in the amdump.1 and log.20010404.1 are: WARNING: got empty schedule from planner dumper: could not open log file /usr/local/etc/amanda/SERVERgroup/log/log: Permission denied (I've made the directory world writable). I would appreciate any help. Thanks, Lisa
AW: Amanda and Onstream DI-30
Hi, I'm using SuSE 7.0, Kernel 2.2.16 with no osst-driver - only aic7xxx, an Onstream ADR50i and I've got exactly the same problem. Writing to a 25GB-Tape will work fine - but when attempting to write data back, there seems to be a point/block (until ~1,2GB) where all readings fail. So changing to Kernel 2.2.18 or 2.4.x will maybe fix the problem? Christian -Ursprngliche Nachricht- Von: Gernot Schreib [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 4. April 2001 08:59 An: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Betreff: Re: Amanda and Onstream DI-30 "Jason Clark" [EMAIL PROTECTED] writes: Well, I've looked through the archives and it appears that some people are having success with this driver. I am not one of them. I'm currently running redhat 6.2 with a 2.2.16 kernel. I can get the drive to work with the ide-tape module patched according to onstream and access it as /dev/ht0 and /dev/nht0 and it works. I can use mt and give commands to the drive write data restore data etc... Any how when I do an backup with amanda it doesn't work. It seems to write but it won't restore. Use a newer kernel and have a look at http://linux1.onstream.nl/ Gernot. -- Gernot Schreib [EMAIL PROTECTED] http://www.stochastik.uni-passau.de/~schreib
Re: Failure on W2k client
On Apr 3, 2001, David Lloyd [EMAIL PROTECTED] wrote:
Again: THIS IS NOT AMANDA'S FAULT! IT IS SMBCLIENT'S FAULT!
You obviously cannot understand what I am saying, or you have not
followed this thread. If you cannot understand English I will have this
translated into any other language that I have a character set for:
SMBCLIENT CAN CONTACT MY WINDOWS 2000 SERVER. IT DOES NOT FAIL. IT WORKS
VIA BROADCAST AND AMANDA FAILS TO SEE THAT IT WORKS.
Or to reword this:
SAMBA IS ABLE TO CONTACT MY WINDOWS 2000 SERVER; SMBCLIENT CAN CONTACT
IT. HOWEVER, IT DOES THIS VIA BROADCAST AND AMANDA FAILS.
Amanda just runs smbclient. If Amanda says the backup failed, it's
because smbclient said so. Perhaps you're running one version of
smbclient by hand, but Amanda is running another, misconfigured
version? Perhaps you're passing some command-line flag to smbclient
that Amanda doesn't pass? Whatever the case is, it's smbclient that
is failing to contact the Windows machine. Amanda plays absolutely no
role here other than telling smbclient to create a tar-file off the
Windows box.
So how is it smbclient's fault when smbclient works? I can't understand
your English...
Perhaps I don't speak or write English well enough to get the message
through. It can't possibly be Amanda's fault. Get the exact command
line that Amanda runs (they're logged in /tmp/amanda/*.debug) and try
them. If they fail to work, you'll have more material to investigate
the problem. If they work, then you probably have a timing problem
(such as having the backup account forbidden from logging in at the
time of the backup or something).
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
RE: Stuck at amdump
Hi all, I thought I'd repost the question with more info: amdump appears to work but I don't believe any files are being written to tape, extracting from the tape with a dd gets only the header. amcheck runs with no errors. The warning/errors in the amdump.1 and log.20010404.1 are: WARNING: got empty schedule from planner dumper: could not open log file /usr/local/etc/amanda/SERVERgroup/log/log: Permission denied (I've made the directory world writable). In the mail I also get the "RESULTS MISSING" message. The platform is: Server-Solaris 2.6, Client-FreeBSD 4.2 I would appreciate any help. Thanks, Lisa
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
On Tue, 27 Mar 2001, Craig Dewick wrote: Will try the 'sst' driver out and report on it's performance after I have some sleep! 8-) Well, I've tried the 'sst' driver and it works only slightly better than the 'sgen' driver. With the 'sst' driver I can send as many 'mtx inquiry' commands as I like and they all work. Also, the 'mtx inventory' command produces a response from the robotics (the gripper arm moves out and in, but nothing else happens). However, all other commands produce SCSI errors. For example, 'mtx -f /dev/rsst5 first' produces this output: # mtx -f /dev/rsst5 first mtx: No such device or address mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed and this error message is logged from the kernel: Apr 4 23:05:21 lios scsi: [ID 107833 kern.warning] WARNING: /iommu@f,e000/sbus@f,e0001000/espdma@f,40/esp@f,80/sst@5,0(sst3): Apr 4 23:05:21 liosError for Command: undecoded cmd 0xb8Error Level: Fatal Apr 4 23:05:21 lios scsi: [ID 107833 kern.notice] Requested Block: 0 Error Block: 0 Apr 4 23:05:21 lios scsi: [ID 107833 kern.notice] Vendor: ADIC Serial Number: Apr 4 23:05:21 lios scsi: [ID 107833 kern.notice] Sense Key: Illegal Request Apr 4 23:05:21 lios scsi: [ID 107833 kern.notice] ASC: 0x24 (invalid field in cdb), ASCQ: 0x0, FRU: 0x0 I don't know what this means, but obviously something is producing incorrect results. Any ideas on what I can look at? With other people reporting success using an ADIC-1200 autochanger with the 'sg' driver in Linux, I'm surprised the 'sgen' and 'sst' drivers under SunOS 5.8 are giving so many hassles... Anyway, has anyone done much testing with the 'sst' driver in SunOS 5.8? It seems the bulk of people tend to use Linux or Windows so I guess Solaris testing is not the primary focus of the Amanda development group. Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point your web client at "www.sunshack.org" or "www.sunshack.net" to access my archive of Sun technical information and links to other places. For info about Sun Ripened Kernels, go to "www.sunrk.com.au" or "www.sun-surplus.com"
What does this mean
Hi Folks ..
I am getting the below error when I run amdump , amcheck has no complains. I
tried changing the permission , does not help
Dr.Prab
These dumps were to tape Enki-03.
The next tape Amanda expects to use is: Enki-04.
FAILURE AND STRANGE DUMP SUMMARY:
cream c0t0d0s0 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t0d0s0/20010403_0.gz.tmp: Permission denied]
srcc0t0d0s0 lev 0 FAILED [err create
/export/home/enki/index/src/c0t0d0s0/20010403_0.gz.tmp: Permission denied]
srcc0t0d0s1 lev 0 FAILED [err create
/export/home/enki/index/src/c0t0d0s1/20010403_0.gz.tmp: Permission denied]
cream c0t0d0s3 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t0d0s3/20010403_0.gz.tmp: Permission denied]
cream c0t0d0s3 lev 0 FAILED [dump to tape failed]
cream c0t0d0s7 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t0d0s7/20010403_0.gz.tmp: Permission denied]
cream c0t0d0s7 lev 0 FAILED [dump to tape failed]
srcc0t0d0s4 lev 0 FAILED [err create
/export/home/enki/index/src/c0t0d0s4/20010403_0.gz.tmp: Permission denied]
srcc0t0d0s4 lev 0 FAILED [dump to tape failed]
srcc0t0d0s7 lev 0 FAILED [err create
/export/home/enki/index/src/c0t0d0s7/20010403_0.gz.tmp: Permission denied]
srcc0t0d0s7 lev 0 FAILED [dump to tape failed]
y2kc0t0d0s4 lev 0 FAILED [err create
/export/home/enki/index/y2k/c0t0d0s4/20010403_0.gz.tmp: Permission denied]
y2kc0t0d0s4 lev 0 FAILED [dump to tape failed]
srcc0t0d0s6 lev 0 FAILED [err create
/export/home/enki/index/src/c0t0d0s6/20010403_0.gz.tmp: Permission denied]
srcc0t0d0s6 lev 0 FAILED [dump to tape failed]
cream c0t1d0s1 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t1d0s1/20010403_0.gz.tmp: Permission denied]
cream c0t1d0s1 lev 0 FAILED [dump to tape failed]
y2kc0t0d0s0 lev 0 FAILED [err create
/export/home/enki/index/y2k/c0t0d0s0/20010403_0.gz.tmp: Permission denied]
y2kc0t0d0s0 lev 0 FAILED [dump to tape failed]
y2kc0t0d0s5 lev 0 FAILED [err create
/export/home/enki/index/y2k/c0t0d0s5/20010403_0.gz.tmp: Permission denied]
y2kc0t0d0s5 lev 0 FAILED [dump to tape failed]
srcc0t1d0s0 lev 0 FAILED [err create
/export/home/enki/index/src/c0t1d0s0/20010403_0.gz.tmp: Permission denied]
srcc0t1d0s0 lev 0 FAILED [dump to tape failed]
y2kc0t0d0s6 lev 0 FAILED [err create
/export/home/enki/index/y2k/c0t0d0s6/20010403_0.gz.tmp: Permission denied]
y2kc0t0d0s6 lev 0 FAILED [dump to tape failed]
cream c0t0d0s6 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t0d0s6/20010403_0.gz.tmp: Permission denied]
cream c0t0d0s6 lev 0 FAILED [dump to tape failed]
cream c0t0d0s4 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t0d0s4/20010403_0.gz.tmp: Permission denied]
cream c0t0d0s4 lev 0 FAILED [dump to tape failed]
cream c0t1d0s0 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t1d0s0/20010403_0.gz.tmp: Permission denied]
cream c0t1d0s0 lev 0 FAILED [dump to tape failed]
y2kc0t0d0s7 lev 0 FAILED [err create
/export/home/enki/index/y2k/c0t0d0s7/20010403_0.gz.tmp: Permission denied]
y2kc0t0d0s7 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:02
Run Time (hrs:min) 0:03
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%) 0.00.00.0
Filesystems Taped15 15 0
Avg Tp Write Rate (k/s) 0.00.0--
FAILED AND STRANGE DUMP DETAILS:
/-- cream c0t0d0s0 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t0d0s0/20010403_0.gz.tmp: Permission denied]
\
/-- srcc0t0d0s0 lev 0 FAILED [err create
/export/home/enki/index/src/c0t0d0s0/20010403_0.gz.tmp: Permission denied]
\
/-- srcc0t0d0s1 lev 0 FAILED [err create
/export/home/enki/index/src/c0t0d0s1/20010403_0.gz.tmp: Permission denied]
\
/-- cream c0t0d0s3 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t0d0s3/20010403_0.gz.tmp: Permission denied]
\
/-- cream c0t0d0s7 lev 0 FAILED [err create
/export/home/enki/index/cream/c0t0d0s7/20010403_0.gz.tmp: Permission denied]
\
/-- srcc0t0d0s4 lev 0 FAILED [err create
/export/home/enki/index/src/c0t0d0s4/20010403_0.gz.tmp:
Re: Failure on W2k client
Ok, I think finally understand what Marty is trying to say. Marty, there are many people on this list who have been using samba for years and understand it very well and how it interacts with amanda, and if we couldn't understand the gist of your initial question, don't blame our lack of understanding of the english language. :-) Marty says his samba setup works, but because of the fallback from wins to broadcast the lookup takes longer than amanda is willing to wait. Amanda times out and as far as amanda is concerned, smbclient failed. I'm not even sure what the implications of this are or how to make it work more efficiently, I'm just interpreting what he stated. Marty, is this correct? Now, this said, I still think the problem is with samba. You should 'fix' your samba setup so that it doesn't take so long to do a lookup. Todd On Wed, 4 Apr 2001, David Lloyd wrote: Marty! I suggest you put your asbestos, flame resistant suit on... Again: THIS IS NOT AMANDA'S FAULT! IT IS SMBCLIENT'S FAULT! You obviously cannot understand what I am saying, or you have not followed this thread. If you cannot understand English I will have this translated into any other language that I have a character set for: SMBCLIENT CAN CONTACT MY WINDOWS 2000 SERVER. IT DOES NOT FAIL. IT WORKS VIA BROADCAST AND AMANDA FAILS TO SEE THAT IT WORKS. Or to reword this: SAMBA IS ABLE TO CONTACT MY WINDOWS 2000 SERVER; SMBCLIENT CAN CONTACT IT. HOWEVER, IT DOES THIS VIA BROADCAST AND AMANDA FAILS. As far as I'm concerned SMB is working correctly. It is setup to use wins, wins fails and it therefore contacts my Windows 2000 server by broadcast and connects. Perfectly. So how is it smbclient's fault when smbclient works? I can't understand your English... DSL -- Todd Pfaff \ Email: [EMAIL PROTECTED] Computing and Information Services \ Voice: (905) 525-9140 x22920 ABB 132 \ FAX: (905) 528-3773 McMaster University \ Hamilton, Ontario, Canada L8S 4M1 \
Re: Failure on W2k client
My last message should have been directed to David Lloyd, not Marty Shannon. Sorry Marty! -- Todd Pfaff \ Email: [EMAIL PROTECTED] Computing and Information Services \ Voice: (905) 525-9140 x22920 ABB 132 \ FAX: (905) 528-3773 McMaster University \ Hamilton, Ontario, Canada L8S 4M1 \
little question
Hi,
When running amdump, it does nothing after completing the sendsize.
It is still running, but not consuming cpu nor disk nor net.
How may I find out what's going on?
on /usr/local/var/amanda/config/{amdump,log} I just can't find
any useful information.
Thank you very much,
Gonzalo Arana
Re: little question
On Apr 4, 2001, Gonzalo Arana [EMAIL PROTECTED] wrote:
How may I find out what's going on?
amstatus
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: What does this mean
On Apr 4, 2001, "Dr.Prabhakar Ganapathy" [EMAIL PROTECTED] wrote:
/export/home/enki/index/cream/c0t0d0s0/20010403_0.gz.tmp: Permission denied]
It means the Amanda server doesn't have permission to create index
files, so you won't be able to use amrecover.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
[Fwd: little question]
Alexandre Oliva wrote:
On Apr 4, 2001, Gonzalo Arana [EMAIL PROTECTED] wrote:
It says 'waiting for dump' on all hosts/directories.
All of them? What is the reason it claims for being idle?
Where may I see a reason? on the amstatus output?
It began to work right now (?)
I still have the logs of the freezed runs of amdump.
Where may I look for?
Also, please note the last line of my signature.
ups! Sory!
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: [Fwd: little question]
On Apr 4, 2001, Gonzalo Arana [EMAIL PROTECTED] wrote:
Where may I see a reason? on the amstatus output?
Yep. At the end of the report, it was why each dumper is idle; before
that, it prints the main reason why the whole process is idle, if it
is.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: [Fwd: little question]
Alexandre Oliva wrote:
On Apr 4, 2001, Gonzalo Arana [EMAIL PROTECTED] wrote:
Where may I see a reason? on the amstatus output?
Yep. At the end of the report, it was why each dumper is idle; before
that, it prints the main reason why the whole process is idle, if it
is.
Sorry, but I can't see any info:
amstatus config --file /usr/local/var/amanda/config/amdump.2
Usign ...
hostn:/dir1 0 160k wait for dumping
hostn:/dir2 0 20150k wait for dumping
SUMMARY part real estimated
size size
partition : 191
estimated : 191 11697412k
failed : 0 0k ( 0.00%)
wait for dumping: 191 11697412k (100.00%)
dumping to tape : 0 0k ( 0.00%)
dumping : 00k0k ( 0.00%) ( 0.00%)
dumped : 00k0k ( 0.00%) ( 0.00%)
wait for writing: 00k0k ( 0.00%) ( 0.00%)
writing to tape : 00k0k ( 0.00%) ( 0.00%)
failed to tape : 00k0k ( 0.00%) ( 0.00%)
taped : 00k0k ( 0.00%) ( 0.00%)
all dumpers active
taper idle
and thats it.
It did keep as this for 20 minutes and I got tired of waiting.
I cancelled that backup.
Sorry again!!
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Failure on W2k client
Hi folks, Both amanda:sendsize and smbclient are OK, it is the interaction that is the problem. This started with my question re: read_socket_with_timeout errors in sendsize.debug. The error is generated from lib/util_sock.c in samba code. From the logs smbclient is noting a failed open to amanda:sendsize. Smbclient takes it own error message as an indicator to use the next address resolution scheme and continues to attempt to connect. Sendsize has noted the socket open failure and declared "session setup failed: code 0"; since the smbclient process hasn't died yet, sendsize continues to log information from the smbclient it spawned. A few things could happen here. Sendsize could kill and respawn an error-reporting smbclient, or wait to call the session off until smbclient exits; Smbclient could march through the host resolution options before reporting a failed open, thus not confusing amanda:sendsize. The reason, probably, that a "wins" first host lookup works for is that the smbclient file descriptor is not a socket and a different set of routines are used to perform the open, which for what ever reason are more robust or less verbose, thereby not causing sendsize to make determination that the session failed. We have a choice of where to make the fix. Changing amanda:sendsize to wait for smbclient to exit before declaring a failed session would make amanda more robust; changing smbclient to wait until the full gamut of host resolution options have been tried before reporting errors would also fix this problem from an amanda perspective but may cause other smb-dependent apps to suffer. Having amanda handle the different possiblities smbclient presents seems a good way to go.. Does anyone careto look at the code? sendsize.c line 504, maybe... We have a tentative thesis that the initial problem may be caused by the NIC being put to sleep in "powersaving" mode during inactive times (night) which is why we can't re-produce the problem during the day. We did uncheck the bit that does this in the 3Com w2k driver but didn't reboot the system. We saw no change last night so we'll try rebooting the sucker this afternoon. thanks, hurf -- Todd Pfaff wrote: Ok, I think finally understand what Marty is trying to say. Marty, there are many people on this list who have been using samba for years and understand it very well and how it interacts with amanda, and if we couldn't understand the gist of your initial question, don't blame our lack of understanding of the english language. :-) Marty says his samba setup works, but because of the fallback from wins to broadcast the lookup takes longer than amanda is willing to wait. Amanda times out and as far as amanda is concerned, smbclient failed. I'm not even sure what the implications of this are or how to make it work more efficiently, I'm just interpreting what he stated. Marty, is this correct? Now, this said, I still think the problem is with samba. You should 'fix' your samba setup so that it doesn't take so long to do a lookup. Todd On Wed, 4 Apr 2001, David Lloyd wrote: Marty! I suggest you put your asbestos, flame resistant suit on... Again: THIS IS NOT AMANDA'S FAULT! IT IS SMBCLIENT'S FAULT! You obviously cannot understand what I am saying, or you have not followed this thread. If you cannot understand English I will have this translated into any other language that I have a character set for: SMBCLIENT CAN CONTACT MY WINDOWS 2000 SERVER. IT DOES NOT FAIL. IT WORKS VIA BROADCAST AND AMANDA FAILS TO SEE THAT IT WORKS. Or to reword this: SAMBA IS ABLE TO CONTACT MY WINDOWS 2000 SERVER; SMBCLIENT CAN CONTACT IT. HOWEVER, IT DOES THIS VIA BROADCAST AND AMANDA FAILS. As far as I'm concerned SMB is working correctly. It is setup to use wins, wins fails and it therefore contacts my Windows 2000 server by broadcast and connects. Perfectly. So how is it smbclient's fault when smbclient works? I can't understand your English... DSL -- Todd Pfaff \ Email: [EMAIL PROTECTED] Computing and Information Services \ Voice: (905) 525-9140 x22920 ABB 132 \ FAX: (905) 528-3773 McMaster University \ Hamilton, Ontario, Canada L8S 4M1 \ -- Hurf Sheldon Dir. Research Systems Program of Computer Graphics 580 Rhodes Hall, Hoy Rd. Cornell University Ithaca, N.Y. 14853 voice:607 255 6713 fax:607 255 0806 email: [EMAIL PROTECTED] http://www.graphics.cornell.edu/~hurf/
Re: [Fwd: little question]
Alexandre Oliva wrote:
On Apr 4, 2001, Gonzalo Arana [EMAIL PROTECTED] wrote:
dumping to tape : 0 0k ( 0.00%)
dumping : 00k0k ( 0.00%) ( 0.00%)
all dumpers active
Hmm... This is very odd. What is `inparallel' set to, in amanda.conf?
8
and thats it.
I assumed you had 2.4.2.
You are absolutely right.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Failure on W2k client
Todd! Marty says his samba setup works, but because of the fallback from wins to broadcast the lookup takes longer than amanda is willing to wait. Amanda times out and as far as amanda is concerned, smbclient failed. I'm not even sure what the implications of this are or how to make it work more efficiently, I'm just interpreting what he stated. Marty, is this correct? That is correct. However I said it, not Marty as you've already noted. All I'm saying (in my own obtuse way) is that it appears "weird" that amanda/smbclient don't always get along with each other. At the moment it's going to be easier to work around this "smbclient" behaviour because this version of smbclient is going to be in production for a reasonable time yet. Simply pointing out that "it's Samba's fault" isn't at all helpful even if it is true. Telling someone that "it's in the FAQ" when they've taken the time to attempt to help someone on the list isn't at all helpful even if the answer is in the FAQ. If you're going to tell people that it's in the FAQ or to read a manual you really should post a URL or some sort of indicator where the FAQ or manual is... I don't think I need to continue this thread any further; I'll just go along and help out where I can. If some people notice that I'm repeating the FAQ at http://www.amanda.org/ then so be it. They can stay silent... DSL -- There's a sad face in the mirror And I'm sad to say it's me Like a ghost up in the attic Only love can set met free...
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
On Wed, 4 Apr 2001, Christopher Linn wrote: are you using gcc or SUNWspro cc? gcc. It's the only compiler I have, since I'm not about to fork out money for a commercial compiler which is less capable than the robust FSF compiler. 8-) if you are running a 64 bit kernel, then you must build your changer software in 64 bit mode; this means you cannot use gcc, since gcc doesn't do 64 bit (on solaris) yet. Nope - this machine is a Sparc 20, so it only supports 32 bit mode. also, have you seen the stctl package? http://www.cs.pdx.edu/~eric/stctl/ written for solaris, i have been using this as my changer software for several years, with both an exabyte 10-h changer and now a compaq storageworks SSL2000 series AIT2 changer; i had to tweek the timeout value for the Initialize Element Status command for the exabyte 10-h, but other than that it has been working flawlessly on solaris 2.6 and solaris 8. Can't say I have, but I will check it out. Looks like the ideal solution if the mtx/sst and mtx/sgen combinations are going to continue to give problems. Thanks very much for the pointer... Regards, Craig. -- Craig Dewick. Send email to "[EMAIL PROTECTED]" Point your web client at "www.sunshack.org" or "www.sunshack.net" to access my archive of Sun technical information and links to other places. For info about Sun Ripened Kernels, go to "www.sunrk.com.au" or "www.sun-surplus.com"
Re: Missing
Any thoughts before I give up and just use dump.? Start by looking at the debug files in /tmp/amanda. In particular, sendsize*debug and sendbackup*debug. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: LSM - Logical Storage Manager Drives
I have configured the system so that amcheck is happy, but amdump reports disk is offline. I have set the device permissions like so: brw-r root system /dev/vol/rootvol (logical volume) Is your Amanda user (the one inetd/xinetd runs amandad as) in group "system"? What's in /tmp/amanda/sendsize*debug? Walter John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: What does this mean
I tried changing the permission , does not help What did you change the permissions on? What did you change them to? What is your Amanda user (the one you run amdump as)? I'm a little surprised amcheck did not whine. I thought I had put in code in 2.4.2 to look for this type of problem. Dr.Prab John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Failure on W2k client
On Apr 4, 2001, Hurf Sheldon [EMAIL PROTECTED] wrote:
Sendsize has noted the socket open failure and declared "session
setup failed: code 0"; since the smbclient process hasn't died yet,
sendsize continues to log information from the smbclient it spawned.
And it keeps looking for the size line, AFAICT. So, whenever
smbclient manages to connect to the client, it should work.
We have a tentative thesis that the initial problem may be caused by
the NIC being put to sleep in "powersaving" mode during inactive
times (night) which is why we can't re-produce the problem during
the day.
Perhaps you could run a couple of `amcheck's before starting amdump?
That's what we do locally, because the Amanda binaries and home
filesystems are NFS-auto-mounted.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Sector Level Backups
On Apr 3, 2001, "Dave Hecht" [EMAIL PROTECTED] wrote:
I would like to use "dd" , or some similar tool to make exact images
of a drive as a full backup, rather than dump or tar. [...] Can
Amanda be modified to do this?
Yep. That's the kind of thing you should be able to do with the
DUMPER API, under (stalled) development for Amanda 2.5. Meanwhile,
you could configure Amanda to run some shell-script instead of GNU
tar, that would run dd after examining the command-line arguments.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Yet another Insecure Port ...
Brand new build of amanda 2.4.2p2 server config build: /configure --with-gnutar=/usr/local/bin/tar --with-portrange=900,950 --with-udpportrange=900,950 (etc) client config build: ./configure --with-gtar=/usr/local/bin/gtar --without-server --with-portrange=900,950 --with-udpportrange=900,950 Server binaries: -rwsr-x--- 1 root wheel 68759 Apr 4 15:46 /usr/local/libexec/calcsize* -rwsr-x--- 1 root wheel 231765 Apr 4 15:47 /usr/local/libexec/dumper* -rwsr-x--- 1 root wheel 58227 Apr 4 15:46 /usr/local/libexec/killpgrp* -rwsr-x--- 1 root wheel 309711 Apr 4 15:47 /usr/local/libexec/planner* -rwsr-x--- 1 root wheel 56004 Apr 4 15:46 /usr/local/libexec/rundump* -rwsr-x--- 1 root wheel 56761 Apr 4 15:46 /usr/local/libexec/runtar* -rwsr-x--- 1 root wheel 322122 Apr 4 15:47 /usr/local/sbin/amcheck* Client: ls: /usr/local/libexec/dumper: No such file or directory ls: /usr/local/libexec/planner: No such file or directory -rwsr-x--- 1 root wheel 71756 Apr 4 17:22 /usr/local/libexec/calcsize* -rwsr-x--- 1 root wheel 62521 Apr 4 17:22 /usr/local/libexec/killpgrp* -rwsr-x--- 1 root wheel 60112 Apr 4 17:22 /usr/local/libexec/rundump* -rwsr-x--- 1 root wheel 60905 Apr 4 17:22 /usr/local/libexec/runtar* amcheck -c test Amanda Backup Client Hosts Check ERROR: frog.hoop-t.net: [host cat.hoop-t.net: port 62870 not secure] Client check: 1 host checked in 0.076 seconds, 1 problem found I'm not seeing any errors through the firewall, so I'm not sure how to further debug this. Any suggestions? Has anyone got Amanda to work using the udpportrange/portrange options through a firewall? Thanks! ~ Doug Silver 619 235-2665 Quantified Systems, Inc ~ Here's the client amandad.debug packet stuff: sending ack: Amanda 2.4 ACK HANDLE 000-00300D08 SEQ 986430352 amandad: sending REP packet: Amanda 2.4 REP HANDLE 000-00300D08 SEQ 986430352 ERROR [host cat.hoop-t.net: port 62870 not secure] amandad: got packet: Amanda 2.4 ACK HANDLE 000-00300D08 SEQ 986430352 amandad: pid 56308 finish time Wed Apr 4 17:25:53 2001
Re: Exabyte Mammoth 2 users take note
Hey, Yeah I had called tech support on that particular reason and they said that premature EOTs were cause by the self cleaning engaging during middle of the dump.. I supposedly have a .i file that removes the autocleaning ability and that you'll hav to manually clean the tapes. Tano On Wed, 28 Mar 2001, Ross Johnson wrote: As of firmware upgrade 8ck3v03a (8ch3v03a for HVD drives), Exabyte have fixed a major problem with premature EOT errors. I have just upgraded and was able to do a full level 0 dump for the first time without getting inconsistent EOTs. So if you're getting this kind of error, it may be worth a trip to http://www.exabyte.com/support/online/downloads/firmware_tape.cfm Regards. -- +-+---+ | Ross Johnson| | "Come down off the cross | Management Technology |___| We can use the wood" - Tom Waits | Building 11 | | University of Canberra | eMail: [EMAIL PROTECTED] | ACT2601 | WWW: http://public.ise.canberra.edu.au/~rpj/ | AUSTRALIA | +-+
Re: Exabyte Mammoth 2 users take note
Hi, Tanniel Simonian wrote: Hey, Yeah I had called tech support on that particular reason and they said that premature EOTs were cause by the self cleaning engaging during middle of the dump.. I supposedly have a .i file that removes the autocleaning ability and that you'll hav to manually clean the tapes. I had read about that problem, but it wasn't what I was seeing. My writes would fail almost everytime at random places, often after only a few hundred megabytes or a few gigabytes. It seemed to improve the faster I wrote to the tape, but not always. The best I ever got while trying to sort the problem out was 50Gb using "dd if=/dev/zero of=/dev/rmt/0bn". The explanation I heard was that the work-around put in the firmware is to skip over bad sections of tape if the bad spot is less than a millimetre long. I also heard that this was to allow third party tape brands to work more reliably, but I've only ever used Exabyte tapes in this drive. Anyway, since upgrading, my backups are running 100% reliably. My supplier was very good, arranging with Exabyte (locally) to swap my tape unit for one with updated firmware when upgrade tapes weren't yet available. Ross Tano On Wed, 28 Mar 2001, Ross Johnson wrote: As of firmware upgrade 8ck3v03a (8ch3v03a for HVD drives), Exabyte have fixed a major problem with premature EOT errors. I have just upgraded and was able to do a full level 0 dump for the first time without getting inconsistent EOTs. So if you're getting this kind of error, it may be worth a trip to http://www.exabyte.com/support/online/downloads/firmware_tape.cfm Regards. -- +-+---+ | Ross Johnson| | "Come down off the cross | Management Technology |___| We can use the wood" - Tom Waits | Building 11 | | University of Canberra | eMail: [EMAIL PROTECTED] | ACT2601 | WWW: http://public.ise.canberra.edu.au/~rpj/ | AUSTRALIA | +-+ -- +-+---+ | Ross Johnson| | "Come down off the cross | Management Technology |___| We can use the wood" - Tom Waits | Building 11 | | University of Canberra | eMail: [EMAIL PROTECTED] | ACT2601 | WWW: http://public.ise.canberra.edu.au/~rpj/ | AUSTRALIA | +-+
Re: more with ADIC-1200 + SunOS 5.8 'sgen' driver and mtx problems
I have the same problem, but I doubt anyone will answer in the amanda forum, since I have asked about this issue before. Since it an mtx issue, I guess there's a different forum to discuss this. But I will post my message again... I have a SUN Enterprise 3500 with SunOS 5.7, a differential SCSI and a DLT L-280 SUN StorEdge array. I have attached the sst through add_drv successfully, and can issue a mtx command to eject, and the autoloader ejects one DLT tape and then loads another. That's the most I can do. Here is my output for the rest of the commands issued by mtx... # mtx -f /dev/rsst1 inquiry Product Type: Tape Drive Vendor ID: 'QUANTUM ' Product ID: 'DLT7000 ' Revision: '2560' Attached Changer: No # mtx -f /dev/rsst1 eject # mtx -f /dev/rsst1 inventory mtx: I/O error mtx:inventory failed # mtx --version mtx version 1.2.9 Usage: mtx --version mtx [ -f loader-dev ] noattach more commands\n mtx [ -f loader-dev ] inquiry | inventory | status mtx [ -f loader-dev ] first [drive#] mtx [ -f loader-dev ] last [drive#] mtx [ -f loader-dev ] next [drive#] mtx [ -f loader-dev ] previous [drive#] mtx [ -f loader-dev ] [invert] load storage-element-number [drive#] mtx [ -f loader-dev ] [invert] unload [storage-element-number][drive#] mtx [ -f loader-dev ] [eepos eepos-number] transfer storage-element-number storage-element-number mtx [ -f device ] eject # mtx -f /dev/rsst1 first mtx: No such device or address mtx: No such device or address mtx: Request Sense: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 mtx: READ ELEMENT STATUS Command Failed If I can get this simple problem fixed, I'm in buisness... -- Rhett Saunders National Office Operations email: [EMAIL PROTECTED] phone: (202) 693-3275
