Somehow this doesn't work iwth make packages due to some kind of a race.
The package is first created correctly but later in the process it is
overwritten by a badly created empty package.
Revert in the mean time so we can have working pkgbase on arm/arm64
This reverts commit a5afd7920d.
Before that dtbs where included in each kernel packages which prevents
us to install multiple kernels.
Differential Revision: https://reviews.freebsd.org/D43632
Reviewed by: bapt
Sponsored by: Beckhoff Automation GmbH & Co. KG
The `make release` command now creates VM and cloudware images (if
enabled) in addition to disk images; this results in a very large
number of 'make installworld' commands running sequentially. Adding
-jN should speed this up significantly.
MFC after: 1 month
X-MFC-to: stable/14
The amd64 and arm64 images supported UEFI, mark it as so users can take
advantage of UEFI boot on GCE. This is already done on FreeBSD
14.0-RELEASE but never codified into the release tools (and should).
PR: conf/276532
Reviewed by: lwhsu
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D43557
Components like base.txz and ports.txz are called distributions in the
installer, and with the introduction of pkgbase we will start dealing
with normal pkg packages in the installer. Rename EXTRA_PACKAGES to
DISTRIBUTIONS, and move base.txz and kernel.txz to that list.
This introduces no functional change but is a small cleanup in advance
of some pkgbase experimentation.
Reviewed by: cperciva
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D43544
The stable/13 snapshot this week failed to build the riscv GENERICSD
image because it ran out of space. Checking main and stable/14
snapshots, they are also low on space, around 100% or more of
capacity. Increase them all from 5 GB to 6 GB. Note, this is the
only riscv image configuration.
Discussed with: cperciva
This marks FreeBSD GCE images as gVNIC capable by adding the
--guest-os-features=GVNIC flag at creation time as suggested in GCE
documentation[1]. This allows Generation 3 and newer GCE instances
to leverage advanced networking capabilities and performance
enhancements provided by gVNIC. Users will benefit from these
improvements without needing to create custom images.
[1] https://cloud.google.com/compute/docs/networking/using-gvnic#create_a_vm_with_gvnic_support
Reviewed by: cperciva
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D43411
Most 64-bit Raspberry Pi models have a variable processor clock
speed that defaults to a slow speed (e.g. 600 MHz for a nominal
1.5 GHz clock). This results in everything running slowly unless
or until powerd is started, and FreeBSD is then thought to be slow.
Enable powerd by default in /etc/rc.conf on the arm64-aarch64-RPI
images. Tested on Raspberry Pi 3B+ and 4B so far.
PR: 256836
MFC after: 1 month
Reviewed by: rgrimes
Differential Revision: https://reviews.freebsd.org/D43296
Allow the cloudware *_FLAVOURS and *_FSLIST values to be overridden
at the command line, to assist users who want to e.g. build only one
of the many EC2 AMIs available.
FreeBSD-src for all the sources but the kernel
FreeBSD-src-sys just for the kernel
MFC After: 3 days
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D42651
The emulator-portinstall target now unconditionally ensures that qemu
is installed; but is only invoked if needed (aka. when cross building
VM images).
MFC After: 3 days
MFC With: 97bd53ef4d ("Fix duplicate rc.conf files")
Two bugs in Makefile.vm resulted in disk images being "built" multiple
times, resulting in lines added to /etc/rc.conf being duplicated:
1. The vm-image target reused the same "staging tree" directory for all
of its builds (multiple disk image types and multiple filesystem types).
2. The cw-type-flavour-fs target depends on emulator-portinstall, which
did not have a 'touch ${.TARGET}' and thus re-ran every time -- and
caused the cw-type-flavour-fs target to be re-run. This was triggered
by release builds running `make cloudware-release` (creating the disk
images) followed by `make ec2amis` (which re-created the disk images
prior to uploading them).
MFC After: 1 week
Sponsored by: https://www.patreon.com/cperciva
Unbloat a bit FreeBSD-utilities.
The only package that will depends on this new one is FreeBSD-ssh
which not anyone have in some setup.
And this will allow to have small pkgbase setup with ssh without
having to bring the bloated FreeBSD-utilities package
Name the package blocklist to reflect upstream futur changes.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D42148
Known issues:
1. The ec2-user user is created with a homedir of /usr/home/ec2-user
instead of /home/ec2-user; this appears to be a bug in cloud-init's
FreeBSD support.
2. Cloud-init configures IPv4 networking but not IPv6 networking.
releng/14.0 candidate.
Discussed with: gjb
Reviewed by: imp
MFC after: 5 days
Relnotes: yes
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41793
Split ec2-base.conf into ec2-base.conf and a reusable ec2.conf,
similar to how Vagrant flavours share a common vagrant.conf.
releng/14.0 candidate.
Discussed with: gjb
MFC after: 5 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41792
Using the recently-added "cloudware flavours" mechanism, turn the
existing EC2 AMIs into a new "base" flavour. The only user-visible
change is that AMI names now include the word "base".
releng/14.0 candidate.
Discussed with: gjb
Reviewed by: imp
MFC after: 5 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41791
There are two "Vagrant" images right now: "Vagrant Image for VirtualBox"
and "Vagrant Image for VMWare". Rather than listing these separately in
a CLOUDWARE list, place "VAGRANT" into a CLOUDWARE_TYPES list and then
use a VAGRANT_FLAVOURS variable to identify the two versions. Add make
logic to allow defaults (in this case, image format and filesystem) to
be specified once for VAGRANT and inherited by both flavours.
This will make future work to add flavoured EC2 images simpler.
releng/14.0 candidate.
Discussed with: gjb
Reviewed by: imp
MFC after: 5 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41790
The cw*-package targets were introduced in February 2015 as part of
adding support for building GCE images; but GCE support was reworked
in June 2015 and the cw*-package targets were in fact never used.
Remove them.
The *_DISK variables were introduced in February 2015 as part of
adding the cloudware-install target; this was removed in May 2016 as
the cloudware images are published via the respective cloud systems
and not published as disk images via the FreeBSD FTP site. As such,
the *_DISK variables are not unused; remove them.
releng/14.0 candidate.
Discussed with: gjb
Reviewed by: imp
MFC after: 5 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41789
We no longer install a default portsnap.conf, so the sed invocation just
generates an error.
Reviewed by: cperciva
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D42003
mergemaster was deprecated some time ago and will be removed from
FreeBSD 15.
Reviewed by: imp
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41797
Headers from src/include were in the runtime-dev package but
subdirectories of src/include ended up in utilities-dev by default.
Neither package is a good choice - the headers in src/include are not
useful without the libraries contained in clibs-dev.
This moves the standard C headers to clibs-dev (C++ headers are already
in this package). While working on this, I found that various clang
libraries and headers were also bundled into utilities-dev by default
so these are also moved to clang-dev.
I also added a FreeBSD-build-essential meta package to make it simple to
install all the toolchain parts.
PR: 254173
Reviewed byb: manu
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D41815
Other cloud images do not do this, and it can produce confusing results.
Reviewed by: Jose Luis Duran, delphij
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41751
To overcome package name changing on default Python version updates.
Approved by: gjb (re)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D41453
The pre-existing "ec2ami" target builds and uploads a single AMI
(with filesystem determined by ${VMFS}) as before; a new "ec2amis"
target does both UFS and ZFS.
Reviewed by: gjb
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41343
Prior to this commit, ${VMFS} controlled the filesystem used for
building EC2 images, but the AMIs were recorded with SSM Parameter
paths which indicated that they were UFS.
This commit (a) uses ${VMFS} in the SSM parameter path instead of
a hard-coded "ufs", and (b) adds the filesystem to the AMI name.
Reviewed by: gjb
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41342
New ${CW}_FSLIST settings control the list of filesystem types with which
each cloudware image will be built; currently these are all set to "ufs",
i.e. no change from previous.
The cloudware images have their filesystem type as part of their file
name; for backwards compatibilty the ${VMFS} image is linked to the
previously used file name. This compatibility can be removed once all
the cloudware uploading/publishing code has been updated to use the new
image names (possibly more than one of them).
Reviewed by: gjb
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41341
A new option 'VMFSLIST' controls the list of filesystems for which VM
images will be built; the default is to build both UFS and ZFS.
The vm-install target installs these as ${OSRELEASE}-${FS}.${FORMAT},
e.g. FreeBSD-14.0-CURRENT-amd64-zfs.vmdk. For backwards compatibility,
the ${VMFS} image is linked to the previously used ${OSRELEASE}.${FORMAT}
name.
Cloudware building will be updated in a later commit.
Reviewed by: gjb
Reviewed by: emaste, markj (previous version)
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41340
Add a FCROOTFSSZ variable which defaults to "1g" which controls the
size of the Firecracker root filesystem; it can be set as low as "300m"
at present.
Allow WITHOUTS to be overridden if users want to build a root disk with
more -- or fewer -- parts of the FreeBSD base system.
Reviewed by: gjb
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D41041
This splits out the certctl utility into a new certctl package and the
openssl libs into an openssl-lib package.
PR: 272816
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D41321
This spits out errors but seemingly isn't actually fatal, so was missed.
Fixes: 6853d893c7 ("release: Automatically generate MK_LIB${LIBCOMPAT} and lib${libcompat}-dbg lists")
The lang/python3 port had failed to properly install because
it did in fact already exist and FORCE_PKG_REGISTER was not
set. So, behaviorally everything here was correct. However,
installing lang/python3 is in fact not correct and not needed,
so only install the lang/python port to provide symbolic links.
PR: 272354
MFC after: 3 days
MFC with: 510fd83138
MFC with: cd8cad0ef5
MFC with: 0ed426276f
Sponsored by: GoFundMe https://www.gofundme.com/f/gjbbsd
This just stages the kernel and builds a stripped-down rootfs for use
with the Firecracker VMM. At some point in the future the release
engineering team might start publishing these, but initially it's
just here to simplify FreeBSD/Firecracker development and testing.
Note that the rootfs generated:
* Uses an IP address of 10.0.0.2 with a gateway of 10.0.0.1,
* Has sshd enabled,
* Has user "freebsd" with password "freebsd" and a root password
of "root", and
* Is 1 GB in size (but has growfs enabled).
All of those are subject to change without notice; anyone intending to
use FreeBSD/Firecracker in anything remotely resembling a production
environment should talk to cperciva first.
Reviewed by: gjb
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D40956
In EC2, UEFI boots faster than BIOS, but not all amd64 instance types
support UEFI. AMIs need to have their boot mode designated, which
created a dilemma: Faster boots, or wider compatibility?
The recently added "uefi-preferred" option solves this: AMIs can be
marked to use UEFI where it's available, but fall back to BIOS on
instance types which do not support UEFI.
This uses bsdec2-image-upload 1.4.6, which recently landed in the
ports tree.
PR: 265697
Reviewed by: delphij, imp
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D40470
vm.subr's default vm_extra_pre_umount removes /qemu and
/etc/resolv.conf. When vm_extra_pre_umount is overridden these steps
need to be performed in the cloud-specific conf file.
PR: 271602
Reviewed by: dch, lwhsu
Event: Kitchener-Waterloo Hackathon 202305
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40257
Change the vmimage script for zfs to create /home as a dataset
rather than /usr/home, ala change to bsdinstall's zfs script.
Reviewed by: markj
Differential Revision: <https://reviews.freebsd.org/D40111
For someone new to the release bits it's not always clear what files are
being created. Report the disk image name explicitly.
Reviewed by: gjb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39953
This script's goal is to check the system for peripherals that needs
firmware and install the needed packages for them.
For now it only support pci subsystem and only video classes for AMD
and Intel GPUs.
Reviewed by: bapt
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39825
BBB code was removed from GENERIC kernel as it's not functional.
Stop installing u-boot for a platform that we don't boot on.
Reviewed by: imp, gjb
Approved by: re@ (gjb)
MFC after: never
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D39844
When building ARM release images, enable IPv6 SLAAC by default in
addition to IPv4 DHCP.
Unlike amd64 (and other desktop/server) releases, ARM releases on SoC
setups are usually deployed by just using the installation image, so
there is no interactive network configuration. Not having IPv6
included by default is kind of an anachronism these days, given that
FreeBSD with the KAME project once pioneered IPv6 technology.
MFC after: 2 weeks
And put in it:
- kbdcontrol
- vidcontrol
- moused
- kbdmap
Those aren't useful in a jail or for a modern desktop.
While here, split the devd.conf part into some new files.
Reviewed by: bapt
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38321
This unbloat FreeBSD-utilities a bit and not everyone uses
valectl which is the only in-tree consumer of libnetmap
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38225
It contain all the binaries and libs from the elftoolchain contrib
project except for libelf which is used everywhere.
All of those tools are never used by the average user.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38224
It contains the ctf tools that most users will never use.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38223
And put inetd and its config file in it.
This unbloat a bit FreeBSD-utilities and some people might not
want inetd always installed.
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D38229
Have liby and libcompat share *-dev and *-lib32_dev rules, and share
*-man rule for libcompat and libelftc. Also correct name substitution
and description for man rules.
Reviewed by: manu
Fixes: 5391bcf0f7 ("pkgbase: Do not record dependency on...")
Fixes: 65fa2fd23b ("pkgbase: Do record dependency on non-...")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37964
libelftc is an internal lib so it's never installed.
When building with WITH_MANSPLITPKG=yes the libelftc-man package
will have a dependecy on a non-existent libelftc package.
Sponsored by: Beckhoff Automation GmbH & Co. KG
libcompat only provides a .a which is put in the -dev package.
Add a special record for it so we do not require a dependency on the
non-existent package FreeBSD-libcompat.
Sponsored by: Beckhoff Automation GmbH & Co. KG
shlib_required/provided is enough for the dependencies and this also
causes problems for packages like rescue which shouldn't depend on runtime
at all.
PR: 268063
Sponsored by: Beckhoff Automation GmbH & Co. KG
Provides an OCI (Oracle Cloud Infrastructure) release target for
Oracle's KVM-based VM implementation. Tested using 13.1-RELEASE,
primarily on Ampere CPU on A1.Flex VM shapes, but also works on
amd64 shapes.
- supports cloud-init and custom scripts
- provides a freebsd@ sudo-enabled user
- root user disabled over ssh & console
Approved by: gjb
Reviewed by: emaste
MFS after: 1 week
Sponsored by: The FreeBSD Foundation
Sponsored by: SkunkWerks, GmbH
Technical assistance from: Oracle
Differential Revision: https://reviews.freebsd.org/D34746
liby-dev provides (only) liby.a. liby has no headers or man pages, and
there is no liby package. Add a special case to record no dependency on
the package that does not exist.
PR: 266923
Reviewed by: bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37429
This will enable VM access to all ZFS feature automatically, only on a
newly installed or provisioned VM or cloud instance.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37283
Deprovision feature of waagent is used for preparing to capture a
running VM and turn it into a VM image. Using it in the process of
building a VM image from scratch will cause some side effects such as
the hostname of the building host getting reset.
Remove calling the deprovision command and use a simpler way to fulfill
the requirements of the Azure VM image.
Sponsored by: The FreeBSD Foundation
The change extends vmimage.subr to handle a new parameter, VMFS, which
should be equal to either "ufs" or "zfs". When it is set to ZFS, we use
makefs to create a bootable pool populated using the same dataset layout
as bsdinstall and "poudriere image" use. The pool can be grown using
the growfs rc.d script, just as in UFS images.
This will make it easy to provide VM and cloud images with ZFS as the
root filesystem. So far I did not do extensive testing of cloud images;
I merely verified that creation of ZFS-based AWS AMIs works and allows
me to create amd64 and arm64 EC2 instances with ZFS as the root
filesystem.
Reviewed by: emaste, gjb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34426
devmatch is useful on standalone machine but not on jails.
Put devinfo(8) and libdevinfo there too.
Differential Revision: https://reviews.freebsd.org/D36229
It's not really useful in a jail or in a mdroot or even if a users
wants to do a full zfs machine.
Reviewed by: mckusick
Differential Revision: https://reviews.freebsd.org/D36227
It is useful to have zfs utilities and lib in a separate package as
it allow users to create image that can support ZFS (i.e. not with
WITHOUT_ZFS in src.conf set) without bloating the default image with
all zfs tools (for example for jails).
Differential Revision: https://reviews.freebsd.org/D36225
For most users it's not needed to boot and they are also
available in the FreeBSD-rescue package in case an update
break and FreeBSD-geom package isn't updated correctly.
Differential Revision: https://reviews.freebsd.org/D36224
It doesn't really make sense to have it in runtime and let's not
bloat utilities more.
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D36222
It doesn't really make sense to have it in runtime and let's not
bloat utilities more.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D36221
We need to do a relative link to efi instead of an absolute link into
the build tree.
Sponsored by: Netflix
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D36941
I somehow introduced the typo when extracting one part of D34598.
Reported by: Jose Luis Duran <jlduran@gmail.com>
Fixes: 9871ae6aa9 ("Track kern.ipc.somaxconn -> ...")
Currently the installer is only started on the primary ("high level")
console. For systems where this is the video console and serial consoles
aren't of interest, and headless systems with just a serial console,
this works just fine, but for systems where both video and serial
consoles are present and meaningful this requires the user to select the
right primary console in loader, with the poor user experience of the
system appearing to hang if they leave the wrong one selected. This
notably differs from our multi-user behaviour of spawning getty on every
console, where the only issue with selecting the wrong primary console
is a quieter boot process until the login prompt appears (or the system
crashes).
Instead, use the newly-added runconsoles helper to run the installer on
every console (except for ttyv*, where only ttyv0 will be used). For
interactive installations, any of the consoles can be used, though only
one should be used at a time as no effort is made to avoid multiple
installations running at the same time clobbering each other. If the
Live CD option is selected, the other installers (which should, if the
user is well-behaved, be sitting at the welcome screen) will be killed.
If an automated install is in use, the primary console will be used to
display its output, and the others will direct the user to the primary
console.
Reviewed by: brooks, gjb
Differential Revision: https://reviews.freebsd.org/D36805
This separates out the install media-specific environment (creating
bsdinstall_etc) from actually running the installer on a given console.
This will be used by a future change to start the installer on multiple
consoles.
Reviewed by: brooks, gjb
Differential Revision: https://reviews.freebsd.org/D36803
The cons25w line was added in c991a64747 for pc98, along with reading
MACHINE in order to determine what terminal type to use for VTYs. Commit
2b375b4edd removed this condition, leaving it as always using xterm
for VTYs, but left behind the now-unused MACHINE variable and the
cons25w list entry. Clean these up to be how they were before pc98
support was added.
Note that anyone who really needs a cons25w terminal can still request
it, it's just not listed as a common option.
Reviewed by: imp, brooks
Differential Revision: https://reviews.freebsd.org/D36587
Traditionally, we've used /boot/msdos for the MBR mount point for the SD
images that we produced. For GPT and bsdinstall, we've used
/boot/efi. Migrate to using /boot/efi for MBR as well and add a
/boot/msdos -> /boot/efi symlink for compatibility (which may disappear
before 14.0, but will remain on the stable branches).
When we first created the arm images, there was no EFI booting and the
FAT partion on an MBR image was used to hold the firmware, uboot.bin,
SoC config files and ubldr. When we transitioned to uboot with EFI, we
put the loader files in the same partition. Later we standardized on
/boot/efi at about the same time we added GPT support to the RE produced
images. We left the MRB case as /boot/msdos for legacy reasons and since
it wasn't always EFI. Later, we dropped support of non-EFI booting on
the RE produced images, so the duality of /boot/msdos diminished even
more. Since so little secondary meaning remains, putting it all in
/boot/efi standardizes the location and reflects the RE images
better as using efi-only booting.
In addition, always label the msdosfs partion 'efi'. While a small
misnomer on some systems that store other files in the ESP, it was
requested in review for more consistency for similar reasons to the
mountpoint rename. There was no way to have an 'alias' or 'second label'
here, so this breaks compatibility. Since the images are self-contained,
this was judged to be an acceptable change.
Sponsored by: Netflix
Reviewed by: manu, allanjude, emaste, gjb
Differential Revision: https://reviews.freebsd.org/D36635
This can be useful instead of reboot if installing in a virtual machine,
and the user wants to modify the VM hardware or virtual media mounts
prior to booting into the newly installed system.
Reported by: Juan Manuel Palacios (@jmp_imaginarium on Twitter)
Approved by: philip
Differential Revision: https://reviews.freebsd.org/D36560
This makes it more obvious that the media being booted is an installer
rather than an installed system, which is otherwise hard to distinguish.
It also provides a more user-friendly, and more accurate, prompt.
Reviewed by: gjb
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36419
This makes use of the new -N etcupdate flag and merges the resulting
METALOG into base.meta re-rooted to /var/db/etcupdate/current.
Reviewed by: gjb
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35858
This is in preparation for non-FreeBSD builds where make is GNU make and
so etcupdate needs to know the name of or path to the bmake binary to
use for its own builds.
Reviewed by: gjb
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D35855
