“FreeBSD 15.2 brings a fix for bsdinstall for installing from a remote pkgbase repository, updated OpenSSH, using ML-DSA-44/Ed25519 SSH host keys by default, VirtIO improvements, and other fixes:
– bsdinstall can now install from a remote pkgbase repository; in BETA1 this failed due to the installer’s small /tmp.
– OpenSSH has been updated to 10.6p2.
– ML-DSA-44/Ed25519 SSH host keys are now generated by default.
– virtio_random(4) now works with modern virtio PCI devices, such as QEMU’s q35 machine type.
– Kernel bug fixes relating to TCP RACK, inotify, and Linux getdents(2) emulation.”
The FreeBSD 15.2 release cycle has reached its second beta. Release Engineering Lead Colin Percival announced on the developers list that releng/15.2 is about to be marked BETA2, with builds starting shortly afterwards. The start may slip a little past midnight: the stable/15 snapshot builds had to be restarted and need to finish first, and the kmods_quarterly_2 builds are still running.
A fair number of changes landed in the week since BETA1. Here is what went in, grouped by area.
SSH and post-quantum host keys
This is the change most users will notice. OpenSSH in base moves forward through 10.5p1, 10.6p1 and 10.6p2, and the rc scripts now generate ML-DSA-44 and Ed25519 host keys by default. ML-DSA is the lattice-based signature scheme standardised by NIST as FIPS 204, so a freshly installed 15.2 system will come up with a post-quantum host key next to the classical one.
OpenSSH: update to 10.5p1, 10.6p1, 10.6p2 (emaste)
rc: generate ML-DSA44/Ed25519 host keys by default (jlduran / emaste)
ssh: use the defaultkey sentinel for the ML-DSA-44 default host key (emaste)
Virtualization: bhyve, vmm and virtio
bhyve: treat BAR registration failures as non-fatal (markj)
vmm: add a bulk TMR reset hook for Intel APICv (dch)
vmm: skip TMR rebuilds for edge-to-edge IOAPIC writes (dch)
virtio_pci_modern: enable virtqueues before completing attach (kevans)
virtio_random: defer the first enqueue until after DRIVER_OK (kevans)
The two virtio fixes are about initialisation ordering, which matters for FreeBSD running as a guest. The vmm changes touch interrupt handling on Intel hosts with APICv.
Kernel, filesystems and networking
inotify: open the target directory when adding a watch (markj)
amd64: make hw.splitlock_force adjustable at runtime (kib)
mqueuefs: set *a_eofflag in VOP_READDIR (delphij)
linux: bound native getdents and getdents64 batches (kevans)
TCP RACK: fix RSM computation for TCP Fast Open (tuexen)
Userland, libraries and installer
msun: fix nextafter*() and nexttoward*() behaviour for the MAX value (kargl / fuz)
bsdinstall: set TMPDIR in the pkgbase install (cperciva)
contrib/bc: remove the vs sub-directory (se / cperciva)
i2ctinyusb: do not list i2ctinyusb.c twice in SRCS (delphij)
pkg 2.9.2 is in the 2026Q4 ports branch (bapt)
How changes reach releng/15.2
The merge process is the one re@ has used for the past year. Developers do not push to the release branch themselves. They send a request to re@, and the release engineer decides whether to cherry-pick the commit. Unless Colin asks otherwise, only members of re@ and secteam@ push to releng/15.2. The criteria for requests are in the change request guidelines, and known problems are tracked on the 15.2 issues page.
If you have work in progress that should be in 15.2-RELEASE, tell re@ now. Three weeks remain before the release build.
Schedule
Milestone
Date
Ports quarterly branch
October 1, 2026
Reminder email
October 9, 2026
stable/15 slush
October 23, 2026
doc/ tree slush
October 30, 2026
releng/15.2 branch
November 6, 2026
BETA1 build starts
November 6, 2026
BETA2 build starts
November 13, 2026
doc/ tree tag
November 13, 2026
BETA3 build starts
November 20, 2026
Ports package builds
TBD (before November 27)
RC1 build starts
November 27, 2026
RELEASE build starts
December 4, 2026
RELEASE announcement
December 8, 2026
Support lifetimes
15.1-RELEASE end of life: March 31, 2027
15.2-RELEASE end of life: September 30, 2027
stable/15 branch end of life: December 31, 2029
Anyone on 15.1 has until the end of March 2027 to move to 15.2.
Help test
Betas exist to be broken. If you run FreeBSD in a VM, on EC2 or on spare hardware, BETA2 is a good one to try, since it carries the new SSH host key defaults and the virtio attach fixes. Check that your SSH clients and configuration management cope with the new host key type, and report anything that looks wrong on Bugzilla or to re@ before RC1 on November 27.
FreeBSD’s Q3 2026 development report highlights progress in AI contribution policies, cybersecurity compliance, virtualization management, desktop improvements, and system performance.
1. AI Policy Development
FreeBSD surveyed developers about the use of AI-generated contributions.
Survey Result
Percentage
Support establishing an AI policy
88%
Support AI-generated documentation with human review
65%
Want disclosure of AI-assisted code
35%
Favor treating AI-assisted code like other contributions
22%
Favor rejecting AI-generated code
16%
Key developments:
An AI working group has been established to draft an official policy.
Final working-group reports are expected in Q4 2026.
2. Cybersecurity and EU Compliance
FreeBSD is preparing for the European Union’s Cyber Resilience Act (CRA).
Development includes support for Software Bills of Materials (SBOMs).
Compliance preparation has required substantial developer effort.
3. Virtualization and Web Management
Bhyvemgr
Graphical management interface for the Bhyve hypervisor.
Expanded data-center and cluster-management features.
4. Desktop Improvements
Continued refinement of FreeBSD desktop installations.
Improvements to suspend/resume functionality.
Additional audio stack enhancements.
Ongoing desktop usability and stability work.
5. Kernel, Storage, and System Improvements
Storage: Better support for zoned storage devices.
Debugging: Enhanced debugging capabilities.
Scheduler: Various scheduling improvements.
Bootloader: Continued enhancements to the boot process.
For system administrators and self-hosting enthusiasts, Sylve’s evolving web interface and Bhyvemgr’s graphical virtualization management are particularly noteworthy.
New tool: Vermaden introduces pkgbase-update(8), a BSD-licensed utility designed to simplify FreeBSD base-system upgrades using PKGBASE.
Motivation: FreeBSD 15.x is the final major version supporting the traditional freebsd-update(8) mechanism.
FreeBSD 16.0: PKGBASE is intended to become the exclusive method for installing and updating the FreeBSD base system.
Main objective: Provide a familiar, straightforward interface resembling freebsd-update, avoiding complicated manual package-management procedures. 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗
Why the Tool Was Created
The official FreeBSD 15.2-BETA1 upgrade instructions require multiple manual operations:
Updating the pkg package manager.
Creating temporary repository configurations.
Upgrading FreeBSD base-system packages and kernel modules.
Updating the EFI bootloader manually.
Checking .pkgnew configuration files.
Cleaning temporary files and rebooting.
Vermaden considered this process unnecessarily complicated and developed pkgbase-update in approximately 2–3 hours.
Available Commands
Command
Purpose
pkgbase-update upgrade -r VERSION
Upgrade to a specified FreeBSD release
pkgbase-update install
Install the selected upgrade
pkgbase-update loader
Handle bootloader updates
pkgbase-update pkgnew
Check newly installed configuration files
pkgbase-update modules
Handle kernel-module-related checks
The tool provides a simplified interface around the existing PKGBASE infrastructure.
HyprBSD: Wayland Desktop on FreeBSD with Steam Gaming
FreeBSD has its own ongoing work to improve the desktop and laptop experience, including the installer, but that work has not yet shipped in a release.
HyprBSD is a new desktop-focused FreeBSD distribution that fills this gap now.
Origin
It was created by Sam Sheridan, an IT consultant who has administered FreeBSD for more than 25 years.
His motivation was frustration with FreeBSD’s out-of-the-box desktop experience, particularly the NVIDIA graphics drivers.
Earlier projects with similar goals include PC-BSD/TrueOS, helloSystem and GhostBSD, which is still active.
Specifications
It is based on FreeBSD 15.1-RELEASE.
A graphical installer gets a system running in about three minutes.
AMD, Intel and NVIDIA graphics are supported.
The desktop uses the Hyprland Wayland compositor.
XWayland handles software that depends on X11.
Gaming
Steam runs through FreeBSD’s Linux binary compatibility layer.
It has been verified with a variety of games, including BattlEye-protected titles.
Approach
Most of these changes could be applied to a stock FreeBSD install by hand. The value of HyprBSD is a polished, ready-made setup.
The project has also contributed fixes to FreeBSD itself to improve it on the desktop.
FreeBSD 15.2 Beta 1 introduces experimental cross-platform build support, security fixes, updated system components, and hardware improvements. The stable release is scheduled for December 8, 2026.
1. Experimental Cross-Platform Builds
FreeBSD base system packages can now be cross-built on Linux and macOS.
Requires manual configuration of the pkg utility on the build host.
Functionality remains experimental.
2. Security Improvements
Dozens of security fixes addressing:
Use-after-free vulnerabilities.
Heap buffer overflows.
Missing input validation.
Potential remote code execution.
The article highlights the growing number of security issues being identified in the AI/LLM era.
3. Updated System Components
Component
Version / Change
OpenZFS
2.4.4
LLVM
21.1.8
OpenSSH
10.4p1
XZ Utils
5.8.4
Default linker
LLVM ld.lld
– Clang now uses LLVM’s ld.lld linker by default unless explicitly overridden.
4. Laptop and Hardware Improvements
New backlight_enable option in rc.conf saves and restores display brightness across reboots.
Additional hardware driver fixes and new hardware identifiers improve device compatibility.
5. Cloud and Desktop Improvements
FreeBSD EC2 desktop AMIs on Amazon AWS now boot into a KDE desktop environment.
XRDP is enabled for remote desktop access.
6. Release Schedule
November 6, 2026: Beta 1 released.
November–December: Weekly beta releases followed by at least one release candidate.
FreeBSD srcmgr@ has launched llm-postcr, an opt-in service that runs each src commit through an LLM (currently Claude) and reports bugs after the commit.
Opting in: run touch ${HOME}/.llm-postcr-opt-in on freefall. If your home directory isn’t readable by others, email srcmgr privately. Reports go to the committer if they’ve opted in, otherwise to srcmgr.
What it reports: only concrete, observable problems, not style(9) issues. It also flags pre-existing bugs in the code a commit touches, and fixing those is generally up to the committer. The exception is a commit that fixes some instances of a problem but misses others, where the missed ones should be addressed.
Results so far: after a couple of weeks of running with manual validation, it found about 100 new and 50 pre-existing bugs in the last 500 commits, with widely varying severity.
Limits: it doesn’t replace code review or testing.
Plans:
An opt-in pre-commit review service is in the works.
Reports are logged in a database and may become public later, for example in Bugzilla.
keys: fall back on the host keys when using a root directory
pkg set -v: store the vital flag as a user override combined with the package’s own flag
clean: keep the exact archives of the installed packages
db: add out-of-schema pkg_local and pkg_attr to improve changes without schema incompatibilities
upgrade/install: report why each installed package that the plan removes
upgrade/install: require an explicit confirmation before removing explicitly installed packages
upgrade/install: require an explicit confirmation before removing explicitly installed packages
upgrade/install: add -N/–no-remove and NEVER_REMOVE to refuse removing unrequested packages
solver: hold an upgrade back instead of removing an explicitly installed package, and report the packages that are held back
libpkg: recognize loongarch64 ELF objects and the loongarch:64 ABI
scheduler: order the packages providing a shared library or a named provide before the packages requiring them
signing: add an ML-DSA-87 signer, keys are created with pkg key –create -t mldsa and repositories are signed with –sign-type mldsa, with SHA512 as the digest
Minor changes:
config: make PKG_CONFIG_FILE a configuration variable
libpkg: escape spaces in metalog filenames
fetch: detect up-to-date responses that do not carry a 304 Not Modified
repo: keep the previously fetched catalogue when an update fails
checksum: add the z-base-32 and hex encodings for sha256, blake2 and blake2s
support for openssl 4
signing command can override the checksum algorithm
rwhich performance improvements
fix: a plist variable name matching
db: the read-only commands can read a database created by an older pkg(8) (skipping upgrades)
solver: do not install a package offered by several repositories when nothing needs it.
libfetch: sync with FreeBSD-current
update vendored softwares to latest versions
pkg add: remove the temporary files and directories left by a failed extraction
AI incorrectly explained the default and reserved-space calculation.
zfs_arc_min_prescient_prefetch_ms
AI suggested 10 ms instead of the actual 6000 ms default.
zfs_dirty_data_max
AI inadequately explained the risks of accumulating unwritten data in RAM.
dnodesize
AI incorrectly described the default and supported sizes.
Metaslab allocation tuning
AI confused defaults and claimed performance benefits without justification.
redundant_metadata
AI incorrectly described redundancy behavior and the default setting.
Klara Systems
3. Why AI-Based ZFS Tuning Is Risky
Version differences: Recommendations may apply to obsolete OpenZFS releases.
Platform differences: Linux and FreeBSD may expose different tunables or defaults.
Parameter interactions: Changing one setting can affect other aspects of ZFS behavior.
False confidence: Plausible technical explanations can conceal fundamental errors.
Data integrity: Certain changes can increase the amount of data vulnerable to an unexpected shutdown.
4. Recommended Approach
Start with OpenZFS defaults.
Consult current official documentation before changing tunables.
Understand the purpose and side effects of each parameter.
Benchmark changes against representative workloads.
Validate performance improvements rather than assuming they exist.
Seek experienced ZFS engineering assistance for critical production deployments.
5. Conclusion
Klara Systems argues that general-purpose AI models should not be trusted as authoritative sources for ZFS performance tuning.
Key takeaway: AI can assist with researching ZFS concepts, but configuration decisions should rely on current documentation, measured workload behavior, and technical validation.
For a TrueNAS deployment, this means avoiding arbitrary ARC, RAIDZ, metadata, or write-cache tuning based solely on AI recommendations.
FreeBSD Team is actively testing a migration to Phorge on the reviews-dev instance and hopes to have a more detailed announcement on timing for a cutover within the next day or so.
The migration runtime seems to be about 2 hours and given that the phabricator has been EoL, this seems like the most prudent path forward.
They also investigated the option of setting up a socks5 proxy and allowing people to get into the existing instance behind an SSH tunnel in the interim; however, decided that it would probably make the most sense to focus on just migrating.
It is the normal minor-release schedule with the release scheduled for March 9th.
Note that 14.6 will be the final release from the stable/14 branch, and thus also the final FreeBSD release to support the i386 platform.
14.6-RELEASE schedule:
ports quarterly branch: January 1, 2027 reminder email: January 7, 2027 stable/14 slush: January 21, 2027 doc/ tree slush: January 28, 2027 releng/14.6 branch: February 5, 2027 BETA1 build starts: February 5, 2027 BETA2 build starts: February 12, 2027 doc/ tree tag: February 12, 2027 BETA3 build starts: February 19, 2027 ports package builds: TBD (before February 26) RC1 build starts: February 26, 2027 RELEASE build starts: March 5, 2027 RELEASE announcement: March 9, 2027 14.5-RELEASE EoL: June 30, 2027 14.6-RELEASE EoL: November 30, 2028 Branch EoL: November 30, 2028
