I'm seeing this as well, almost. I don't use the "install=" target, but my latest successful build of netbsd-7 produced a "base.tgz" set that contained:
$ tar tzvf base.tgz drwxr-xr-x 2 root wheel 0 Oct 24 10:29 . -rw-r--r-- 1 root wheel 319 Apr 17 2014 ./boot.cfg drwxr-xr-x 2 root wheel 0 Oct 3 19:17 ./altroot drwxr-xr-x 2 root wheel 0 Oct 14 07:46 ./bin drwxr-xr-x 2 root wheel 0 Oct 24 10:26 ./dev -r-xr-xr-x 1 root wheel 42679 Oct 3 21:54 ./dev/MAKEDEV drwxr-xr-x 2 root wheel 0 Oct 3 19:17 ./dev/altq drwxr-xr-x 2 root wheel 0 Oct 3 19:17 ./dev/fd drwxr-xr-x 2 root wheel 0 Oct 24 10:26 ./etc -rw------- 1 root wheel 1395 Apr 17 2014 ./etc/master.passwd -rw-r--r-- 1 root wheel 1281 Oct 24 10:26 ./etc/passwd -rw-r--r-- 1 root wheel 40960 Oct 24 10:26 ./etc/pwd.db -r--r--r-- 1 root wheel 3924 Oct 24 10:26 ./etc/release -rw------- 1 root wheel 40960 Oct 24 10:26 ./etc/spwd.db -rw-r--r-- 1 root wheel 875 Apr 17 2014 ./etc/ttys [...] as well as most files that SHOULD be there being zero length. This started (as near as I can tell) after this commit: http://mail-index.netbsd.org/source-changes/2014/10/24/msg059743.html (and on -current with its prior counterpart). The principal symptom was 'pax' trying to archive old versions of shared libraries that had been removed from DESTDIR upon complaint by "checkflist"--libm and various libxcb* (amd64 example): [...] --- do-base --- pax: Unable to open ./lib/libm.so.0.10 to read (No such file or directory) pax: Unable to open ./usr/lib/i386/libm.so.0.10 to read (No such file or directory) --- do-comp --- pax: Unable to open ./lib/libm.so.0.10 to read (No such file or directory) pax: Unable to open ./usr/lib/i386/libm.so.0.10 to read (No such file or directory) [...] (The libxcb*.so errors didn't appear in this attempt, but did before.) I found the entries for the old libs in ${DESTDIR}/METALOG.sanitized. I figured I could delete the METALOG* files and they'd be regenerated. They were, but seem to have been generated incorrectly. They lack any reference to "libm.so*" (and presumedly the relevant "libxcb*.so*" files (I forget which ones they were). As a result, all the sets seem to be archives of the entire DESTDIR with most files being zero-length, differing primarily by containing a non- zero-length instance of their own "./etc/mtree/set.foo" file. They all contain the files that should only be in the "etc.tgz" set. I should note that I typically do update builds. Perhaps that was not sufficient. I am running a non-update build now. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
