Do you will upgrade to release 15? Or what is your general major version upgrade scheme?

cy@ · Oct 7, 2025

anguisette said:
hah, well... yes, except if you use ports packages from pkg.freebsd.org, in which case the text change causes all your packages to suddenly vanish until the builders catch up and publish packages for the new release. (then you get to learn about overriding ${ABI} in pkg.) this is one of the reasons i always tell people not to use pkg.f.o for -CURRENT, but it would be nice if we could make that work a bit nicer.

Because sometimes all we can base our updates on is a text string. This is a problem even if you have your own poudriere. The text string is baked into package meta-file. Could we (ports) do better? Most certainly. With compatibility shims in place this would never be a problem. Look at how symbols are versioned in libraries. A library will support multiple versions of a function or syscall, i.e. statfs(2). The library supports 64-bit and legacy (32-bit) inode arguments.

anguisette said:
(also, for some reason the switch to 16 broke the net-snmp port, presumably because they have some whitelist of versions.)

That's because some software, typically GNU configure, looks at the version string. There's not getting around that. But generally, if one follows -CURRENT the changes are incremental.

Zare · Oct 7, 2025

When we move to pkgbase, will we have all those few hundred system packages listed in pkg info, or will we have some sort of separation?

For example I dislike how dpkg -l on a minimal Debian install still spews out few screens of packages.

This all sounds too Linuxy and I'm not sure I like it that much (albeit seeing the benefits too). I'm not sure why I want to have all those base parts separated.

anguisette · Oct 7, 2025

Zare said:
When we move to pkgbase, will we have all those few hundred system packages listed in pkg info

yes.

Zare said:
For example I dislike how dpkg -l on a minimal Debian install still spews out few screens of packages.

you can filter by pkg name (pkg info | grep -v '^FreeBSD') or by origin (pkg query -e '%o !~ base/*' '%n-%v %c'). if you do that a lot, add an alias in pkg.conf or in your shell.

Zare said:
This all sounds too Linuxy and I'm not sure I like it that much (albeit seeing the benefits too).

well, Solaris released with pkgbase in 1992 and it worked the same way. did Sun copy Linux?

RetroComputingCollector · Oct 7, 2025

ralphbsz said:
Exactly. I will stay on 13.x as long as there is a supported 13.x version. Then I will switch to 14.x, and stay on that as long as there is support, which I think is until 2028 or thereabouts. Not clear yet whether I will move to 15.x ever; that depends on whether by then pkgbase and the foundation's newfound love for desktop/laptop support make it a desirable option for a server-class machine.

I am actually considering switching some of my machines to NetBSD, as I feel like FreeBSD is going down a road to Linux. NetBSD has a better non-linuxified X implementation, and no pkgbase. I fear I will have to stick on 14.x until it is EOLed, slowly replacing FreeBSD installs with NetBSD, as the EOL date grows nearer, and in the end only having one FreeBSD machine left. By the way, I tried pkgbase. It sucks as much as an industrial vacuum. Hopefully I don't have to abandon FreeBSD, and I still don't think I have the follow-through to do it, but I might if it gets bad enough.

bakul · Oct 7, 2025

I got a Mac Mini (late 2014) for almost nothing. Installed 15.0-ALPHA5 painlessly (using package install from a memstick image snapshot). This will replace a server so I have tested only things I need but X11 came up fine.

There are 304 FreeBSD-* packages which is a bit distressing (but I felt the same way when they split up xorg into a zillion little pieces). On the other hand I also complain about the texlive-texmf package weighing in at 3GB!

astyle · Oct 7, 2025

bakul said:
There are 304 FreeBSD-* packages

I have about 5 times that many packages, and I compile from ground up and I change the Makefile knobs in Ports. At least I'm not beholden to somebody else compiling my GPU drivers

on a schedule that I don't wanna know or put in effort to find out.

I'm running 14.2-RELEASE as my daily driver, and y'know what, every time I deal with Windows Update on a couple other machines at my place, WU never ceases to amaze me with the plentiful harvest of brand-new reasons to stay away from Windows. If I had just a dollar for every new reason to stay away from Windows, I could solve WIkipedia's fundraising needs for at least 10 years, easy.

meaw229a said:
Saying that in these days we have VM's. Just try around there and see what happens.

One kind of needs enough metal at their disposal before talking about running VMs...

Zare · Oct 9, 2025

anguisette said:
yes.

you can filter by pkg name (pkg info | grep -v '^FreeBSD') or by origin (pkg query -e '%o !~ base/*' '%n-%v %c'). if you do that a lot, add an alias in pkg.conf or in your shell.

well, Solaris released with pkgbase in 1992 and it worked the same way. did Sun copy Linux?

This is the exact reply I did not want to get. I'll refrain from posting sarcastic remarks about the discovery of grep.

It is what it is and I don't like it.

vmisev · Friday at 1:21 AM

T-Aoki said:
Security fixes.
Any fixes (except that anything cannot happen on main) are introduced into main (aka -Current), tested, then MFC(Merge From Current)'ed into latest (if the code to be fixed matches, including older) stable branch, unless it's too urgent to wait for test results and possibly to apply stable branches.

Then, tested on latest stable branch and when considered OK, MFS (Merge From Stable)'ed into corresponding Releases and previous stable. Repeat.

So I chose latest stable, considering balance between risk and benefit.

Talking about security, I just noticed that pkg audit now works for the base as well. On FreeBSD 15.0-STABLE stable/15-n280708-bbfaff26bf36 GENERIC:

Code:

 > pkg audit
libxslt-1.1.43_1 is vulnerable:
  libxslt -- unmaintained, with multiple unfixed vulnerabilities
  CVE: CVE-2025-7425
  CVE: CVE-2025-7424
  WWW: https://vuxml.FreeBSD.org/freebsd/b0a3466f-5efc-11f0-ae84-99047d0a6bcc.html

linux-rl9-libxml2-2.9.13_8 is vulnerable:
  libxml2 -- multiple vulnerabilities
  CVE: CVE-2025-49795
  CVE: CVE-2025-49795
  CVE: CVE-2025-49794
  CVE: CVE-2025-6170
  CVE: CVE-2025-6021
  WWW: https://vuxml.FreeBSD.org/freebsd/abbc8912-5efa-11f0-ae84-99047d0a6bcc.html

2 problem(s) in 2 package(s) found.

but

Code:

 > pkg audit -r FreeBSD-base
FreeBSD-base is vulnerable:
  openssl -- potential SSL 2.0 rollback
  CVE: CVE-2005-2969
  WWW: https://vuxml.FreeBSD.org/freebsd/60e26a40-3b25-11da-9484-00123ffe8333.html

  gzip -- directory traversal and permission race vulnerabilities
  CVE: CVE-2005-1228
  CVE: CVE-2005-0988
  WWW: https://vuxml.FreeBSD.org/freebsd/63bd4bad-dffe-11d9-b875-0001020eed82.html

  bzip2 -- denial of service and permission race vulnerabilities
  CVE: CVE-2005-1260
  CVE: CVE-2005-0953
  WWW: https://vuxml.FreeBSD.org/freebsd/197f444f-e8ef-11d9-b875-0001020eed82.html

  kernel -- TCP connection stall denial of service
  CVE: CVE-2005-2068
  CVE: CVE-2005-0356
  WWW: https://vuxml.FreeBSD.org/freebsd/3ec8f43b-e8ef-11d9-b875-0001020eed82.html

  FreeBSD -- FPU information disclosure
  CVE: CVE-2006-1056
  WWW: https://vuxml.FreeBSD.org/freebsd/1fa4c9f1-cfca-11da-a672-000e0c2e438a.html

  Overflow error in fetch
  CVE: CVE-2004-1053
  WWW: https://vuxml.FreeBSD.org/freebsd/759b8dfe-3972-11d9-a9e7-0001020eed82.html

  tcpdump ISAKMP payload handling remote denial-of-service
  CVE: CVE-2004-0184
  CVE: CVE-2004-0183
  WWW: https://vuxml.FreeBSD.org/freebsd/f8551668-de09-4d7b-9720-f1360929df07.html

  many out-of-sequence TCP packets denial-of-service
  CVE: CVE-2004-0171
  WWW: https://vuxml.FreeBSD.org/freebsd/e289f7fd-88ac-11d8-90d1-0020ed76ef5a.html

  shmat reference counting bug
  CVE: CVE-2004-0114
  WWW: https://vuxml.FreeBSD.org/freebsd/f95a9005-88ae-11d8-90d1-0020ed76ef5a.html

  gzip -- multiple vulnerabilities
  CVE: CVE-2006-4338
  CVE: CVE-2006-4337
  CVE: CVE-2006-4336
  CVE: CVE-2006-4335
  CVE: CVE-2006-4334
  WWW: https://vuxml.FreeBSD.org/freebsd/11a84092-8f9f-11db-ab33-000e0c2e438a.html

  bind8 negative cache poison attack
  CVE: CVE-2003-0914
  WWW: https://vuxml.FreeBSD.org/freebsd/f04cc5cb-2d0b-11d8-beaf-000a95c4d922.html

  L2TP, ISAKMP, and RADIUS parsing vulnerabilities in tcpdump
  CVE: CVE-2004-0057
  CVE: CVE-2003-1029
  CVE: CVE-2003-0989
  WWW: https://vuxml.FreeBSD.org/freebsd/96ba2dae-4ab0-11d8-96f2-0020ed76ef5a.html

  openssh -- multiple vulnerabilities
  CVE: CVE-2006-5051
  CVE: CVE-2006-4924
  WWW: https://vuxml.FreeBSD.org/freebsd/32db37a5-50c3-11db-acf3-000c6ec775d9.html

  kernel -- information disclosure when using HTT
  CVE: CVE-2005-0109
  WWW: https://vuxml.FreeBSD.org/freebsd/180e9a38-060f-4c16-a6b7-49f3505ff22a.html

  sppp -- buffer overflow vulnerability
  CVE: CVE-2006-4304
  WWW: https://vuxml.FreeBSD.org/freebsd/c9d2e361-32fb-11db-a6e2-000e0c2e438a.html

  openssl -- Incorrect PKCS#1 v1.5 padding validation in crypto(3)
  CVE: CVE-2006-4339
  WWW: https://vuxml.FreeBSD.org/freebsd/077c2dca-8f9a-11db-ab33-000e0c2e438a.html

  tnftpd -- remotely exploitable vulnerability
  CVE: CVE-2004-0794
  WWW: https://vuxml.FreeBSD.org/freebsd/c4b025bb-f05d-11d8-9837-000c41e2cdad.html

  Packages that depend on FreeBSD: 

17 problem(s) in 1 package(s) found.

tuaris · Saturday at 6:12 PM

RetroComputingCollector said:
I am actually considering switching some of my machines to NetBSD, as I feel like FreeBSD is going down a road to Linux. NetBSD has a better non-linuxified X implementation, and no pkgbase. I fear I will have to stick on 14.x until it is EOLed, slowly replacing FreeBSD installs with NetBSD, as the EOL date grows nearer, and in the end only having one FreeBSD machine left. By the way, I tried pkgbase. It sucks as much as an industrial vacuum. Hopefully I don't have to abandon FreeBSD, and I still don't think I have the follow-through to do it, but I might if it gets bad enough.

I'm having similar thoughts for post 15.x or 16.x (since pkgbase is still optional for now). What's the point of using FreeBSD over Linux if it's going to be 'more like' Linux, but not actually Linux? I've gone to great lengths avoiding Linux and using FreeBSD for everything, even at the expense of not using certain software because it doesn't run on FreeBSD.

PKG base as it's currently implemented (by sharing the userland package management with system package management) is looking like a major deal breaker.

I don't know, maybe this is a preliminary step towards a future where user-land packages and ports are deprecated? To go back to installing third party software from the source (as binaries) rather than from a centralized 'marketplace'. I'd actually be in favor of that. It does seem that's the direction things are moving in.

Also, I can't imagine make buildworld and make buildkernel going away. That would cause quite a stir. So I think this may go one of two ways:

pkgbase will work "good enough" and will remain in FreeBSD. Some people are using it, but it never gain significance or critical mass as the majority of users revert or opt to go to freebsd-update or source based upgrades once freebsd-update is deprecated (and even then someone else may continue working on freebsd-update). Maybe FreeBSD might get forked and we'll have a version without pkgbase, or a version with a better engineered version of it.
There will be a moment when everyone involved with this decision comes to realize that this was a mistake. It's near impossible to deprecate freebsd-update becuase too many people still use it. Very few people are using pkgbase, and it's been problem after problem with it. Everyone's doing source upgrades, pkgbase gets neglected. Sometime around FreeBSD 17 or 18, pkgbase is finaly removed.

I just don't see a situation where pkgbase actually gains any significance, so long as make buildworld and make buildkernel still exist. Nowhere. Not the server, not the desktop, not even embded.

astyle · Saturday at 7:11 PM

tuaris said:
even at the expense of not using certain software because it doesn't run on FreeBSD.

Now this is actually funny. When it comes to user applications with nice features, FreeBSD's Ports Collection is perfectly viable, and has lots of the same softwares.

astyle · Saturday at 7:16 PM

tuaris said:
even at the expense of not using certain software because it doesn't run on FreeBSD.

Now this is actually funny. When it comes to user applications with nice features, FreeBSD's Ports Collection is perfectly viable, and has lots of the same softwares.

Oh, man, this is a duplicate, thanks to the wonky wifi driver... I do have a separate thread where I ask for help with it: Thread help-with-intel-8265-ac-card.99636. Card is dropping connections randomly, and I suspect this is due to data buffer issues and ability to reset the card...

Espionage724 · Saturday at 8:50 PM

I run updated versions of any OS as soon as an image is available! (I used 14.2-R a few days early

)

I went to 14.2 and 14.3 as soon as they were available and had no problems. I'm not aware of any 15 features I'd benefit from hugely so I'd wait until a RELEASE image. I don't do OS upgrades and clean-install the newest.

dclau · Saturday at 10:07 PM

It will be 15.1, why would I rush things? Always did it that way, never failed (potentially a thing yet to come). Keeping a keen eye on the forums used to help.
To each, their own.

bumpyhead · Saturday at 10:09 PM

I will use pkg-base to upgrade from 14.3 to 15.0, is this doable?

fmc000 · Sunday at 3:20 AM

bumpyhead said:
I will use pkg-base to upgrade from 14.3 to 15.0, is this doable?

Yes

fmc000 · Sunday at 3:25 AM

dclau said:
It will be 15.1, why would I rush things? Always did it that way, never failed (potentially a thing yet to come). Keeping a keen eye on the forums used to help.
To each, their own.

Well, trying to upgrade from 14.3 to 15 went flawlessly on my test laptop and in my test VM, so I was confident enough to proceed on my main system... On which I had to rollback because of a serious regression in handling nvme suspend/resume. Hopefully having caught this issue so early will help solve it when 15 is officially out.

T-Aoki · Sunday at 3:48 AM

fmc000 said:
Well, trying to upgrade from 14.3 to 15 went flawlessly on my test laptop and in my test VM, so I was confident enough to proceed on my main system... On which I had to rollback because of a serious regression in handling nvme suspend/resume. Hopefully having caught this issue so early will help solve it when 15 is officially out.

Reading Comment 7 of PR 290265 (you opened this?) by Warner, he seems NOT to be able to reproduce it (otherwise, he wouldn't have written the process to try, I guess).

So I think help from someone bitten by the issue to report back would be mandatory to find the root cause and fix the issue.

This kind of things often happen on hardware specific issues in volunteer based projects like FreeBSD (i.e., I cannot test issues specific with GSP-dependent nvidia GPU, as I don't have GPUs to test. mine is Quadro P1000 notebook and without GSP in it).

For expensive proprietary software products with expensive enough annual (or per-ticket basis) maintainance contract, the developer can purchase exactly same version (hopefully, exactly same manufacturing lot) of related hardware and proceed enough tests using electronic-signal-revel of analyzers, though.

fmc000 · Sunday at 4:23 AM

T-Aoki said:
Reading Comment 7 of PR 290265 (you opened this?) by Warner, he seems NOT to be able to reproduce it (otherwise, he wouldn't have written the process to try, I guess).

So I think help from someone bitten by the issue to report back would be mandatory to find the root cause and fix the issue.

This kind of things often happen on hardware specific issues in volunteer based projects like FreeBSD (i.e., I cannot test issues specific with GSP-dependent nvidia GPU, as I don't have GPUs to test. mine is Quadro P1000 notebook and without GSP in it).

For expensive proprietary software products with expensive enough annual (or per-ticket basis) maintainance contract, the developer can purchase exactly same version (hopefully, exactly same manufacturing lot) of related hardware and proceed enough tests using electronic-signal-revel of analyzers, though.

Please take a look at my Comment 9. I'm all in in trying to help debug this issue. I kept everything I could in case they're needed...

Code:

5:22][fmc000@tu45b-freebsd ~]$ bectl list                                               
BE                   Active Mountpoint Space Created
FreeBSD-14.3-STABLE  NR     /          31.2G 2025-06-24 14:32
FreeBSD-15.0-RELEASE -      -          202M  2025-10-17 08:36
FreeBSD-15.0-STABLE  -      -          14.7G 2025-10-11 11:33
[5:22][fmc000@tu45b-freebsd ~]$

PMc · 2025-10-20T11:26:37+0100

cy@ said:
15 brings in a modern Kerberos among other improvements.

Yeah, and I would like to really cordially thank You for undertaking that operation - as it is one of the tiresome and elaborate ones.

cy@ said:
Too many people feel updating or applying patches break things. This is probably due to their experience with Microsoft Windows, which breaks pretty much every Patch Tuesday. Other operating systems aren't this sloppy.

Updating to another major release does bring surprizes on any sufficiently complex site, and a lot of them are unpleasant. When to do it for an otherwise just working environment is a difficult question, but one should plan for enough time (preferably on-site) to investigate.

Lets put some flesh to the bones and look at a few issues from my recent upgrade 13->14:

commandline interpretation in the ps command has changed (concerning the -J option), some scripts did misbehave.
booting failed randomly when using more than two NUMA domains. After analysis, the actual bug (PR 289204) was found and fixed.
unicode locale version bump. Postgresql clusters needed some extra patting to become happy again. (I didn't even know that locale has a version)
the BIND/named gssapi feature didn't work with Heimdal any longer, but when installing MIT, it didn't work either. Only when going into debug, it provided a useless error message "internal cryptosystem error". Discussion on BIND mailinglist didn't help, and I needed to pimp the krb5 package with lots of printf(), then I was able to pinpoint the problem: security/krb5 insists on using /dev/urandom but the chroot as implemented inside rc.d/named doesn't unhide that device.
The gssapi issue was already documented in PR 275241, but the chroot issue wasn't known, as GSSAPI is not a default option here.
audio/ardour doesn't start on empty anymore - currently unresolved PR 289714 (may or may not be upgrade-related).

All of these happen to happen only with specific applications, specific hardware or specific scripting. Running a test system doesn't help much, and rolling back a whole environment via ZFS may create more hassle than to workaround the individual issues (after they have been properly identified, that is). In any case it takes time and effort.

cy@ said:
But a trickle of commits or package updates each and every day one doesn't really notice much of a difference from one day to the next. It's like watching your kids grow up. You don't notice the changes. But go away somewhere, i.e. for a job, and come back a year later and you notice significant growth.

That sounds cute - but I don't think one can do that with an environment of some ten or more diversified instances and lots of usecases. Many of the routines do not run daily, and one may find a problem only a fortnight later or so. Also, if e.g. IPv6 fails in some specific situation, things do silently fallback to IPv4, and that may go unnoticed for quite a while.
Then the question arises, where was that problem introduced; and there are already three possible souces of changes: local, application and OS. I wouldn't want to hunt issues on a constantly moving target.
The alternative would be to have full automated test coverage for everything. But that's a different story...