Re: GNU tar versions (was: Backups failing on Solaris 9 with GNU tar)
On Monday 17 January 2005 10:56, Eric Siegerman wrote: >On Mon, Jan 17, 2005 at 04:45:18AM -0500, Gene Heskett wrote: >> So I'm puzzled as to whether I'm still doing something wrong, or >> this new tar doesn't recognize the '-f... -' for the stdin from a >> pipe option. > >That "..." is a placeholder for "x or t, with whatever other >options you want, e.g. v"; you're not meant to type it literally. > >> /bin/gtar: ./.kde/share/apps/RecentDocuments/cdrom.desktop: time >> stamp 2020-04-27 15:36:21 is 482063157 s in the future > >Do the original files have the same bad timestamps? That'll >determine whether this is really a bug or version incompatibility >in tar, or just a case of shooting the messenger... Well, since both versions show the same errors, I'd have to assume the error is real in the files themselves. I have years old messages in my inbox here that carry dates in the middle of the 2020's because of that. But TBT, I haven't looked at the specific files mentioned either. This system has been known to have a totally bogus clock for an hour or so after a crash, so much so that I now have a call to ntpdate -settime in my rc.local file, to crash set the clock correctly, and thats been working pretty good as long as the bootup can find the module eth0 needs called 'forcedeth' and I have networking. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.32% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: GNU tar versions (was: Backups failing on Solaris 9 with GNU tar)
On Mon, Jan 17, 2005 at 04:45:18AM -0500, Gene Heskett wrote: > So I'm puzzled as to whether I'm still doing something wrong, or this > new tar doesn't recognize the '-f... -' for the stdin from a pipe > option. That "..." is a placeholder for "x or t, with whatever other options you want, e.g. v"; you're not meant to type it literally. > /bin/gtar: ./.kde/share/apps/RecentDocuments/cdrom.desktop: time stamp > 2020-04-27 15:36:21 is 482063157 s in the future Do the original files have the same bad timestamps? That'll determine whether this is really a bug or version incompatibility in tar, or just a case of shooting the messenger... -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The animal that coils in a circle is the serpent; that's why so many cults and myths of the serpent exist, because it's hard to represent the return of the sun by the coiling of a hippopotamus. - Umberto Eco, "Foucault's Pendulum"
Re: GNU tar versions (was: Backups failing on Solaris 9 with GNU tar)
On Sunday 16 January 2005 16:57, Gene Heskett wrote: >On Sunday 16 January 2005 15:47, Kurt Raschke wrote: >>On Jan 16, 2005, at 4:25 AM, Paul Bijnens wrote: >>> For the record: >>> plain gtar 1.12 needs to be patched to handle large files (> >>> 2GB). plain gtar 1.13 makes bad index-lists which amrecover >>> cannot handle, as does the rarely used 1.13.9x, which changed the >>> index-format again in an incompatible way. >>> >>> In production environment I use only 1.13.19 or 1.13.25 >>> currently. >> >>There is also a tar 1.15 release out now; can anyone comment on its >>compatibility with AMANDA? I'm asking mainly because 1.13.25 is >>getting rather old. >> >>-Kurt > >I'll find out tonight, I just got 1.15-1 and installed it, then > added a line to my config driver script telling it where the new > tar was, and its re-installing 2.4.5b1-20041221 now. amcheck seems > to be happy, so tonights run should tell the story. > >As they say on the radio, stay tuned for further developements. > >Here, gtar was installed in /bin/gtar, and the new tar is >in /usr/local/bin/tar' so the script I use got a new line: > >#!/bin/sh ># since I'm always forgetting to su amanda... >if [ `whoami` != 'amanda' ]; then > echo > echo " Warning " > echo "Amanda needs to be configured and built by the user amanda," > echo "but must be installed by user root." > echo > exit 1 >fi >make clean >rm -f config.status config.cache >./configure --with-user=amanda \ > --with-group=disk \ > --with-owner=amanda \ > --with-gnu-ld \ > --prefix=/usr/local \ > --with-tapedev="FILE:/amandatapes" \ > --with-debugging=/tmp/amanda-dbg/ \ > --with-tape-server=coyote.coyote.den \ > --with-amandahosts \ > --with-configdir=/usr/local/etc/amanda \ > --with-gnutar=/usr/local/bin/tar > >make >- > >Hopefully this is enough to make it use the newer tar. It logs in > as: > >[EMAIL PROTECTED] amanda-2.4.5b1-20041221]$ /usr/local/bin/tar > --version tar (GNU tar) 1.15.1 > >And I didn't give it anything special when I ran ./configure to > build it. Should I have? Ok, here is what I got: amdump, no errors amverify of the backups made, no errors amrecover seems not to be able to read aamanda.conf, and its asking for /usr/local/etc/amanda/DailySet1/amanda.conf. But that was renamed to just /usr/local/etc/amanda/Daily/amanda.conf proably 2 years ago. [EMAIL PROTECTED] data]# amrecover AMRECOVER Version 2.4.5b1-20041221. Contacting server on coyote.coyote.den ... 220 coyote AMANDA index server (2.4.5b1-20041221) ready. 200 Access OK Setting restore date to today (2005-01-17) 200 Working date set to 2005-01-17. 501 Could not read config file /usr/local/etc/amanda/DailySet1/amanda.conf! amrecover>quit -- amrestore seems a bit dangerous: [EMAIL PROTECTED] data]# amrestore amrestore: Must specify tape-device or holdingfile amrestore: Usage: amrestore [-b blocksize] [-r|-c] [-p] [-h] [-f fileno] [-l label] tape-device|holdingfile [hostname [diskname [datestamp [hostname [diskname [datestamp ... ]] --- And dd seems not to be able to do it either: [EMAIL PROTECTED] data]# dd if=00013.coyote._root.0 bs=32k count=1 AMANDA: FILE 20050117 coyote /root lev 0 comp .gz program /usr/local/bin/tar To restore, position tape at start of file and run: dd if= bs=32k skip=1 | /usr/bin/gzip -dc | usr/local/bin/tar -f... - [EMAIL PROTECTED] data]# dd if=00013.coyote._root.0 bs=32k skip=1 | /usr/bin/gzip -dc | /usr/local/bin/tar -f... - /usr/local/bin/tar: You must specify one of the `-Acdtrux' options Try `/usr/local/bin/tar --help' or `/usr/local/bin/tar --usage' for more information. 3+0 records in 2+0 records out And did not generate any extra data in the /amandatapes/Dailys/data subdir where I was cd'd to at the time. Adding a x to the tar invocation makes sense though, so: -- [EMAIL PROTECTED] data]# dd if=00013.coyote._root.0 bs=32k skip=1 | /usr/bin/gzip -dc | /usr/local/bin/tar -xf... - /usr/local/bin/tar: ...: Cannot open: No such file or directory /usr/local/bin/tar: Error is not recoverable: exiting now 4+0 records in 3+0 records out -- So I'm puzzled as to whether I'm still doing something wrong, or this new tar doesn't recognize the '-f... -' for the stdin from a pipe option. Humm, the original gtar doesn't like it either. Same error, so its obviously me. Removing the ..., which I don't recall was the correct usage, and the older gtar is now busy filling that virtual tape directory with the contents of the level 0 /root file. That will be a mess to cleanup... And its reporting some bad timestamps???: -- [EMAIL PROTECTED] data]# dd if=00013.coyote._root.0 bs=32k skip=1 | /usr/bin/gzip -dc | /bin/gtar -xf - /bin/gtar: ./.kde/share/apps/RecentDocuments/cdrom.desktop: time stamp 2020-04-27 15:36:21 is 482063157 s in the future /bin/gtar: ./.kde/share/apps/Rece
Re: GNU tar versions (was: Backups failing on Solaris 9 with GNU tar)
On Sunday 16 January 2005 15:47, Kurt Raschke wrote: >On Jan 16, 2005, at 4:25 AM, Paul Bijnens wrote: >> For the record: >> plain gtar 1.12 needs to be patched to handle large files (> 2GB). >> plain gtar 1.13 makes bad index-lists which amrecover cannot >> handle, as does the rarely used 1.13.9x, which changed the >> index-format again in an incompatible way. >> >> In production environment I use only 1.13.19 or 1.13.25 currently. > >There is also a tar 1.15 release out now; can anyone comment on its >compatibility with AMANDA? I'm asking mainly because 1.13.25 is >getting rather old. > >-Kurt I'll find out tonight, I just got 1.15-1 and installed it, then added a line to my config driver script telling it where the new tar was, and its re-installing 2.4.5b1-20041221 now. amcheck seems to be happy, so tonights run should tell the story. As they say on the radio, stay tuned for further developements. Here, gtar was installed in /bin/gtar, and the new tar is in /usr/local/bin/tar' so the script I use got a new line: #!/bin/sh # since I'm always forgetting to su amanda... if [ `whoami` != 'amanda' ]; then echo echo " Warning " echo "Amanda needs to be configured and built by the user amanda," echo "but must be installed by user root." echo exit 1 fi make clean rm -f config.status config.cache ./configure --with-user=amanda \ --with-group=disk \ --with-owner=amanda \ --with-gnu-ld \ --prefix=/usr/local \ --with-tapedev="FILE:/amandatapes" \ --with-debugging=/tmp/amanda-dbg/ \ --with-tape-server=coyote.coyote.den \ --with-amandahosts \ --with-configdir=/usr/local/etc/amanda \ --with-gnutar=/usr/local/bin/tar make - Hopefully this is enough to make it use the newer tar. It logs in as: [EMAIL PROTECTED] amanda-2.4.5b1-20041221]$ /usr/local/bin/tar --version tar (GNU tar) 1.15.1 And I didn't give it anything special when I ran ./configure to build it. Should I have? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.32% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
GNU tar versions (was: Backups failing on Solaris 9 with GNU tar)
On Jan 16, 2005, at 4:25 AM, Paul Bijnens wrote: For the record: plain gtar 1.12 needs to be patched to handle large files (> 2GB). plain gtar 1.13 makes bad index-lists which amrecover cannot handle, as does the rarely used 1.13.9x, which changed the index-format again in an incompatible way. In production environment I use only 1.13.19 or 1.13.25 currently. There is also a tar 1.15 release out now; can anyone comment on its compatibility with AMANDA? I'm asking mainly because 1.13.25 is getting rather old. -Kurt
