Re: [Bug-tar] New install of 1.27, is refusing to backup certain subtrees

[Nathan Stratton Treadway]

On Sun, Mar 02, 2014 at 06:39:09 -0500, Gene Heskett wrote:
> STRANGE DUMP DETAILS:
>   /-- coyote /lib lev 0 STRANGE
[...]
>   ? /usr/local/bin/tar: ./init/rw: directory is on a different filesystem; 
> not dumped

>   /-- coyote /var lev 1 STRANGE
[...]
>   ? /usr/local/bin/tar: ./lock: directory is on a different filesystem; not 
> dumped
>   ? /usr/local/bin/tar: ./run: directory is on a different filesystem; not 
> dumped
>   ? /usr/local/bin/tar: ./lib/nfs/rpc_pipefs: directory is on a different 
> filesystem; not dumped

On Sun, Mar 02, 2014 at 14:36:54 -0500, Gene Heskett wrote:
> tmpfs, smack in the middle of an ext2-ext3 and journaled file system?
> 
> How the heck do they pull that off?  And better yet, is it fixable?

These are all simply virtual filesystems mounted on those respective
mount points.

I don't remember which distribution you are running, but my Ubuntu Lucid
server shows:

  # mount | grep -E "/var|/lib"
  none on /var/run type tmpfs (rw,nosuid,mode=0755)
  none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
  none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
  none on /var/lib/ureadahead/debugfs type debugfs (rw,relatime)

(I'm not running NFS on this server, so that would explain why
/var/lib/nfs/rpc_pipefs doesn't exist.)

So I think your mount points are they way they should be....


What has changed is that tar 1.27 now prints a warning message when it
detects a filesystem boundary (when --one-file-system is in effect),
while earlier versions didn't.  

(So presumably the correct fix is to get Amanda updated to
recognize/handle the new warning message.)

                                                        Nathan

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  address@hidden  -  Mid-Atlantic region
Ray Ontko & Co.  -  Software consulting services  -   http://www.ontko.com/
 GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt   ID: 1023D/ECFB6239
 Key fingerprint = 6AD8 485E 20B9 5C71 231C  0C32 15F3 ADCD ECFB 6239