Re: Restore without amanda...
Suman Malla wrote: > > While using dd with ufsrestore i.e. > > dd if=/dev/nst0 bs=32k skip=1 | gzip -d | /usr/sbin/ufsrestore -ivh - /dev/nst0 sounds like Linux but ufsrestore sounds like Solaris. Are you trying to read from the right device?
Re: Restore without amanda...
Suman Malla wrote: > > While using dd with ufsrestore i.e. > > dd if=/dev/nst0 bs=32k skip=1 | gzip -d | /usr/sbin/ufsrestore -ivh - > > I get - > > st0: Incorrect block size > dd: /dev/nst0: Input/Output error > 0+0 records in > 0+0 records out Use "mt -f /dev/nst0 setblk 32768"
tapelists permissions being changed...
Hi all, I've been scratching my head for a long time, and haven't managed to work out what is changing the permissions on this file, and so ask for some pointers! amcheck returns: ERROR: /etc/amanda/CORBETT/tapelist is not writable and sure enough, if I check out the permissions: -rw---1 root disk 104 Jan 30 01:05 tapelist I can change the permissions, but they'll be reset after the next dump. Which program writes to this file? I'm assuming that I have a broken sticky bit somewhere... but I think I've been hit with the dumb stick this week - can't find it for the life of me (I checked through the list of setuids that you sent me last time John). Cheers, Chris
RE: amreport broken between 2.4.1p1 and 2.4.2
Thanks for the tip. For those interested, I am now using: columnspec "HostName=0:10,Disk=1:18,OrigKB=1:8,OutKB=1:8,DumpRate=0:7,TapeRate=0:7" which works quite well on some of our longer hostnames and bigger disk sizes. g. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of John R. Jackson > Sent: Monday, 29 January 2001 11:56 AM > To: Grant Beattie > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: amreport broken between 2.4.1p1 and 2.4.2 > > > >The email output of amreport seems to have been broken somewhere between > >2.4.1p1 and 2.4.2. > > What you call "broken", others call a new "feature" :-). > > Look for "columnspec" in "man amanda". FYI, here's what I use: > > columnspec "OrigKB=1:8,OutKB=1:8,DumpRate=0:7,TapeRate=0:7"
RE: Restore without amanda...
While using dd with ufsrestore i.e. dd if=/dev/nst0 bs=32k skip=1 | gzip -d | /usr/sbin/ufsrestore -ivh - I get - st0: Incorrect block size dd: /dev/nst0: Input/Output error 0+0 records in 0+0 records out Any idea? -- Suman [EMAIL PROTECTED] - email "Ben Hyatt" <[EMAIL PROTECTED]> wrote: > > How can I restore files without Amanda? Thanks for your time. > > use dd along with ufsrestore. > > There's good online docs on this. > http://www.backupcentral.com/amanda-24.html > > -Ben > > > Regards, > > SMalla > > __ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com
Re: Restore without amanda...
Ben Hyatt wrote: >> How can I restore files without Amanda? Thanks for your time. > > > use dd along with ufsrestore. > > There's good online docs on this. > http://www.backupcentral.com/amanda-24.html I've had a problem using dd with skip=1, though. For some reason, dd on my system (Debian 2.2) doesn't skip the first block as it should when reading directly from the tape. I used cp to copy the dump to a scratch file and then used dd w/skip=1 and it works. You might try using dd once to read from the tape, and pass the output to 'strings' or to a file and use 'strings file' to check it. If you get a readable amanda header, then you have the same problem I have. One of these days I'll try to track it down. -Mack > > > -Ben > >> Regards, >> SMalla > -- ** Mack Earnhardt Optivel, Inc. E-mail: [EMAIL PROTECTED] Voice: 317.507.6274 Fax:800.832.5615 Web:http://www.optivel.com **
RE: Restore without amanda...
> How can I restore files without Amanda? Thanks for your time. use dd along with ufsrestore. There's good online docs on this. http://www.backupcentral.com/amanda-24.html -Ben > Regards, > SMalla
Re: Error msg interpretation
jrj wrote: Is this 2.4.2? If so, I think you're not the only one who's mentioned this. Sigh. Yes, it is. Interestingly, I think this is the first partition of mine to receive a level 3 dump. Ben
Re: Error msg interpretation
>That's interesting, considering `mars' is the tape server. I'm just telling you what it means :-). Now you'll have to start gathering more data to find out why. Is this 2.4.2? If so, I think you're not the only one who's mentioned this. Sigh. >Ben John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Restore without amanda...
>How can I restore files without Amanda? Thanks for your time. Have you read docs/RESTORE? What about: http://www.backupcentral.com/amanda.html Both cover this topic. >SMalla John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Restore without amanda...
Hi, How can I restore files without Amanda? Thanks for your time. Regards, SMalla __ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com
Re: Error msg interpretation
>FAILURE AND STRANGE DUMP SUMMARY: > mars sda7 lev 3 FAILED [data timeout] It means dumper on your server stopped getting data for 30 minutes (or whatever you set dtimeout to in amanda.conf). That's interesting, considering `mars' is the tape server. Ben
Re: Error msg interpretation
>Can anyone help me diagnose what this error message precisely means? > >FAILURE AND STRANGE DUMP SUMMARY: > mars sda7 lev 3 FAILED [data timeout] It means dumper on your server stopped getting data for 30 minutes (or whatever you set dtimeout to in amanda.conf). That, in turn, could be caused by any number of things. I'd start by looking at the client and seeing what is running for the Amanda user, looking at /tmp/amanda/sendbackup*debug, truss'ing the various backup processes, watching for network traffic, running lsof to see if anything is moving, etc. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
I/O error on tapetype program, help.
Hello, I've been getting weird errors on my nightly amanda job and saw
that there was a problem.
I currently use an EXABYTE EZ 17 Autoloader drive and had used the
TAPETYPE value given from this email group. After a few weird errors and
thinking that I had fixed them, I finally fell short when I got another
error.
I'm stuck because when I run the amdump manually Amanda runs without
hickups. When it runs on its own, it craps out on me and dumps the
remainder of the backups onto a holding disk.
I thought maybe my tapetype was wrong, so I ran it and produced the
following result: Note that this is on a 60/150 GB tape for a mammoth2
[root@quake tape-src]# tapetype -f /dev/nst1
wrote 110526 32Kb blocks in 338 files in 735 seconds (Input/output error)
wrote 102364 32Kb blocks in 628 files in 1040 seconds (Input/output error)
define tapetype unknown-tapetype {
comment "just produced by tapetype program"
length 3750 mbytes
filemark 900 kbytes
speed 3980 kps
}
Why am I getting I/O errors? I'm really confused. I get no errors when I
run amanda manually, but when it runs automagically I get this input out
error.
On amanda's email report i get:
Subject: AMANDA MAIL REPORT FOR January 29, 2001
These dumps were to tape EXA06
*** A TAPE ERROR OCCURRED: [[writing file: Input/ouput error]]/
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanada expects to use is: EXA07.
This has happend to all the tapes I have tried so far, I cannot believe
that I got a batch of bad tapes.
Tanniel Simonian
Re: Exabyte Mammoth2
I just ran the tapetype program on mine and got very intersting errors, which I will email to this group, however, the tapetype of the EZ17 has been mentioned before and if you look into the December archives of egroups you'll see them. If you can't find it I will send you the numbers. Second, the problem with make. Have you configure for the first time in the amanda src directory. From the src, make sure you make clean, and then delete config.cache. Then run configure with all of your -- options, and see if that works. Hope this helps. Tano On Mon, 29 Jan 2001, Michael T. Mader wrote: > Hi, > > has anybody done a tapetype for a Mammoth2 drive? Would be fine to know > because I am just starting a Exabyte EZ17 changer with a Mammoth2 drive. > > Thx > > Michael > > BTW: Does anybody know about this error I get with gmake/gcc when building > tapetype? > tape-src/tapetype.c:244: `O_RDWR' undeclared (first use in this function) > > > Michael Thorsten Mader > Lehrstuhl fuer Genetik und Neurobiologie > Biozentrum, Am Hubland > Universitaet Wuerzburg > 97074 Wuerzburg > 0049-931-8884466 (fon) > http://www.biozentrum.uni-wuerzburg.de/genetics/VirtualBrain/ >
Error msg interpretation
Can anyone help me diagnose what this error message precisely means? FAILURE AND STRANGE DUMP SUMMARY: mars sda7 lev 3 FAILED [data timeout] Thanks, B.
RE: why | ufsrestore?
How does one configure the blocksize? What about the blocksize used on the tape? perhaps that can be tuned, too... g. > -Original Message- > From: Marc W. Mengel [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, 30 January 2001 3:12 AM > To: [EMAIL PROTECTED] > Cc: Grant Beattie; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: why | ufsrestore? > > > > > On Sun, 28 Jan 2001, John R. Jackson wrote: > > > > But you're comparing apples and oranges. As you've noted, going from > > disk to tape on the same machine gets 3 MBytes/s whether you are using > > ufsdump or Amanda is using taper to copy a holding disk image. > > > > But that's not what happens when Amanda is dumping a client direct to > > tape. The data has to go across the network (even if it's all on the > > local machine it still goes through the kernel network stack). And, > > probably even more important, Amanda does compression when dumping, > > not when writing to tape. > > > > So a dump to holding disk would be "slow" but the corresponding holding > > disk to tape operation would be "fast". But a direct to tape backup > > would pay the penalty and show the speed loss due to compression even > > though the tape I/O portion is going as fast as it is given data. > > > > You didn't mention what kind of dump rates Amanda reports. Those should > > more or less match your direct to tape numbers for large enough images > > to get a good sample and with similar clients. > > > > Note that I'm not saying something isn't wrong in Amanda. Just that > > we need to narrow down the list of culprits. > > We've gotten excellent results here with cranking up the blocksize > of writes to the network in our old backup scripts (which always go > direct to tape). Everywhere except OSF1, which seems to get confused... > > Marc > > >
Re: |ufsrestore .. also for tar ?
* Jean-Louis Martineau <[EMAIL PROTECTED]> (Mon, Jan 29, 2001 at 03:45:03PM -0500) > It will require to much work to the sendbackup process. It > will be possible to do it with the DUMPER-API, is you have time, you > should work on the DUMPER-API. Time, yeah, heard about that .. seems to be very useful to have around ;) ... (or, sorry, but Im afraid I don';t really ahve the time to spare, though who knows ;) ) Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
Interpretation please
On a recent backup report, we received the following message: FAILURE AND STRANGE DUMP SUMMARY: amanda sd0e lev 1 FAILED [nak error:unexpected ack packet] amanda is the name of the backup server. I dump'ed the partition by hand, and saw no problems. Anyone know what went wrong? Thanks! Andrew Robinson * Andrew W. Robinson | Voice: +1 (504)-889-2784 * * Computerized Processes Unlimited, Inc. | FAX:+1 (504)-889-2799 * * 4200 S. I-10 Service Rd., Suite 205| E-Mail: [EMAIL PROTECTED] * * Metairie, LA 70001 | WWW: http://www.cpu.com * * "Consulting System Integrators" *
Re: |ufsrestore .. also for tar ?
On Mon, Jan 29, 2001 at 09:05:21PM +0100, Gerhard den Hollander wrote: > * Alexandre Oliva <[EMAIL PROTECTED]> (Mon, Jan 29, 2001 at 05:59:16PM -0200) > > On Jan 29, 2001, Gerhard den Hollander <[EMAIL PROTECTED]> wrote: > > >> doing a tar cvf .. should give you a full list of everything being backed > >> up ? > > > The problem is that you wouldn't be able to tell error messages from > > the actual file list. So we do throw a `tar tf' in the pipeline. > > How about soimething like: > Anything not starting with a / is an error message ? > Anything with Warning: in it is a warning > Anything with exclude in it is an exclude message,. > anything else is a file being taped ? > > If there is interest, I can hack up a perl filter that filters out all > warnings, errors and exclud emessages, leaving in only the files being > dumped. It will require to much work to the sendbackup process. It will be possible to do it with the DUMPER-API, is you have time, you should work on the DUMPER-API. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Client stopped responding, Request timed out
I've been running Amanda 2.4.2 for several months now. I have a client, client.foo.com that has stopped responding and here's what I get from the Amanda report: FAILURE AND STRANGE DUMP SUMMARY client.foo. /disk1 lev 0 FAILED [Request to client.foo.com timed out.] client.foo. /var lev 0 FAILED [Request to client.foo.com timed out.] client.foo. /usr lev 0 FAILED [Request to client.foo.com timed out.] client.foo. /home lev 0 FAILED [Request to client.foo.com timed out.] client.foo. / lev 0 FAILED [Request to client.foo.com timed out.] Amanda is launched from inetd and I did verify that inetd was running. Both client and amanda server are connected to switched 100 Mbps ports so speed isn't necessarily an issue. I also increased the the timeouts (although ctimeout I just raised from 30 to 60): etimeout1200 dtimeout1800 ctimeout60 Here is the debug files for client.foo.com: amandad.debug amandad: debug 1 pid 10696 ruid 520 euid 520 start time Sun Jan 28 22:30:49 2001 amandad: version 2.4.2 amandad: build: VERSION="Amanda-2.4.2" amandad: BUILT_DATE="Thu Jul 6 13:33:02 CDT 2000" amandad: BUILT_MACH="Linux client.foo.com 2.2.5-22 #1 Wed Jun 2 09:17:03 EDT 1999 i686 unknown" amandad: CC="gcc" amandad: paths: bindir="/usr/local/amanda/bin" amandad: sbindir="/usr/local/amanda/sbin" amandad: libexecdir="/usr/local/amanda/libexec" amandad: mandir="/usr/local/man" AMANDA_TMPDIR="/tmp/amanda" amandad: AMANDA_DBGDIR="/tmp/amanda" amandad: CONFIG_DIR="/usr/local/amanda/etc" DEV_PREFIX="/dev/" amandad: RDEV_PREFIX="/dev/" DUMP="/sbin/dump" amandad: RESTORE="/sbin/restore" SAMBA_CLIENT="/usr/bin/smbclient" amandad: GNUTAR="/usr/local/bin/tar" COMPRESS_PATH="/usr/bin/gzip" amandad: UNCOMPRESS_PATH="/usr/bin/gzip" MAILER="/usr/bin/Mail" amandad: listed_incr_dir="/usr/local/amanda/var/gnutar-lists" amandad: defs: DEFAULT_SERVER="amanda.foo.com" amandad: DEFAULT_CONFIG="daily" amandad: DEFAULT_TAPE_SERVER="amanda.foo.com" amandad: DEFAULT_TAPE_DEVICE="/dev/nrsa0" HAVE_MMAP HAVE_SYSVSHM amandad: LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE BSD_SECURITY amandad: USE_AMANDAHOSTS CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP amandad: COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" amandad: COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" got packet: Amanda 2.4 REQ HANDLE 004-80310808 SEQ 980742604 SECURITY USER amanda SERVICE sendsize OPTIONS maxdumps=2;hostname=client.foo.com; DUMP /drive1 0 1970:1:1:0:0:0 -1 DUMP /drive1 1 2001:1:10:6:20:15 -1 DUMP /var 0 1970:1:1:0:0:0 -1 DUMP /var 1 2001:1:17:2:42:18 -1 DUMP /usr 0 1970:1:1:0:0:0 -1 DUMP /usr 1 2001:1:18:2:25:44 -1 DUMP /home 0 1970:1:1:0:0:0 -1 DUMP /home 1 2001:1:21:5:26:24 -1 GNUTAR / 0 1970:1:1:0:0:0 -1 exclude-list=/usr/local/amanda/exclude GNUTAR / 1 2001:1:20:5:28:22 -1 exclude-list=/usr/local/amanda/exclude sending ack: Amanda 2.4 ACK HANDLE 004-80310808 SEQ 980742604 bsd security: remote host amanda.foo.com user amanda local user amanda amandahosts security check passedamandad: running service "/usr/local/amanda/libexec/sendsize" selfcheck.debug selfcheck: debug 1 pid 16214 ruid 520 euid 520 start time Sun Jan 28 19:00:47 2001 /usr/local/amanda/libexec/selfcheck: version 2.4.2 checking disk /disk1: device /dev/sdb1: OK checking disk /var: device /dev/sda6: OK checking disk /usr: device /dev/sda5: OK checking disk /home: device /dev/sda8: OK checking disk /: device /: OK selfcheck: pid 16214 finish time Sun Jan 28 19:00:47 2001 runtar.debug runtar: debug 1 pid 10702 ruid 520 euid 0 start time Sun Jan 28 22:30:50 2001 /usr/local/bin/tar: version 2.4.2 running: /usr/local/bin/tar: /usr/local/bin/tar --create --directory / --listed-incremental /usr/local/amanda/var/gnutar-lists/client.foo.com__0.new --sparse --one-file-system --ignore-failed-read --totals --file /dev/null --exclude-from /usr/local/amanda/exclude . sendsize.debug sendsize: debug 1 pid 10697 ruid 520 euid 520 start time Sun Jan 28 22:30:50 2001 /usr/local/amanda/libexec/sendsize: version 2.4.2 amandates botch: /dev/sda1 lev 0: new dumpdate 959404817 old 979968536 amandates botch: /dev/sda5 lev 0: new dumpdate 959405582 old 979784774 amandates botch: /dev/sda6 lev 0: new dumpdate 959405079 old 979699366 amandates botch: /dev/sda6 lev 1: new dumpdate 958789394 old 980054948 amandates botch: /dev/sda8 lev 0: new dumpdate 959404910 old 980054819 amandates botch: /dev/sdb1 lev 0: new dumpdate 959404801 old 979107633 calculating for amname '/', dirname '/' calculating for amname '/home', dirname '/home' calculating for amname '/usr', dirname '/usr' sendsize: getting size via gnutar for / level 0 sendsize: getting size via dump for /home level 0 sendsize: running "/sbin/dump 0sf 1048576 - /dev/sda8" running /usr/local/amanda/libexec/killpgrp sendsize: running "/usr/local/amanda/libexec/runtar --create --directory / --listed-incremental /usr/local/amanda/var/gnutar-lists/client.foo.co
Exabyte Mammoth2
Hi, has anybody done a tapetype for a Mammoth2 drive? Would be fine to know because I am just starting a Exabyte EZ17 changer with a Mammoth2 drive. Thx Michael BTW: Does anybody know about this error I get with gmake/gcc when building tapetype? tape-src/tapetype.c:244: `O_RDWR' undeclared (first use in this function) Michael Thorsten Mader Lehrstuhl fuer Genetik und Neurobiologie Biozentrum, Am Hubland Universitaet Wuerzburg 97074 Wuerzburg 0049-931-8884466 (fon) http://www.biozentrum.uni-wuerzburg.de/genetics/VirtualBrain/
Re: |ufsrestore .. also for tar ?
* Alexandre Oliva <[EMAIL PROTECTED]> (Mon, Jan 29, 2001 at 05:59:16PM -0200) > On Jan 29, 2001, Gerhard den Hollander <[EMAIL PROTECTED]> wrote: >> doing a tar cvf .. should give you a full list of everything being backed >> up ? > The problem is that you wouldn't be able to tell error messages from > the actual file list. So we do throw a `tar tf' in the pipeline. How about soimething like: Anything not starting with a / is an error message ? Anything with Warning: in it is a warning Anything with exclude in it is an exclude message,. anything else is a file being taped ? If there is interest, I can hack up a perl filter that filters out all warnings, errors and exclud emessages, leaving in only the files being dumped. Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
Re: |ufsrestore .. also for tar ?
On Jan 29, 2001, Gerhard den Hollander <[EMAIL PROTECTED]> wrote:
> doing a tar cvf .. should give you a full list of everything being backed
> up ?
The problem is that you wouldn't be able to tell error messages from
the actual file list. So we do throw a `tar tf' in the pipeline.
--
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
|ufsrestore .. also for tar ?
sidenote: since egroups went yahoo, I haven';t eben able to access the searchable archives .. Is this just Konqueror, or is it broken ? Anyway, When dumping with ufsdump, amanda pipes through ufsrestore to get an index .. fair enough However, when dumping via tar, we dont need this, right ? doing a tar cvf .. should give you a full list of everything being backed up ? (well, maybe we need a grep -v excluded pipe or something smart like that ) So is amanda doing that ? Or does she do a tar cf - . | tar tvf - ?? Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
Re: Where is tar 1.13.19
On Jan 29, 2001, Jonathan Dill <[EMAIL PROTECTED]> wrote:
> Do you know how to build binary RPMs optimized for other architecture
> eg. i586 and i686? I think you have to do something to the spec file,
> but I'm not sure what.
I think it's enough to build it with -march=i686 -mcpu=i686. I
believe Mandrake used to build packages optimized for i586; it might
be that they've switched to i686 already.
--
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: amanda 2.4.2
>I have decided to upgrade amanada 2.4.1p1 to 2.4.2 Version 2.4.2p1 has been released and you should probably use it. There is at least one fairly important bug fix. > Clem Kumah[EMAIL PROTECTED] John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda 2.4.2
>From: "Patrick M. Hausen" <[EMAIL PROTECTED]> >Date: Mon, 29 Jan 2001 19:49:46 +0100 (CET) >Doesn't installing Amanda from /usr/ports/misc/amanda24 work for you? I started with amanda from "ports" back in '98, but it became rather too awkward to ensure that the Solaris boxen also had amanda configured the same way. And I migrated to 2.4.2p1 well before a "port" was available for it. >The recommended way to install software on a FreeBSD system is using >the ports collection. Well, I find the FreeBSD "ports" system a curious combination of convenience and frustration, largely, no doubt, because I'm far more accustomed to obtaining the sources for software, configuring, and building it. I haven't learned enough about the "ports" system to be able to have anywhere near as much control as easily as I do with the old-fashioned mechanism I'm used to. For cases where I want things installed the same way the port maintainer did them, the "ports" are very nice -- and that's the majority of cases. But in the case of amanda, especially in a heterogeneous environment, I found it very awkward... especially when I was trying out some of my own patches (for example). And given the present state of amanda's development, where a great deal is determined prior to compilation (at configuration time), I am reluctant to recommend any approach for installing amanda that does not expose the installer to the configuration process in all its detail. (Witness the issues brought forth by folks who install amanda "RPMs" on Linux systems, for example.) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: amanda 2.4.2
Hi all! David Wolfskill wrote: > >Date: Mon, 29 Jan 2001 18:02:38 + > >From: Clem Kumah <[EMAIL PROTECTED]> > > >I have decided to upgrade amanada 2.4.1p1 to 2.4.2 > >When I try to do a make command I get the following error: > > >make: don't know how to make amoverview. Stop > >*** Error code 1 > > >I seem to recal that it needs gnu make. Is this correct, and where can I > >get a copy? > > >I am runing it on a freebsd 4.2-Release > > It does not need GNU make (gmake; see /usr/ports/devel/gmake), although > using gmake appears to work. It needs a working (as in "not broken") > make. Unfortunately, the PR that I filed with the FreeBSD folks > (http://www.freebsd.org/cgi/query-pr.cgi?pr=23328) doesn't appear to > have received a great deal of attention from those necessary to get the > matter addressed. If you would follow-up on that PR, to let folks knwo > that others are being affected, I would appreciate it. > [...] Doesn't installing Amanda from /usr/ports/misc/amanda24 work for you? The recommended way to install software on a FreeBSD system is using the ports collection. The port of Amanda is almost up to date wr/t Amanda development - i.e. it fetches and installs Amanda 2.4.2. It should install Amanda 2.4.2p1 just fine, just: cd /usr/ports/misc/amanda24 vi Makefile # change 2.4.2 to 2.4.2p1 rm distinfo make makesum make install HTH, Patrick -- --- WEB ISS GmbH - Scheffelstr. 17a - 76135 Karlsruhe - 0721/9109-0 --- -- Patrick M. Hausen - Technical Director - [EMAIL PROTECTED] --- "Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat."
Re: amanda 2.4.2
>Date: Mon, 29 Jan 2001 18:02:38 + >From: Clem Kumah <[EMAIL PROTECTED]> >I have decided to upgrade amanada 2.4.1p1 to 2.4.2 >When I try to do a make command I get the following error: >make: don't know how to make amoverview. Stop >*** Error code 1 >I seem to recal that it needs gnu make. Is this correct, and where can I >get a copy? >I am runing it on a freebsd 4.2-Release It does not need GNU make (gmake; see /usr/ports/devel/gmake), although using gmake appears to work. It needs a working (as in "not broken") make. Unfortunately, the PR that I filed with the FreeBSD folks (http://www.freebsd.org/cgi/query-pr.cgi?pr=23328) doesn't appear to have received a great deal of attention from those necessary to get the matter addressed. If you would follow-up on that PR, to let folks knwo that others are being affected, I would appreciate it. In the mean time, someone else in the FreeBSD community came up with some patches against FreeBSD-CURRENT to fix the problem, and sent them to me. I ported them to FreeBSD 4.2-STABLE (which should be very close to -RELEASE), and both sets may be found in his PR, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24102. Summarizing: either installing GNU make (from /usr/ports/devel/gmake) and using gmake to build amanda, or patching the native FreeBSD make per http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24102 should do the trick for you. And regardless of which approach you tak, please update http://www.freebsd.org/cgi/query-pr.cgi?pr=23328 to let folks know that action to resolve this would be helpful. (If you need to modify the patches in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24102 for 4.2-R, it would be good to follow up on that, as well.) Cheers, david -- David Wolfskill [EMAIL PROTECTED] UNIX System Administrator Desk: 650/577-7158 TIE: 8/499-7158 Cell: 650/759-0823
Re: amrecover: cannot connect to host (connection refused)
I was getting connection refused on amrecover for a while. The
.amandahosts file allowed access to root@localhost, but amrecover would
use root@servername and fail. My solution was to use the server name
explicitly in both .amandahosts and disklist.
Hope this help one of your problems. :)
-Mack
Sebastian Frankfurt wrote:
> Hello,
>
> I am using RedHat 7.0 with xinetd-2.1.8.9pre11-1.
> amcheck and amdump are working properly, but if I want
> to restore files from dump using amrecover, the tool
> is not working.
> Everything is called from the same host (localhost).
>
> This is what the amrecover sends to stdout:
>
>AMRECOVER Version 2.4.1p1. Contacting server on localhost ...
>amrecover: Unexpected server end of file
>
>
> And this is what I found in /var/log/messages:
>
>Jan 29 07:51:51 myhost xinetd[1318]: xinetd Version 2.1.8.9pre11
> started with
>Jan 29 07:51:51 myhost xinetd[1318]: libwrap
>Jan 29 07:51:51 myhost xinetd[1318]: options compiled in.
>Jan 29 07:51:51 myhost xinetd[1318]: Started working: 8 available
> services
>Jan 29 07:51:54 myhost xinetd: xinetd startup succeeded
>Jan 29 07:52:07 myhost xinetd[1318]: warning: can't get client
> address: Invalid argument
>Jan 29 07:52:07 myhost xinetd[1318]: file descriptor of service
> amandaidx has been closed
>Jan 29 07:52:07 myhost xinetd[1318]: select reported EBADF but no bad
> file descriptors were found
>
>
> I think, the problem is:
>
> warning: can't get client address: Invalid argument
>
> but do you know when this could happened?
>
>
> This happens only the very first time, if I try to connect
> via amrecover the next time, nothing happens in the syslog,
> but the amrecover client barfs:
>
>AMRECOVER Version 2.4.1p1. Contacting server on localhost ...
>amrecover: Error connecting to server: Connection refused
>
>
> It is possible for operator and root to do an rsh localhost .
>
> The permissions for /root/.rhosts
> -rw---1 root root25 Jan 28 23:44 /root/.rhosts
>
> The permissions for /root/.amandahosts
> -rw---1 operator disk 107 Jan 29 00:29 /root/.amandahosts
>
> Amanda-User: operator
> User Operator is in 'disk' group.
>
> If you need the information of /etc/xinet.d/am*
> I will attach these files. I tried to use the amanda inetd-entries
> w/o tcp_wrappers, but the errors are still the same.
>
> I will also put the debug output of /tmp/amanda to this mail.
>
> So, I am not subscribed to the mailing list, please
> do a CC to mailto:[EMAIL PROTECTED]
>
> Any suggestions?
>
> thanx in advance,
>
> Sebastian
>
>
>
>
> # default: on
> #
> # description: Part of the Amanda server package
>
> service amanda
> {
> socket_type = dgram
> protocol= udp
> wait= yes
> user= operator
> group = disk
> server = /usr/lib/amanda/amandad
> disable = no
> }
>
>
>
>
> # default: off
> #
> # description: Part of the Amanda server package
> #
>
> service amandaidx
> {
> socket_type = stream
> protocol= tcp
> wait= yes
> user= operator
> group = disk
> server = /usr/lib/amanda/amindexd
> disable = no
> }
>
>
>
>
> # default: off
> #
> # description: Part of the amanda server package
> #
>
> service amidxtape
> {
> socket_type = stream
> protocol= tcp
> wait= no
> user= operator
> group = disk
> server = /usr/lib/amanda/amidxtaped
> disable = no
> }
>
>
>
>
> amandad: debug 1 pid 932 ruid 11 euid 11 start time Mon Jan 29 07:34:19 2001
> amandad: version 2.4.1p1
> amandad: build: VERSION="Amanda-2.4.1p1"
> amandad:BUILT_DATE="Mon Aug 21 16:31:37 EDT 2000"
> amandad:BUILT_MACH="Linux porky.devel.redhat.com 2.2.5-22smp #1 SMP Wed Jun
>2 09:11:51 EDT 1999 i686 unknown"
> amandad:CC="gcc"
> amandad: paths: bindir="/usr/bin" sbindir="/usr/sbin"
> amandad:libexecdir="/usr/lib/amanda" mandir="/usr/share/man"
> amandad:CONFIG_DIR="/etc/amanda" DEV_PREFIX="/dev/"
> amandad:RDEV_PREFIX="/dev/r" DUMP="/sbin/dump"
> amandad:RESTORE="/sbin/restore" SAMBA_CLIENT="/usr/bin/smbclient"
> amandad:GNUTAR="/bin/tar" COMPRESS_PATH="/usr/bin/gzip"
> amandad:UNCOMPRESS_PATH="/usr/bin/gzip" MAILER="/usr/bin/Mail"
> amandad:
RE: amanda 2.4.2
> I am runing it on a freebsd 4.2-Release On my openbsd box I see gmake in my ports tree here. (bhyatt)@kawasaki:/usr/ports/devel/gmake:[115]> HTH -Ben > Clem Kumah > [EMAIL PROTECTED] > System Administrator / Teamleader www.worldonline.co.uk World Online UK+44 (0) 870 748
amanda 2.4.2
Hi, I have decided to upgrade amanada 2.4.1p1 to 2.4.2 When I try to do a make command I get the following error: make: don't know how to make amoverview. Stop *** Error code 1 I seem to recal that it needs gnu make. Is this correct, and where can I get a copy? I am runing it on a freebsd 4.2-Release Thanks in advance. -- Clem Kumah [EMAIL PROTECTED] System Administrator / Teamleader www.worldonline.co.uk World Online UK+44 (0) 870 748
Re: why | ufsrestore?
On Sun, 28 Jan 2001, John R. Jackson wrote: > > But you're comparing apples and oranges. As you've noted, going from > disk to tape on the same machine gets 3 MBytes/s whether you are using > ufsdump or Amanda is using taper to copy a holding disk image. > > But that's not what happens when Amanda is dumping a client direct to > tape. The data has to go across the network (even if it's all on the > local machine it still goes through the kernel network stack). And, > probably even more important, Amanda does compression when dumping, > not when writing to tape. > > So a dump to holding disk would be "slow" but the corresponding holding > disk to tape operation would be "fast". But a direct to tape backup > would pay the penalty and show the speed loss due to compression even > though the tape I/O portion is going as fast as it is given data. > > You didn't mention what kind of dump rates Amanda reports. Those should > more or less match your direct to tape numbers for large enough images > to get a good sample and with similar clients. > > Note that I'm not saying something isn't wrong in Amanda. Just that > we need to narrow down the list of culprits. We've gotten excellent results here with cranking up the blocksize of writes to the network in our old backup scripts (which always go direct to tape). Everywhere except OSF1, which seems to get confused... Marc
Re: Where is tar 1.13.19
Mandrake Cooker has RPM and SRPM for tar 1.13.19 and you can get it on rpmfind.net. I suggest building from the src.rpm unless you're running Mandrake: http://rpmfind.net/linux/RPM/cooker//cooker/SRPMS//tar-1.13.19-4mdk.src.html I have no idea if this is "stable" but I'm going to test it out. Do you know how to build binary RPMs optimized for other architecture eg. i586 and i686? I think you have to do something to the spec file, but I'm not sure what. Josh Kuperman wrote: > I saw that tar (gtar?) 1.13.19 is the right version to use. I checked > both the Free Software Foundations's site as well as rpmfind.net (just > in case my life would be easy.) and 1.13.17 seemed to be the latest. > > Where should I be looking? -- "Jonathan F. Dill" ([EMAIL PROTECTED])
Re: amanda-2.4.2-beta2
Hello! Clem Kuma wrote: > Where can I find gnu make for Freebsd? # cd /usr/ports/devel/gmake # make install clean will do the trivck on a FreeBSD system with the ports collection installed. If you prefer to install precompiled binaries try ftp://ftp.freebsd.org/pub/FreeBSD/ports/packages/All (I haven't tried the latter - I always install from source) Additionally: there's an Amanda port in the ports collection: /usr/ports/misc/amanda24 Chances are it will compile your version just fine if you update the checksums or use "make NO_CHECKSUM=yes" HTH, Patrick -- --- WEB ISS GmbH - Scheffelstr. 17a - 76135 Karlsruhe - 0721/9109-0 --- -- Patrick M. Hausen - Technical Director - [EMAIL PROTECTED] --- "Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat."
Re: amanda-2.4.2-beta2
Where can I find gnu make for Freebsd? > > On Thu, Oct 26, 2000 at 01:07:57PM -0300, The Hermit Hacker wrote: > > On 26 Oct 2000, Alexandre Oliva wrote: > > > > > On Oct 26, 2000, The Hermit Hacker <[EMAIL PROTECTED]> wrote: > > > > > > > make: don't know how to make amoverview. Stop > > > > *** Error code 1 > > > > > > > Stop in /usr/local/mp3/amanda/src/amanda-2.4.2b2. > > > > > > Is there a file named amoverview.pl.in in the tarball? Didn't > > > `configure' create `amoverview.pl' out of it? > > > > yes on both counts: > > > > > find . -name "amoverview.pl*" -print > > ./server-src/amoverview.pl.in > > ./server-src/amoverview.pl > > Which make are you using? Is it gnu make? > > Jean-Louis > -- > Jean-Louis Martineau email: [EMAIL PROTECTED] > Departement IRO, Universite de Montreal > C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 > Montreal, Canada, H3C 3J7Fax: (514) 343-5834 -- Clem Kumah [EMAIL PROTECTED] System Administrator / Teamleader www.worldonline.co.uk World Online UK+44 (0) 870 748
Re: Where is tar 1.13.19
You can find it here: ftp://alpha.gnu.org/pub/gnu/tar Jim > I saw that tar (gtar?) 1.13.19 is the right version to use. I checked > both the Free Software Foundations's site as well as rpmfind.net (just > in case my life would be easy.) and 1.13.17 seemed to be the latest. > > Where should I be looking? > > > -- > Josh Kuperman > [EMAIL PROTECTED] >
Where is tar 1.13.19
I saw that tar (gtar?) 1.13.19 is the right version to use. I checked both the Free Software Foundations's site as well as rpmfind.net (just in case my life would be easy.) and 1.13.17 seemed to be the latest. Where should I be looking? -- Josh Kuperman [EMAIL PROTECTED]
Re: why | ufsrestore?
* Jean-Louis Martineau <[EMAIL PROTECTED]> (Mon, Jan 29, 2001 at 08:59:30AM -0500) > On Mon, Jan 29, 2001 at 02:42:04PM +0100, Gerhard den Hollander wrote: > > It's not the compression (or at leat not only the compression) that gives > > the penalty, but more likely the 5 way split .. > > > > As long as Im doing incrementals it isn't too bad, since those dump to > > disk, and from disk to tape is fast. > > Your drive must not be streaming because of latency in the pipes, > try increasing tapebufs in amanda.conf. Does increasing tapebufs improve the speed in which amanda dump to disk ? I thought tapebufs was only for dumping to tape ? Gerhard, (@jasongeo.com) == The Acoustic Motorbiker == -- __0 What do you mean, "I hurt your feelings"? =`\<, I didn't know you had any feelings. (=)/(=) What do you mean, "I ain't kind"? I'm just not your kind.
Re: why | ufsrestore?
On Mon, Jan 29, 2001 at 02:42:04PM +0100, Gerhard den Hollander wrote: > It's not the compression (or at leat not only the compression) that gives > the penalty, but more likely the 5 way split .. > > As long as Im doing incrementals it isn't too bad, since those dump to > disk, and from disk to tape is fast. Your drive must not be streaming because of latency in the pipes, try increasing tapebufs in amanda.conf. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Re: why | ufsrestore?
* John R. Jackson <[EMAIL PROTECTED]> (Sun, Jan 28, 2001 at 08:20:30PM -0500) >>I have always wondered .. why does amanda pipe ufsdump output to ufsrestore >>before sending it to the tape device? > It's collecting the index data. > The dump (or tar) output pipeline is rather complicated. The image data > goes back to sendbackup who in turn tee's it to the restore program > to gather the index information (if indexing is enabled) as well as > sending the raw data (possibly through a compression program) back on > the network to a dumper process on the server side. The restore program > also feeds its results back through sendbackup to be sent to the dumper > on a different socket (as I recall). So sendbackup is multiplexing five > data streams: > > * reading the dump image coming in from the backup program > > * writing the image out to the index (restore) process > > * writing the image out the socket connected to dumper on the server > or to a compression program > > * reading the output of the index process > > * writing the index data to another socket back to dumper Allright, that explains a lot. Thanks very much. >>If I ufsdump direct to tape, eg. >> >>ufsdump 0f /dev/rmt/0n / >> >>I consistently achieve 3mb/second (Exabyte mammoth). >> >>If amanda is dumping direct to tape (file systems that are bigger than the >>holding disk), I'm lucky if i get 1mb/second. >> >>If it's going from the holding disk to tape, I get 3mb/second, as expected. > But you're comparing apples and oranges. As you've noted, going from > disk to tape on the same machine gets 3 MBytes/s whether you are using > ufsdump or Amanda is using taper to copy a holding disk image. > But that's not what happens when Amanda is dumping a client direct to > tape. The data has to go across the network (even if it's all on the > local machine it still goes through the kernel network stack). And, > probably even more important, Amanda does compression when dumping, > not when writing to tape. Even with compression disabled, amanda is much slower. Dumper gets between .5 and 3kbps (disk and tape all on server ). Taper gets 7-8Kbps [see below for more detailed report] > So a dump to holding disk would be "slow" but the corresponding holding > disk to tape operation would be "fast". But a direct to tape backup > would pay the penalty and show the speed loss due to compression even > though the tape I/O portion is going as fast as it is given data. It's not the compression (or at leat not only the compression) that gives the penalty, but more likely the 5 way split .. As long as Im doing incrementals it isn't too bad, since those dump to disk, and from disk to tape is fast. When doing a 0dump of a 100+G tar directory it becomes painfull ;) > You didn't mention what kind of dump rates Amanda reports. Those should > more or less match your direct to tape numbers for large enough images > to get a good sample and with similar clients. > Note that I'm not saying something isn't wrong in Amanda. Just that we > need to narrow down the list of culprits. Using the atatched script, I got the following out of my latest amdump file (all disks are local to the amanda server all disks are wide scsi (80Mbps ) or better (LVD) ) (usage, getbps.pl amdumpfile ) DUMPER: 17.7 TAPER: 55.6 DUMPER: 8.7 TAPER: 47.7 DUMPER: 565.9 TAPER: 2886.3 DUMPER: 1431.6 TAPER: 9620.7 DUMPER: 294.6 TAPER: 6414.0 DUMPER: 3061.4 DUMPER: 2249.5 TAPER: 9787.8 TAPER: 2884.3 DUMPER: 1027.1 TAPER: 7059.3 DUMPER: 2077.8 TAPER: 6033.7 DUMPER: 1869.2 TAPER: 5516.5 DUMPER: 2913.1 TAPER: 7524.7 DUMPER: 1671.4 TAPER: 8072.4 DUMPER: 1423.8 TAPER: 6464.1 DUMPER: 1216.9 DUMPER: 2204.8 TAPER: 7347.8 TAPER: 6818.4 DUMPER: 1796.7 TAPER: 6793.8 DUMPER: 1584.8 TAPER: 7249.1 DUMPER: 2673.5 TAPER: 11384.8 DUMPER: 4331.9 TAPER: 4330.9 DUMPER: 2742.2 TAPER: 2742.1 Averages Dumper 1758.13 Taper 5951.7 The same script run over the last 10orso amdump files I had still on disk (output stripped to only show the averages) gives Averages Dumper 1124.84210526316 Taper 4952.77368421053 Averages Dumper 1198.96 Taper 4038.22 Averages Dumper 1762.467 Taper 7299.05 Averages Dumper 1758.13 Taper 5951.7 Averages Dumper 1523.978 Taper 5017.5 Averages Dumper 899.25 Taper 4525.7625 Averages Dumper 1771.47 Taper 5564.87 Averages Dumper 1658.56 Taper 6897.71 Averages Dumper 82.1 Taper 3085.6 Averages Dumper 95.81 Taper 3129.7 Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely fo
Re: Amrecover, Invalid directory error
* Alexandre Oliva <[EMAIL PROTECTED]> (Mon, Jan 29, 2001 at 11:07:59AM -0200) >> Ehm, >> docs INSTALL sais, use 1.12 w/ patches. >> I assumed (incorrectly) that 1.13 would work as well. > It's fixed in 2.4.2p1. So I noticed ;) Will 1.13.17 work ? >>> Yep, but there's a (rare?) bug in 1.13.17 that may cause it to crash. >> I just tested it >> ()I know, why ask, if you can test it yourself) >> and 1.13.17 works fine (the one that comes with Suse 7.0) > Which doesn't mean it wouldn't crash for you at certain obscure > conditions. Jean-Louis Martineau posted a message about the problem > (with patch) it a while ago. His patch made it to 1.13.19. As well > as his improvements for GNU tar to use hash tables instead of linear > searches for filenames, which should make it significantly faster. OK, I will install 1.13.19 on the linux boxen as well. However, it doesn;t give me a huge performance boost .. it still takes well over 3 hours to get an estimate ;) Gerhard, <@jasongeo.com> == The Acoustic Motorbiker == -- __O Some say the end is near. =`\<, Some say we'll see armageddon soon (=)/(=) I certainly hope we will I could use a vacation
Re: Amrecover, Invalid directory error
On Jan 29, 2001, Gerhard den Hollander <[EMAIL PROTECTED]> wrote:
>> As in docs/INSTALL?
> Ehm,
> docs INSTALL sais, use 1.12 w/ patches.
> I assumed (incorrectly) that 1.13 would work as well.
It's fixed in 2.4.2p1.
>>> Will 1.13.17 work ?
>> Yep, but there's a (rare?) bug in 1.13.17 that may cause it to crash.
> I just tested it
> ()I know, why ask, if you can test it yourself)
> and 1.13.17 works fine (the one that comes with Suse 7.0)
Which doesn't mean it wouldn't crash for you at certain obscure
conditions. Jean-Louis Martineau posted a message about the problem
(with patch) it a while ago. His patch made it to 1.13.19. As well
as his improvements for GNU tar to use hash tables instead of linear
searches for filenames, which should make it significantly faster.
--
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: Amrecover, Invalid directory error
* Alexandre Oliva <[EMAIL PROTECTED]> (Mon, Jan 29, 2001 at 07:07:01AM -0200) > On Jan 29, 2001, Gerhard den Hollander <[EMAIL PROTECTED]> wrote: Sure enough, GNU tar 1.13. Will version 1.11.8, or 1.12 work? >>> >>> I don't think 1.11.* will work. 1.12 will work if you apply the patches >>> from www.amanda.org. 1.13.19 is reported to work. >> Could this be added to the docs, please ? > As in docs/INSTALL? Ehm, docs INSTALL sais, use 1.12 w/ patches. I assumed (incorrectly) that 1.13 would work as well. >> Will 1.13.17 work ? > Yep, but there's a (rare?) bug in 1.13.17 that may cause it to crash. I just tested it ()I know, why ask, if you can test it yourself) and 1.13.17 works fine (the one that comes with Suse 7.0) Im using 1.13.19 for the Solaris boxen. Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
Re: Amrecover, Invalid directory error
On Jan 29, 2001, Gerhard den Hollander <[EMAIL PROTECTED]> wrote:
> * John R. Jackson <[EMAIL PROTECTED]> (Fri, Jan 26, 2001 at 01:05:47PM -0500)
>> > Sure enough, GNU tar 1.13. Will version 1.11.8, or 1.12 work?
>>
>> I don't think 1.11.* will work. 1.12 will work if you apply the patches
>> from www.amanda.org. 1.13.19 is reported to work.
> Could this be added to the docs, please ?
As in docs/INSTALL?
> Will 1.13.17 work ?
Yep, but there's a (rare?) bug in 1.13.17 that may cause it to crash.
--
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: Amrecover, Invalid directory error
* John R. Jackson <[EMAIL PROTECTED]> (Fri, Jan 26, 2001 at 01:05:47PM -0500) > > Sure enough, GNU tar 1.13. Will version 1.11.8, or 1.12 work? > > I don't think 1.11.* will work. 1.12 will work if you apply the patches > from www.amanda.org. 1.13.19 is reported to work. Could this be added to the docs, please ? Will 1.13.17 work ? Kind regards, -- Gerhard den Hollander Phone +31-10.280.1515 Technical Support Jason Geosystems BV Fax +31-10.280.1511 (When calling please note: we are in GMT+1) [EMAIL PROTECTED] POBox 1573 visit us at http://www.jasongeo.com 3000 BN Rotterdam JASON...#1 in Reservoir CharacterizationThe Netherlands This e-mail and any attachment is/are intended solely for the named addressee(s) and may contain information that is confidential and privileged. If you are not the intended recipient, we request that you do not disseminate, forward, distribute or copy this e-mail message. If you have received this e-mail message in error, please notify us immediately by telephone and destroy the original message.
