On 05/12/14 19:25, Philip Guenther wrote: > On Mon, 12 May 2014, RD Thrush wrote: >> I use this box mostly w/amd64 -current. I boot in i386 appx. weekly to >> do a partial dpb bulk build. I don't use tmpfs (or mfs) in i386 mode. >> I do the dpb builds (both i386 and amd64) w/ chroot. This is the first >> time I've encountered this problem. Let me know if I can help further. > > "dpb builds w/ chroot"? I seem to recall that espie (or sthen?) had found > that that led to panics. Or was that was a different meaning of "dpb > builds w/ chroot"?
I've not noticed any panics within the past several months. Although I have scripting around the dpb invocation, I essentially run dpb on an amd64 host as follows: dpb -s -A i386 -c -R -u -J 0 -X pkg_info-qPa.all -h dpb_hosts.i386 -f 8 -D SYSLOG -P i386-combined.pkg_info-qPa where "dpb_hosts.i386" contains: DEFAULT timeout=10 stuck=1000 memory=200M arch=i386 STARTUP=/home/rd/OpenBSD/build/packages/dpb_start rd@i7v32 sf=2 memory=400M jobs=1 arch=i386 rd@a8v2 jobs=8 chroot=/dpb memory=400M sf=14 arch=i386 a8v2 is the machine that prompted the sendbug report. The dpb_start STARTUP script mounts "/usr" and "/usr/local" rw while my dpb wrapper mounts those filesystems ro upon completion. NB: I intermittently see what I consider nfs non-reproducible nfs timeout issues (on both arches) and the dpb scripting is my effort to capture enough data make a sensible dpb report,
