Bug 206979 - GNU tar update to 1.15.91 breaks existing amanda installations
GNU tar update to 1.15.91 breaks existing amanda installations
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: tar (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Peter Vrabec
Ben Levenson
: Reopened
Depends On:
Blocks: 207115 207689 208490 208491
  Show dependency treegraph
Reported: 2006-09-18 12:11 EDT by Jonathan Larmour
Modified: 2013-01-09 23:04 EST (History)
8 users (show)

See Also:
Fixed In Version: 5.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-26 16:08:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan Larmour 2006-09-18 12:11:17 EDT
Description of problem:

The GNU tar update to 1.15.91 a few days ago has broken my amanda backup system
due to a switch to a different state file format. Specifically, from analysis of
/var/log/amanda/ the problem is when sending sizes of level 1s (or above):
sendsize[9076]: time 0.799: /bin/tar: Unexpected field value in snapshot file
sendsize[9076]: time 0.799: /bin/tar: Error is not recoverable: exiting now
sendsize[9076]: time 0.800: .....
sendsize[9076]: estimate time for /home level 1: 0.004
sendsize[9076]: no size line match in /bin/tar output for "/home"

From some searching, this is a known issue and caused the amanda people to issue
2.5.1 incorporating some sort of change to work around it:

However the real problem is in tar - it should not casually introduce a new file
format breaking existing incremental dump state files.

Either way, amanda backups using tar are non-functional on FC5 after this update.

Version-Release number of selected component (if applicable):


How reproducible:

Requires incremental backup state files generated with an older tar.
Comment 4 Peter Vrabec 2006-09-19 05:26:04 EDT
I have pushed new tar-1.15.91 update, because incremental backup in tar-1.15.90 didn't work 
properly (#206121).

tar-1.15.91 was also pushed into RHEL-5 and FC-6, so we really need to solve this problem 
fast.  Backporting the newer gnutar support from 2.5.1 to 2.5.0p2 seems to be best way. If it's 
not possible, we can either downgrade tar to version 1.15.1, which includes backporting some 
patches or start talking about amanda upgarade.
Comment 18 James Antill 2006-09-21 16:27:21 EDT
 Ok, so I'm almost finished with the port. However from the documentation it
seems like incremental backups doesn't work with POSIX format archives (in this
 The state file format is the only problem for amanda? If so I'll look at
patching that change into 1.15.91.
Comment 19 Jay Fenlason 2006-09-21 16:34:47 EDT
Well, there's the fact that the --one-file-system option doesn't work, which 
means that when I try to back up / it dumps /proc, /selinux, /home, etc.  It 
really should be opened as a separate bug, though. 
Comment 20 Peter Vrabec 2006-09-22 06:16:30 EDT
tar-1.15.91 with fixed one file system option is available here:
Comment 22 RHEL Product and Program Management 2006-09-22 16:42:15 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux release.  Product Management has requested further review
of this request by Red Hat Engineering.  This request is not yet committed for
inclusion in release.
Comment 28 Jay Turner 2006-09-26 14:29:47 EDT
QE ack to resolving the situation in some manner.  Either we sort out what's
broken with tar or we revert tar.  We simply can't be in the position that
amanda doesn't work.
Comment 36 Jay Fenlason 2006-09-28 16:56:34 EDT
Using tar-1.15.91-3 with both the --listed-incremental option and the 
--wildcards option appears to be busted in that the output file contains no 
directory information.  I think that this is a good datapoint that 1.15.91 is 
not usable. 
Comment 42 Peter Vrabec 2006-10-04 06:44:22 EDT
fixed by tar-1.15.1-18
Comment 43 Jay Turner 2006-10-04 08:08:16 EDT
Putting into the correct state (modified)  Will move to Verified once the fix is
verified and then to Closed once the fixed package appears in a RHEL5 tree.

Note You need to log in before you can comment on or make changes to this bug.