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

zpool upgrade:
If you need features that come in with the upgrade, then simple to "update bootcode before doing zpool upgrade"
If you don't then you have no need to do zpool upgrade.
New bootcode is backwards compatible, but old bootcode may not understand new zpool stuff.

So even using ZFS, BEs just be aware of the relationship between bootcode and zpool upgrade.
 
mer said:
If you need features that come in with the upgrade, then simple to "update bootcode before doing zpool upgrade"
Click to expand...
It's not always 100% works.
If zpool upgrade (accidentally) attempts to enable any read-incompatible features that are NOT listed here, boot can fail.

Basically, this shouldn't happen, as such a feature should be patched out on FreeBSD, even if enabled upstream. But human makes mistake.

Another thing is bugs exposed first on FreeBSD. An example would be bclone issue happened when stable/14 was created, thus, sysctl vfs.zfs.bclone_enabled was introduced.

Related caution here.
 
  • Like
Reactions: mer
fmc000 said:
May I ask you why you made this choice and what are the advantages? And in case I decide to follow this path, what should I do? Thanks in advance.
Click to expand...
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.
 
Code: 
The freebsd-update(8) utility supports binary upgrades of amd64 and aarch64
systems running earlier FreeBSD releases.

NOTE: THE STEP OF UPDATING YOUR EXISTING SYSTEM FIRST IS NECESSARY.  An
errata notice was recently issued (FreeBSD-EN-25:18.freebsd-update) which
corrects a problem which otherwise results in systems becoming inoperative
when attempting to upgrade to 15.0.
 
POSIX.1 said:
Could you please elaborate on that or give some links?
Click to expand...
in 15.0, our ancient Heimdal 1.5 was replaced with MIT Kerberos. this means we now support modern key types (Heimdal was limited to aes256-sha1, and defaulted to DES), and the new libgssapi implementation provides better compatibility with third-party applications. in particular, you can now build a bunch of ports with base Kerberos where they previously required security/krb5.

if you use the base Heimdal KDC, a migration will be required when upgrading to 15.0, Rick is working on this at the moment.

fjdlr said:
The question I'm asking myself (perhaps someone has already answered it):
I'm upgrading my FreeBSD releases with
(Example)

from my current release:
FreeBSD 14.3-RELEASE-p3

Will the system switch directly to PKG-Base?
Click to expand...
upgrading with freebsd-update will not switch your system to pkgbase. switching to pkgbase will require a manual action, the specific details of which aren't finalised yet (but it will probably involve running the pkgbasify script).
 
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.
Click to expand...
And if I decided to follow your path, what should I do with my pkgbase-converted 14.3 machine?
 
Greybeards usually avoid XX point zero Releases (XX.0). And they have reasons for it.

Saying that in these days we have VM's. Just try around there and see what happens.
 
fmc000 said:
And if I decided to follow your path, what should I do with my pkgbase-converted 14.3 machine?
Click to expand...
As I don't know how often base pkgs for pkgbase are rebuilt for stable branches, I don't recommend my way for pkgbase users.
Most promising way for pkgbase users would be to track latest Release (currently 14.3 and 15.0 once it is released).

I'm going my "track latest stable" way because I'm using source upgrading method.
 
meaw229a said:
Greybeards usually avoid XX point zero Releases (XX.0). And they have reasons for it.
Click to expand...
It would be something like to avoid Windows update near the end of months (feature preview only), and Windows update has option to delay (by default, if I recall correctly, 1 week) applying.
 
I use -RELEASE, and generally upgrade when the quarterly ports have been built.

That means I'll migrate to 15.0-RELEASE something like Feb or Mar 2026.

RELEASE for me cos I want to use what most users are using. That does mean that I'm sometimes lagging behind changes in CURRENT. That can be a bit of a pain.

For the rest, VMs but that has limitations.
 
cracauer@ said:
I find -current to be pleasant. Except in the direct runup to a .0 release, as people rush in their changes.
Click to expand...
Yes, I've been using -CURRENT as my main FreeBSD since 2013. For every couple of hundred bugfixes and new features there may be one stinker. I've been very pleased with -CURRENT.

Even the run-up to 16-RELEASE it hasn't been that bad. I think I was the largest cause of -CURRENT churn when MIT replaced Heimdal. But that was to be expected as Kerberos is a beast.

The only major thing (I don't want to use the term issue as it's not an issue), is that some commit may change the Linux KBI. This breaks DRM, usually fixed by rebuilding/reinstalling the port. If you're a VirtualBox user the kmod may need the occasional rebuild too. Even with that I'm still glad I made the switch.
 
mer said:
zpool upgrade
Click to expand...
Frankly:
zpool upgrades to me are one of my greatest concerns about FreeBSD upgrades, because as you said (and others in several other posts) you need to know about to update the bootcode first.
And I'm also always worried to lose data, when upgrading. Twenty years of Windows usage (and some experience with some early Linux distros) simply made me paranoid about any kinds of updates and upgrades.
Seven years with FreeBSD still did not cure that yet.

I'm working on it. Since all FreeBSD upgrades, and especially updates I did since 10.? did not cause any real issue at all. And none trouble I wasn't the source of, because of not reading about what the upgrades bring, and how to deal with it. Reading, and knowing before, and no trouble had been caused at all. :cool:
But it's not easy to get rid of trauma. And there was a lot of shit I experienced with Windows (and Linux).
I'm working on it. 🤜🤛 I'm confident I will make it one day. 😎


However,
as long as it works, and there is no security gap, I don't see no reason to upgrade my pools.
And I also read several times here what you also said:
upgrading the zpools ain't necessary as long as you don't really need the new features.
And I don't.
But the reason I did zpool upgrades anyway in the past is, when a FreeBSD upgrade includes a new zfs version you get a kind of error message, when you do a zpool status. I don't know the exact text right now, but it's something like your pools are not at the newest zfs version, and you shall upgrade.

So, bottom line:
All zpool upgrades I did in the past were just to get rid of this "error message."
I'm too paranoid and pedantic, cannot simply ignore that, even if I see the things work as before. It nags me.

So, is there another way to deal with that?
 
Last edited:
Maturin said:
All zpool upgrades I did in the past were just to get rid if this "error message."
I'm too paranoid and pedantic, cannot simply ignore that, even if I see the things work as before. It nags me.
Click to expand...
zpool upgrade means "this newer version of zpool provides new features and may change some in a non-readonly fashion"
So Are these new things something you may actually need, now or in the future? Only you can answer, but if "yes" then before you do zpool upgrade, upgrade your bootcode (legacy/bios or UEFI). That saves you from getting stuck if you lost power had a reboot in between.
I've learned to ignore the error message :)

For me, bottom line:
"latest bootcode" understands latest zpool and older zpool (backwards compatibility). There may (i'm not sure) of cases where latest bootcode thinks an older feature is different permission (read, write, read/write) but I think it should still boot.
To me that means as long as latest bootcode is "good" (not broken) it should be safe to always update bootcode without zpool upgrade.
 
cy@ said:
The only major thing (I don't want to use the term issue as it's not an issue), is that some commit may change the Linux KBI. This breaks DRM, usually fixed by rebuilding/reinstalling the port.
Click to expand...
at least this particular issue will be fixed when drm is merged into base, although i think that's still waiting on the last batch of GPL code to be removed. that won't fix the other ports kmod issues, but i think drm is by far the most common issue here for users.
 
anguisette said:
at least this particular issue will be fixed when drm is merged into base, although i think that's still waiting on the last batch of GPL code to be removed. that won't fix the other ports kmod issues, but i think drm is by far the most common issue here for users.
Click to expand...
That's news to me.

The FreeBSD DRM was in base. It was removed because it was unmaintainable without a lot of developer effort. We couldn't keep up with our limited resources (number of developers). And so here we are.
 
pkg upgrade broke my installation (again). This time pkg: 2.2.2 -> 2.3.1 on my 14.3 test installation (something about Linux support). I dare not try it on my main 14.3 installation. This is why I am more nervous about upgrading FreeBSD than other operation systems as I stated earlier in this thread. I am using UFS so no roll back.

Affected applications include libreoffice.
 
I'm running something of a scrappy build VM that's really a throwaway thing for Poudriere experimentation. It runs CURRENT. Just the other day after a haphazard update something looked a bit off. Turns out the whole thing went from 15 to 16-CURRENT without a hitch. On real systems I run a much tighter ship, but this one was a pleasant surprise.
 
bvdw78 said:
I'm running something of a scrappy build VM that's really a throwaway thing for Poudriere experimentation. It runs CURRENT. Just the other day after a haphazard update something looked a bit off. Turns out the whole thing went from 15 to 16-CURRENT without a hitch. On real systems I run a much tighter ship, but this one was a pleasant surprise.
Click to expand...
It always does. It's just text string change.

It's not like there's any "magic" to this. When I worked on IBM mainframe MVS (O/S) support and development, that too had that text string change. People thought it was some monumental thing whereas it was in fact comprised of a bunch of little package updates. In the case of -CURRENT it's a bunch of commits which finally re@ changes the text string. But the idea is just the same. It's all the little things.

When I was still a grasshopper, purchasing FreeBSD CDs and DVDs from Walnut Creek each release was a monumental update because the snapshot in time that the release was included hundreds of commits to create a monumental step forward. So it is with every operating system. 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.
 
cy@ said:
It always does. It's just text string change.
Click to expand...
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.

(also, for some reason the switch to 16 broke the net-snmp port, presumably because they have some whitelist of versions.)
 
You must log in or register to reply here.
Back
Top