FreeBSD 10.2-RELEASE Errata

The FreeBSD Project

Intel, Celeron, Centrino, Core, EtherExpress, i386,
i486, Itanium, Pentium, and Xeon are trademarks or registered
trademarks of Intel Corporation or its subsidiaries in the United
States and other countries.

SPARC, SPARC64, and
UltraSPARC are trademarks of SPARC International, Inc in the United
States and other countries. SPARC International, Inc owns all of the
SPARC trademarks and under licensing agreements allows the proper use
of these trademarks by its members.

Many of the designations used by
manufacturers and sellers to distinguish their products are claimed
as trademarks. Where those designations appear in this document,
and the FreeBSD Project was aware of the trademark claim, the
designations have been followed by the “™” or the
“Â®” symbol.

Last modified on 2016-01-14 by gjb.

Abstract

This document lists errata items for FreeBSD 10.2-RELEASE,
containing significant information discovered after the
release or too late in the release cycle to be otherwise
included in the release documentation. This information
includes security advisories, as well as news relating to the
software or documentation that could affect its operation or
usability. An up-to-date version of this document should
always be consulted before installing this version of
FreeBSD.

This errata document for FreeBSD 10.2-RELEASE will be
maintained until the release of FreeBSD 10.3-RELEASE.

1.Â Introduction

This errata document contains “late-breaking
news” about FreeBSD 10.2-RELEASE Before installing this
version, it is important to consult this document to learn about
any post-release discoveries or problems that may already have
been found and fixed.

Any version of this errata document actually distributed
with the release (for example, on a CDROM distribution) will be
out of date by definition, but other copies are kept updated on
the Internet and should be consulted as the “current
errata” for this release. These other copies of the
errata are located at https://www.FreeBSD.org/releases/, plus any
sites which keep up-to-date mirrors of this location.

Source and binary snapshots of FreeBSD 10.2-STABLE also
contain up-to-date copies of this document (as of the time of
the snapshot).

4.Â Open Issues

FreeBSD/i386 10.2-RELEASE running as a guest
operating system on VirtualBox
can have a problem with disk I/O access. It depends on some
specific hardware configuration and does not depend on a
specific version of VirtualBox or
host operating system.

It has been reported that instability may be present on
virtual machines running on other hypervisors, such as Xen
or KVM.

It causes various errors and makes FreeBSD quite unstable.
Although the cause is still unclear, disabling unmapped I/O
works as a workaround. To disable it, choose
Escape to loader prompt in the boot menu
and enter the following lines from loader(8) prompt,
after an OK:

set vfs.unmapped_buf_allowed=0
boot

Note that the following line has to be added to
/boot/loader.conf after a boot. It
disables unmapped I/O at every boot:

vfs.unmapped_buf_allowed=0

FreeBSD/i386Â 10.2-RELEASE installed on ZFS
may crash during boot when the ZFS pool mount is attempted
while booting an unmodified GENERIC
kernel.

As described in /usr/src/UPDATING
entry 20121223, rebuilding the kernel
with options KSTACK_PAGES=4 has been
observed to resolve the boot-time crash. This, however, is
not an ideal solution for inclusion in the
GENERIC kernel configuration, as
increasing KSTACK_PAGES implicitly
decreases available usermode threads in an environment that
is already resource-starved.

Taking into account the heavy resource requirements of
ZFS, in addition to the i386-specific tuning
requirements for general workloads, using ZFS with the
FreeBSD/i386Â GENERIC kernel
is strongly discouraged.

If installing FreeBSD/i386 on ZFS, it is possible to
configure the system after installation to increase the
KSTACK_PAGES.

When prompted by bsdinstall(8) to perform
additional post-installation configuration to the system,
select [Â YESÂ ].

This procedure requires the system sources available
locally. If the System source code
distribution was not selected during installation, it can
be obtained using svnlite:

Warning:

It is extremely important to take note that, by
default, freebsd-update(8) will install the
GENERIC kernel configuration, and
as such, freebsd-update(8) consumers are strongly
encouraged to avoid FreeBSD-provided kernel binary upgrades
with such configurations.

Note:

Keep in mind that REPOS_DIR will need
to be set again after the current shell session is
terminated, if continuing to use the packages provided on
the dvd1.iso installer.

Finally, bootstrap pkg(8) from the
ISO, and install required
packages:

# pkg bootstrap
# pkg install xorg-serverxorggnome3 [...]

An issue was discovered where the netstat(1)-s option will cause a segmentation fault
on systems with IPSEC compiled into the
kernel. The issue was resolved in the
stable/10 branch, and an Errata Notice is
planned after 10.2-RELEASE is released.

[2015-08-19] Resolved as FreeBSD-EN-15:12.

An issue was discovered that causes make(1) to
generate noisy output when doing source-based upgrades from
FreeBSD 9.3 and earlier. The issue was reported in PR 202277,
and after investigation and determining the issue does not
cause source-based upgrades to fail, a post-release Errata
Notice is planned.

[2015-08-19] Resolved as FreeBSD-EN-15:11.

An issue with FreeBSD virtual machines with
vagrant was discovered that
affects the VirtualBox where the
virtual machine will not start on the initial boot invoked
with vagrant up.

The issue is due to the virtual machine
MAC being unset, as FreeBSD does not provide
a default Vagrantfile.

It has been observed, however, that a subsequent
invocation of vagrant up will allow the
virtual machine to successfully boot, allowing access via
vagrant ssh.

[2015-08-16] An error was discovered in the release
notes for FreeBSD 10.2-RELEASE regarding the
drm device driver. The entry for r282199
states the driver was updated to match the version LinuxÂ®
3.8.13 version, however the entry should have noted the
change affects device-independent code, and does not bring
the drm driver fully in line with the
stated LinuxÂ® version.