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

On Mon, Aug 27, 2012 at 05:28:09PM +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.
> 
> I've seen that it was committed to head in the meantime so
> I gave that a try. The problem still persists.
> 
> https://redports.org/~decke/20120827152217-19891-54992/expat-2.0.1_2.log

Are you sure that you tested the right kernel ?
You may use the following test program to verify. Compile it on 32bit
system. Run it like this:
./getvfsbyname devfs ufs nfs
On patched kernel, I get
sandy% ./getvfsbyname devfs ufs nfs                                           ~
name devfs typenum 113 ref 2 flags 0x480000
name ufs typenum 53 ref 1 flags 0x0
name nfs typenum 58 ref 4 flags 0x20000

On unpatched machine, the result is
ooma32% ./getvfsbyname devfs ufs nfs               ~/build/bsd/DEV/stuff/tests
getvfsbyname: getvfsbyname("devfs"): No such file or directory
getvfsbyname: getvfsbyname("ufs"): No such file or directory
getvfsbyname: getvfsbyname("nfs"): No such file or directory