Tired of upgrading, where's my LTS?!?

FreeBSD needs LTS releases (>=5y)


  • Total voters
    57
... some it guy has to do a yum update -y every few months. And they were fine. Even heartbleed didn't affect them.

Oh yes it did. Heartbleed most definitely affected RHEL. Or more accurately, every single web server that uses OpenSSL including Apache and NGINX.

To fix it on RHEL all you had to do was yum update -y .

On FreeBSD all you had to do was pkg update && pkg upgrade and type the letter 'y' when it asked for confirmation to proceed.

I want to be able to put the pkg update && pkg upgrade into a cron job (and also the freebsd-update related commands for the core OS). Some people say that is crazy/scary/too risky. They have legitimate arguments based on their risk apatite. Some of us believe we have sufficient mitigating controls in-place to bring the risk within acceptable levels for our particular risk apatite.
 
There is a -y flag for pkg as well, but I tend to agree with gkontos, sooner or later it will (with pkg, yum, apt, or anything) do something to make you say, "Oh darn. I shouldn't have used -y there."
 
This thread's not going to resolve anything or pose any meaningful solutions, because no-one's bothered to define what the actual problem is. Are we complaining about upgrades to FreeBSD? To installed packages? Or are we simply complaining about the lack of paid, cover-your-ass support contracts that let us shift blame onto faceless nobodies we don't care about, poor schmucks working in the bowels multi-million-dollar companies that our employers' tiny legal departments would never be stupid enough to mess with, just so our ignorant bosses will shut up? Without knowing what the real concern is there's not much further this thread can go.
 
no-one's bothered to define what the actual problem is.

I was wondering that myself. I'm not a production user, just some old guy who fiddles with a lot of stuff. However, the only problems I've encountered with FreeBSD upgrade over the years have been because my own lack of expertise and basically my own fault. Looking back on the kinds of problems I've had with Linux (which I've used since it came out) have been because of (largely) unwanted modernizations of the software.

On a side note; Frankly, regardless of one's personal preferences or professional needs, I don't think one can ever win. It always amuses me how people go on about the importance of their particular verdict when deciding what they argue is the only logical choice for them or their situation. To me it looks more like just defensive ammunition. When people are happy with what they have, they'll make it work. This goes for the corporate as well as the home user.
 
On enterprise-grade Linux systems like RHEL, CentOS, Oracle Linux and similar spinoffs, you have no less than ten years of low-risk upgrades. The odd new feature may be introduced in a minor release without any drama. And I know for sure that a CentOS server that I setup back in 2014 can be kept as is until 2024, because bug corrections and security fixes will eventually be backported until then.
I happen to work with one of those enterprise-grade Linux systems. For starters in a serious business environment here in U.S. we typically use desktops for about three years and servers about five. That time coincide with a typical manufacturer warranty. I have quite a few servers which are over five years old but no server older than 8 years after one of them recently died during the planned power shutdown. To be frank with you LTS beyond 5 years makes little sense as those machines should be replaced with new hardware.

Speaking of Red Hat derivatives you mentioned, you probably know the upgrade among major versions is not supported. As a mater of fact Red Hat 6 used Ext2 for a root partition while Red Hat 7 completely moved to XFS. As somebody who works daily with RHEL, FreeBSD, and OpenBSD I see no major advantage or disadvantage of RHEL over the BSDs (FreeBSD 10 and later supports binary updates just like OpenBSD via openup). Actually FreeBSD installed on the ZFS pool is the safest system to update as you can always go back to the previous snapshot via beadm.

https://blather.michaelwlucas.com/archives/2363

In terms of upgrading between releases OpenBSD is the easiest (but it could be due to my familiarity with the system).

FreeBSD has a lots of problems. Please check my post in this thread

https://forums.freebsd.org/threads/59058/

but LTS is definitely not the one of them. RHEL really has an edge in terms of automatic, unattended installation over FreeBSD if I need to point one advantage of RHEL.

Comparing to RHEL/Ubuntu (with few exceptions all other so called distributions bring nothing except custom wallpapers) any of BSDs and FreeBSD in particular could be considered hobby projects if not for the rich UNIX history. I don't understand Linux guys who come onto this forum and say FreeBSD should do this or that. FreeBSD has no Red Hat, Canonical, HP, Oracle, IBM behind itself like Linux (iXsystems is moms and paps shop at best) so it should not act as one.

IMHO not replacing OpenSSL with LibreSSL is far bigger FreeBSD problem than LTS.
 
I'm generally satisfied with the current model. What I would like to see added is security-fix-only support for the last release of one major version (let's call it 10.3) until the .1 release of the next major version (11.1 in this case) has been out for 6 months.

A bunch of us with multiple production servers are wary of going with any .0 release. This wariness is reinforced by the number of threads we see here with people reporting problems either going from 10.3 to 11.0 or once they are on 11.0. While we don't use freebsd-update (we build new system images from scratch and then use a deployment script to push them to production servers), there are enough other issues to make us wary. Consider my "Who the heck tested this?" post here, which also links to another thread where someone had their mfi(4) controller (a very popular device) fail to be detected in 11.0 after working fine in 10.x.

And practically, it will take us a few months to get all our locally-developed stuff tested and approved for a new major release. Hence my request for "11.1 + 6 months". This could be called "extended support" or "mature version support" once the standard support for 10.3 ends, to indicate that the only support coming is security fixes and there won't be any MFCs of enhancements or errata fixes.

It will be important to get developers on board with this. Right now, there are a few developers [you know who you are] that seem to delight in ripping out support for old versions within a few weeks of the version going out of support. Conversely, there are other developers who apparently feel "if it isn't a big problem, why not MFC". 9-STABLE still gets regular commits, 8-STABLE has had at least 5 commits in the last year, etc.
 
What I would like to see added is security-fix-only support for the last release of one major version (let's call it 10.3) until the .1 release of the next major version (11.1 in this case) has been out for 6 months.
FreeBSD 10 is a bit tricky as that still falls in the 'old' support scheme. But it's likely there's still support for at least one major version before the current one (not counting -CURRENT). So there will be, for example, 12.1 and 11.4 (just guessing the minor version) support at the same time. The 5 year starts counting after the last release of a major branch. Depending on how fast they're going to release new versions you may even see 11.4, 12.2 and 13.0 being supported.
 
This wariness is reinforced by the number of threads we see here with people reporting problems either going from 10.3 to 11.0 or once they are on 11.0.

It is always difficult to judge by these things, but I think there have been a lot of threads reporting situations that a professional or more skilled user would not encounter.

Being one of the ones who screwed up royally on going to 11.0, I've noted many of those threads. This is just anecdotal, but it seems that many of those were because of misunderstanding the process. It is pretty simple when you know, but there are at least two things which have caused that in many instances. One of them could be fixed with trivial effort.

One it that going from 10.1 to 11.0 requires an intermediate step. That makes sense, but it doesn't make sense that the process wouldn't either do it for you, or warn you to do it manually. It's a reasonable assumption for people to make and I think that the upgrade code should take into account some of the basic errors that a user might make. Another is that the handbook layout is poor when it comes to upgrading. If one is in a hurry and doesn't look carefully, one will miss the part where it says you have to reinstall all programs. It says that, but only much later on the page after a long section which is irrelevant to most people. I'm sure I'm not the only one who thought they were finished following the instructions and didn't discover that there was more important information far down on the page.
 
The 5 year starts counting after the last release of a major branch.

I thought it started with *.0-RELEASE? That would give roughly two years of support via binary updates, followed by roughly three years of support through the -STABLE branch (or just 5 straight years through the -STABLE branch) for those willing to use it. I thought the whole point was to give users a reasonably long support period and a predictable release schedule while also cutting down on the number of supported releases to alleviate the burden on the development team. It makes sense for users, since if they so chose they could just upgrade once every couple years to the last, well-tested minor release of each major version, and the development team could relax a bit.

Starting the countdown after the last minor release would result in an absolute minimum of 6.5-7 years of support for every major version, and since a new major version comes out every 1.5-2 years, we'd end up with four supported major versions at once. I could be looking at this from the wrong angle or misunderstanding something, but it seems like there wouldn't be any significant change...
 
Hi! After RedHat decided to make a big renovation between it's 6.x and 7.x major releases I started to investigate FreeBSD release cycle. 5 years of support for major version sounds promising but it's 2 days of reading and testing and I can't comprehend the idea of the new FreeBSD release model. The aim is to setup a system with 5 years ABI stability.

Starting point: https://www.freebsd.org/security/

"Effective FreeBSD 11.0-RELEASE, the support model has been changed ... Under the new support model, each major version's stable branch is explicitly supported for 5 years, while each individual point release is only supported for three months after the next point release."

That's great, but what does it mean? I guess if freebsd-version shows 11.0-RELEASE-p16 we are in the clear. Is it? No, I still get infamous '/lib/libz.so.6: version ZLIB_1.2.9 required by /usr/local/lib/libpng16.so.16 not found'. WTF? What have I missed? Evidently I have a point release. Then how to move to a STABLE branch? freebsd-update -r 11-STABLE upgrade? freebsd-update -r 11.0-STABLE upgrade? No, nothing like this exists on the mirror.

This link ( https://www.freebsd.org/doc/en/books/dev-model/release-branches.html ) doesn't explain to me should I consider -STABLE a line of minor releases in stable branch of just one release in the end of that series. Considering the doc is about 3rd release it's probably obsoleted anyway.

SirDice sujests 'The 5 year starts counting after the last release of a major branch'. That's fun, so I should wait for the last in the line to be released to get my ABI stability? Let's see when this is going to happen...

https://www.freebsd.org/security/
Code:
Branch          Release                   Type Release  Date                  Expected EoL
stable/11         n/a                       n/a     n/a                                    September 30, 2021
releng/11.1  11.1-RELEASE       n/a     July 26, 2017                  September 30, 2018

Ok, now it's stable vs releng and what all this n/a mean? How should I interpret this? If stable/11 has no release date it means it is not a release but a line of multiple releases. What about SirDice's suggestion? No, it can't be true otherwise stable/11 wouldn't end in 2021 or it should be present right now.

Now I have two systems:

one as a result of upgrade: 11.0-RELEASE-p16 and a fresh install 11.0-RELEASE-p1
in both cases pkg upgrade says all my packages are up to date.

What a mess...

Looks like FreeBSD (with binary packages) is just a short-term release like Fedora. Words about 5 year support are just words. As well I you can run Fedora, update it every 6 month and call it a 5 year support.
 
First: you're responding to a thread which has been idle for over a year. Might want to keep that in mind because with older threads there's no guarantee that participants are still active (there's also the issue that things could have changed drastically over time as well).

"Effective FreeBSD 11.0-RELEASE, the support model has been changed ... Under the new support model, each major version's stable branch is explicitly supported for 5 years, while each individual point release is only supported for three months after the next point release."

That's great, but what does it mean?
Just what it says. FreeBSD knows major versions (10, 11, 12) and minor versions / releases (10.4, 11.1, 11.2). A major release will be supported for 5 years whereas support for a minor release (or point release I suppose) heavily depends on the release of the next version. Support will only be valid for 3 months after that release date.

No, I still get infamous '/lib/libz.so.6: version ZLIB_1.2.9 required by /usr/local/lib/libpng16.so.16 not found'. WTF? What have I missed?
Impossible to comment on without any more context. You could have missed /usr/ports/UPDATING, you could have made the classic mistake of mixing ports ( # make install clean) and binary packages ( # pkg install), you could have decided not to upgrade your FreeBSD version and let its support expire (the ports collection is only build against supported releases) and of course you could also have made plenty of mistakes during the installation of graphics/png.

This issue is hardly as infamous as you try to make it sound:
Code:
peter@zefiris:/usr/local/lib $ ldd ./libpng16.so.16
./libpng16.so.16:
        libz.so.6 => /lib/libz.so.6 (0x80123b000)
        libm.so.5 => /lib/libm.so.5 (0x801453000)
        libc.so.7 => /lib/libc.so.7 (0x800823000)

Evidently I have a point release. Then how to move to a STABLE branch? freebsd-update -r 11-STABLE upgrade? freebsd-update -r 11.0-STABLE upgrade? No, nothing like this exists on the mirror.
And now you're making me wonder how much research you really did. Because it looks like you just skimmed over the whole lot.

Why would you want to use a STABLE branch in the first place? STABLE is a so called snapshot release, aka a developers version. It is less bleeding edge than CURRENT but even so it's still an experimental release which isn't officially supported. Developer snapshots are provided 'as is' and basically don't get any guarantees that they'll even run.

Major difference being that STABLE is, as mentioned, far less experimental and therefor even supported on these forums, but even so: if you're worried about support options then you really don't want STABLE. Stick with the production releases instead.

There's no mess here at all, the major issue is that with this material it's expected that users carefully read and also pay attention to the details.
 
Doesn't the thread goes up? Anyway, I repeate, the aim is to setup a system with 5 years ABI stability. What you say 'A major release will be supported for 5 years whereas support for a minor release (or point release I suppose) heavily depends on the release of the next version.' doesn't explain why library linkage is broken between minor releases. The same way you take Fedora and update it every half a year. What's the point if application compiled for a [minor] release is broken after update? I mentioned RHEL because it allows exactly that: compile your app for minor release and then run it till the EoF without problem. This is what I call 'support' and 'abi stability'.

https://access.redhat.com/articles/rhel-abi-compatibility
 
Anyway, I repeate, the aim is to setup a system with 5 years ABI stability.
Then you don't want developer snapshots, but stick with RELEASE.

What you say 'A major release will be supported for 5 years whereas support for a minor release (or point release I suppose) heavily depends on the release of the next version.' doesn't explain why library linkage is broken between minor releases.
It isn't.

Most likely this is the result of an improper upgrade, but as I mentioned above there's hardly enough information to comment on it in detail.
 
Yeah, I find that confusing. What should you use if you're running a production server, 11.0-RELEASE? I do wish they'd be a bit more explicit. One is usually advised to upgrade, but if you're in production, and upgrade to 11.1, then 11.2 comes out, breaks things, including VirtualBox, which may be used in production. (If it's used for graphic editing, NVidia, another broken package may also be used.)


May be similar to RedHat/CentOS, you accept the tradeoff of older packages and systems for stability.
You definitely don't want to move to STABLE. See Fred Cash's explanation, which, while written for 4x, 5x, and 6x releases is still valid. http://srobb.net/release.html
 
Then you don't want developer snapshots, but stick with RELEASE.

But I am! You can see it from my post. And I don't use ports cause I understand the implication. No, the linkage for package is broken just because I'm on 11.0 which is now obsoleted.
 
May be similar to RedHat/CentOS, you accept the tradeoff of older packages and systems for stability.

I surely accept this trade-offs in my case. Cause we have our own repo with very new versions of whatever we need. And breaking of a library interface between minor (sic!) updates is a no-go.
 
See Fred Cash's explanation, which, while written for 4x, 5x, and 6x releases is still valid. http://srobb.net/release.html

I think in 2018 we have the opposite situation.
"-STABLE refers to the programming API/ABI used by the kernel and base applications and libraries. IOW, developers can write applications and drivers for 6.0 and that same binary and driver will work on 6.9 " - this is actually what i needed but can't get with a new FreeBSD release model.

"This is contrary to the Linux world, where "stable" means stable running code and not stable programming APIs/ABIs " - which is untrue in my case cause RHEL gave me just that. Though their new initiative "make a new base, change everything" breaks things again.
 
Code:
peter@zefiris:/usr/local/lib $ ldd ./libpng16.so.16
./libpng16.so.16:
        libz.so.6 => /lib/libz.so.6 (0x80123b000)
        libm.so.5 => /lib/libm.so.5 (0x801453000)
        libc.so.7 => /lib/libc.so.7 (0x800823000)

Code:
freebsd ~ # strings /usr/local/lib/libpng.so |grep ZLIB
ZLIB_1.2.9
ZLIB_1.2.4.0
freebsd ~ # strings /lib/libz.so.6 |grep ZLIB
ZLIB_1.2.4.0
ZLIBprivate_1.0
ZLIB_1.2.7.0
ZLIB_1.2.7.1

As you see libpng has higher requirements then base system provides...
 
... and that how it looks after a minor (!) update 11.0->11.2

Code:
[root@freebsd2 ~]# strings /lib/libz.so.6 |grep ZLIB
ZLIB_1.2.4.0
ZLIBprivate_1.0
ZLIB_1.2.7.0
ZLIB_1.2.7.1
ZLIB_1.2.9
 
Not to mention the problem that LTS doesn't solve anything, it only postpones the inevitable. Sooner (in that case later) you are going to have to perform that upgrade and when you do (and you have no other alternatives left) then things can become quite messy when you're effectively upgrading between three or four major releases.

The time and alleged money you "safe" by using LTS can then easily get burned up, and more.

A faster release cycle can also have it's hiatus, but it is something you can anticipate for, and with a bit of proper planning and testing things don't have to be that problematic.

Of course many want less effort and not having to deal with their OS too much if possible. But for a server that's usually not a viable option.
 
I think in 2018 we have the opposite situation.
"-STABLE refers to the programming API/ABI used by the kernel and base applications and libraries. IOW, developers can write applications and drivers for 6.0 and that same binary and driver will work on 6.9 " - this is actually what i needed but can't get with a new FreeBSD release model.
I think there's a bunch of confusion here. Let me see if I can explain some things:

1) A "major version" of FreeBSD is supported for a minimum of 5 years from the release of the x.0 version. So FreeBSD 11 is supported for 5 years. That doesn't mean you can install 11.0 and expect support for 11.0 for the whole 5 years. First, you need to keep up with security patches (the -p# in the release name). After 11.1 comes out, you have 3 months to update your system before 11.0 becomes unsupported. You get to 11.1 via the same method you installed the -p# patches (there are a variety of methods, freebsd-update is the one normally suggested for end users).

2) There is a difference between FreeBSD "base" (what the developers are 100% responsible for [more or less - contrib and some other parts are special cases]) and "ports" (which are adaptations of other software, for example net/samba48). Ports have a defined maintainer in the FreeBSD development environment, but that maintainer is just responsible for keeping the port up-to-date with "upstream" and dealing with any bug reports that seem to be FreeBSD-specific. There are a number of different ways to update your installed ports, and again you need to stick with one method.

3) There is no guarantee that new installs of ports (pulling pre-built binaries from a FreeBSD distribution server) will work properly on anything but the latest release of a particular version. That is another reason to keep your base system up-to-date (see item 1 above).

4) Mix-and-match definitely does not work. You use freebsd-update, build from source, or some other method to keep "base" updated. You either use packages (pre-built binaries) for "ports", or you build from source. You use one of the 2 methods to keep your ports updated if you build from source - portmaster or portupgrade. You cannot start with one method and then change to the other, unless you are an expert and understand the steps you need to take to handle the conversion (and any ensuing fallout).

5) The issue you seem to have is an installation of a new port (from packages) on an unsupported release. Remember, you have 3 months after the next "dot" release comes out to update your system. Refer to https://www.freebsd.org/releases/ for supported and unsupported releases. It is likely that if you built the port from source, it would not give you this error. However, see the previous item about not mixing and matching methods of installing / updating ports.

6) The FreeBSD ABI is quite stable and upwardly compatible on any given major version. Note that I said upwardly compatible - a program built on 11.0 should run on 11.2 without any problems, but a program built on 11.2 may or may not run on 11.0. I think this is what you ran into with your port. Additionally, the ABI is compatible with most programs compiled under [much] older FreeBSD versions. The kernel part of this is controlled by the "COMPAT_FREEBSDx" build options (default on). This provides backward compatibility with specific older versions of FreeBSD (except for COMPAT_FREEBSD32, which is for 32-bit support on 64-bit systems). The library part of this is handled by various ports - for example, misc/compat10x for compatibility with user binaries from FreeBSD 10. I just checked and I can run a (non-trivial - 500K source lines) binary compiled on FreeBSD 6.3 i386 on FreeBSD 11.2 amd64.
 
Back
Top