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

On Thu, Aug 30, 2012 at 4:34 PM, Konstantin Belousov
<kostikbel_at_gmail.com> wrote:
> 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.

I've updated the host to a recent 9-stable and it works like a charm now.
Thanks for fixing it!

-- 
Bernhard Froehlich
http://www.bluelife.at/