[Bug 204426] Processes terminating cannot access memory
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon Feb 1 13:34:33 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204426
--- Comment #24 from rblayzor at inoc.net ---
(In reply to Konstantin Belousov from comment #23)
These VM's boot diskless and mount their root file system as RO.
Trying to mount root from nfs: []...
NFS ROOT: 10.0.0.211:/vol/bsdroot/v0f
Where "v0f" is nothing more than subdir for a new rootfs. "bsdroot" is just a
NetApp volume RO volume from these hosts.
There is a VMDK (virtual disk) that is mounted at boot time; which is a thin
provision disk 10GB in size. 2GB a 2Gbps swap partition and a 8Gb scratch disk
for things like /var or /var/tmp
da0 at mpt0 bus 0 scbus0 target 0 lun 0
da0: <VMware Virtual disk 1.0> Fixed Direct Access SCSI-2 device
bootpc_init: wired to interface 'vmx0'
da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
da0: Command Queueing enabled
da0: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C)
da0: quirks=0x40<RETRY_BUSY>
The port binaries are built on a another FreeBSD 10.2 platform (same VM config)
and then we rsync /usr/local to be part of the rootfs.
We always keep the port builds and the base system fresh and in sync. Typically
when we want roll out a new version of FreeBSD we'll upgrade the build VM
first, then create a new subdir for rootfs and install there. Followed by a
complete port rebuild and resync. This has always worked for us since FreeBSD
8.x just fine...
Only recently we've seen these random, strange, unexplainable core dumps.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-threads
mailing list