Maybe this isn't quite the usual sequence, but I'm trying to get the
root filesystem for a current build up.

Now I don't what to build as root (if it can be helped) to ensure the
build system isn't trashed any more that absolutely necessary :-)

So as 'me' I've run build.sh using the script:

#!/bin/sh
exec 2>&1
DESTDIR=/usr/bsd-current/dest
RELEASEDIR=/usr/bsd-current/release
UNPRIVED=
export DESTDIR RELEASEDIR UNPRIVED
build.sh -u -D /usr/bsd-current/dest -O /usr/bsd-current/obj "$@"

I then created a filesytem (to be the new root) and mounted it on /mnt
then:
# cd $DESTDIR; cp -R . /mnt
# chroot /mnt
# cd /dev; MAKEDEV all
# mtree -U -def /etc/mtree/NetBSD.dist

The next job is fixing the file permnissions, the required values are in
$OBJ/METALOG so you might think that:
# mtree -U -f /tmp/METALOG
would do the trick (where you have copied METALOG into the chroot) 
however this fails because all the entries in METALOG are preceeded by
./usr/bsd-current/dest which is no longer true.

Interestingly mtree fails:
mtree: .: No such file or directory
mtree: failed at line 1 of the specification
even ktrace doesn't show a failing syscall....

Removing the directory prefix doesn't actually make a difference!

ktrace gives:

  2994 mtree    RET   close 0
  2994 mtree    CALL  open(0xbfbfd997,0,0x1b6)
  2994 mtree    NAMI  "/tmp/zz"
  2994 mtree    RET   open 3
  2994 mtree    CALL  close(0)
  2994 mtree    RET   close 0
  2994 mtree    CALL  dup2(0x3,0)
  2994 mtree    RET   dup2 0
  2994 mtree    CALL  close(0x3)
  2994 mtree    RET   close 0
  2994 mtree    CALL  __fstat13(0,0xbfbfd630)
  2994 mtree    RET   __fstat13 0
  2994 mtree    CALL  __sysctl(0xbfbfd5a8,0x2,0xbfbfd5a0,0xbfbfd5a4,0,0)
  2994 mtree    RET   __sysctl 0
  2994 mtree    CALL  readlink(0x480f89c0,0xbfbfd610,0x3f)
  2994 mtree    NAMI  "/etc/malloc.conf"
  2994 mtree    RET   readlink -1 errno 2 No such file or directory
  2994 mtree    CALL  mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0)
  2994 mtree    RET   mmap 1209053184/0x4810b000
  2994 mtree    CALL  break(0x8053558)
  2994 mtree    RET   break 0
  2994 mtree    CALL  break(0x8054558)
  2994 mtree    RET   break 0
  2994 mtree    CALL  break(0x8055000)
  2994 mtree    RET   break 0
  2994 mtree    CALL  break(0x8057000)
  2994 mtree    RET   break 0
  2994 mtree    CALL  read(0,0x8055000,0x2000)
  2994 mtree    GIO   fd 0 read 312 bytes
       "./sys type=link mode=0755 link=usr/src/sys uname=root
gname=wheel
        ./usr/include/a.out.h type=file mode=0444 uname=root gname=wheel
time=\
        886453637.0
        ./usr/include/ar.h type=file mode=0444 uname=root gname=wheel
time=783\
        132943.0
        ./usr/include/arpa/ftp.h type=file mode=0444 uname=root
gname=wheel ti\
        me=887070770.0
       "
  2994 mtree    RET   read 312/0x138
  2994 mtree    CALL  break(0x8058000)
  2994 mtree    RET   break 0
  2994 mtree    CALL  break(0x8059000)
  2994 mtree    RET   break 0
  2994 mtree    CALL  issetugid
  2994 mtree    RET   issetugid 0
  2994 mtree    CALL  open(0xbfbfd328,0,0x4805e600)
  2994 mtree    NAMI  "/usr/share/nls/C/libc.cat"
  2994 mtree    RET   open 3
  2994 mtree    CALL  __fstat13(0x3,0xbfbfd28c)
  2994 mtree    RET   __fstat13 0
  2994 mtree    CALL  mmap(0,0xf57,0x1,0x1,0x3,0,0,0)
  2994 mtree    RET   mmap 1209057280/0x4810c000
  2994 mtree    CALL  close(0x3)
  2994 mtree    RET   close 0
  2994 mtree    CALL  munmap(0x4810c000,0xf57)
  2994 mtree    RET   munmap 0
  2994 mtree    CALL  write(0x2,0xbfbfcec4,0x7)
  2994 mtree    GIO   fd 2 wrote 7 bytes
       "mtree: "
  2994 mtree    RET   write 7
  2994 mtree    CALL  write(0x2,0xbfbfcef4,0x1c)
  2994 mtree    GIO   fd 2 wrote 28 bytes
       ".: No such file or directory"

There doesn't seem to be anything wrong in there at all.

Any thought as to why mtree won't run in a chroot environment?
(The chroot lets me run the 'current' binaries and libraries - the 1.5.2
kernel should cope with these sort of calls.)

Part of the plan is to use the updates to METLOG after a rebuild to work
out which files need to be copied over.  Indeed, if xinstall wrote a
src=xxx line to METALOG the file could be pulled straight from $OBJ
instead of $DEST.  Would need to copy the header files (etc) into $OBJ
(instead of $DEST) during 'make build' though...

	David