Re: make package fails in chroot: tar: getvfsbyname failed: No such file or directory

On Thu, Aug 30, 2012 at 04:07:48PM +0200, Bernhard Fr?hlich wrote:
> On Mon, Aug 20, 2012 at 2:31 PM, Konstantin Belousov
> <kostikbel_at_gmail.com> wrote:
> > On Mon, Aug 20, 2012 at 01:42:31PM +0200, Bernhard Fr?hlich wrote:
> >> On Sun, Aug 19, 2012 at 10:01 PM, Tim Kientzle <tim_at_kientzle.com> wrote:
> >> >
> >> > On Aug 19, 2012, at 12:17 PM, Garrett Cooper wrote:
> >> >
> >> >> On Sun, Aug 19, 2012 at 9:45 AM, Tim Kientzle <tim_at_kientzle.com> wrote:
> >> >>>
> >> >>> On Aug 12, 2012, at 6:20 AM, Paul Schenkeveld wrote:
> >> >>>
> >> >>>> Hi,
> >> >>>>
> >> >>>> I have a wrapper script that builds packages in a chroot environment
> >> >>>> which happily runs on release 6 thru 9 and earlier 10 but fails with:
> >> >>>>
> >> >>>> tar: getvfsbyname failed: No such file or directory
> >> >>>>
> >> >>>> on a recent -CURRENT.
> >> >>>
> >> >>> libarchive does do an initial getvfsbyname() when you ask it
> >> >>> to traverse a directory tree so that it can accurately handle later
> >> >>> requests about mountpoints and filesystem types.  This code
> >> >>> is admittedly a little intricate.
> >> >>
> >> >>    The problem most likely is the fact that all mountpoints are
> >> >> exposed via chroot, thus, if it's checking to see if a mountpoint
> >> >> exists, it may exist outside of the chroot.
> >> >>
> >> >
> >> > I reviewed the code to refresh my memory.   Some
> >> > of what I said before was not quite right.
> >> >
> >> > Libarchive's directory traversal tracks information about
> >> > the filesystem type so that clients such as bsdtar can
> >> > efficiently skip synthetic filesystems (/dev or /proc) or
> >> > network filesystems (NFS or SMB mounts).
> >> >
> >> > The net effect is something like this:
> >> >
> >> >    For each file:
> >> >        stat() or lstat() or fstat() the file
> >> >        look up dev number in an internal cache
> >> >        if the dev number is new:
> >> >             fstatfs() the open fd to get the FS name
> >> >             getvfsbyname() to identify the FS type
> >> >
> >> > Unless there's a logic error in libarchive itself, this
> >> > would suggest that somehow fstatfs() is returning
> >> > a filesystem type that getvfsbyname() can't
> >> > identify.
> >> >
> >> > Paul:
> >> >     What filesystem are you using?
> >> >
> >> >     What does "mount" show?
> >> >
> >> >     Does it work outside the chroot?
> >>
> >> I also see the same on the redports.org build machines.
> >> It builds within a jail there which is completely on a tmpfs.
> >> Interestinly everything is fine with a 10-CURRENT/amd64
> >> jail but it breaks in a 10-CURRENT/i386 jail. Both are
> >> running on the same 10-CURRENT/amd64 which is
> >> around 2 months old.
> >>
> >> https://redports.org/buildarchive/20120814130205-56327/
> >
> > Try this.
> 
> Is it possible that this requires the host system to be quite
> new? The commit in HEAD seems to doesn't help in my
> case. Host is 9-stable from Jun 27 and jail is 10-current from
> a few days ago.
Doh, the fix was in kernel, and I merged the change back to stable only
on August 27.

Running HEAD world on stable is not supported anyway.