Attempted to upgrade to 14.2-RELEASE today

I am now on VM and will upgrade first, rebuild the drm port after first install and reboot.
How to know that packages has started to build for 14.2-RELEASE or wait for few weeks.
 
gnath said:
I am now on VM and will upgrade first, rebuild the drm port after first install and reboot.
How to know that packages has started to build for 14.2-RELEASE or wait for few weeks.
Click to expand...
According to this, 14.1 is EoL 31 March 2025, so I would expect quarterly package builds using 14.2 in second quarter 2025. I could be wrong, but it makes sense to me.

www.freebsd.org

FreeBSD Security Information

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org
 
mer said:
According to this, 14.1 is EoL 31 March 2025, so I would expect quarterly package builds using 14.2 in second quarter 2025. I could be wrong, but it makes sense to me.

www.freebsd.org

FreeBSD Security Information

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org
Click to expand...
And this is the reason why I decided to not upgrade my working version of FreeBSD because I use binary packages I do do not want to start using ports again.
 
fernandel said:
And this is the reason why I decided to not upgrade my working version of FreeBSD because I use binary packages I do do not want to start using ports again.
Click to expand...
Well, it's just one package, maybe two if you use Virtualbox... It's not that you have to rebuild hundreds of them...
 
fernandel fmc000 Valid points. I've always been of the opinion "Upgrading/updating is a good thing at least for security updates, but you should evaluate the CVEs, decide if you can mitigate or put them off for a little bit"
In this case, delaying may not be a bad thing, it will let everyone else find the bugs :)
 
fernandel said:
And this is the reason why I decided to not upgrade my working version of FreeBSD because I use binary packages I do do not want to start using ports again.
Click to expand...

I'm looking into ways to handle this on my set-ups:
  • Would using CURRENT avoid linuxkpi or other pkg kernel modules mismatching?
  • If I enable src/ports during RELEASE install, can I just use and update only i915kms/necessary parts from src/ports and keep everything else pkg?
  • If I build i915kms (or any kernel modules) from src/ports, would that forever avoid the kernel mismatch possibility?
 
Espionage724 said:
I'm looking into ways to handle this on my set-ups:
  • Would using CURRENT avoid linuxkpi or other pkg kernel modules mismatching?
  • If I enable src/ports during RELEASE install, can I just use and update only i915kms/necessary parts from src/ports and keep everything else pkg?
  • If I build i915kms (or any kernel modules) from src/ports, would that forever avoid the kernel mismatch possibility?
Click to expand...
My understanding:
CURRENT: probably not. I'd guess that using CURRENT could lead to more mismatching in modules
One can build from source (ports) for a package and lock it down (I'm not sure of the exact commands) and use prebuilt binaries for everything else. the i915kms comes from drm-kmod which I think nothing else depends on (I think called a leaf port)
"forever avoid" only until you install a new kernel.

If you look at it right now, if you freebsd-update to 14.2-RELEASE you will need to rebuild from source/ports drm-kmod against that untilat least 31 Mar 2025 (EoL of 14.1-RELEASE). If there are -p level updates to 14.2 between now and 31Mar2025, you should not need to rebuild drm-kmod UNLESS there is a kernel update. A kernel update MAY trigger a rebuild.

To build from ports you need up to date kernel source and up to date ports tree. Ports tree you need to be careful WRT quarterly and latest.
 
mer said:
Ports tree you need to be careful WRT quarterly and latest.
Click to expand...
Can you clarify this a bit more?

I git pulled src releng/14.2, and did ports main (figured src would be better to target the FreeBSD version running and Ports being general software that could benefit from main/latest changes). I did that post-install without selecting ports/src at install (I'd like the branches/set-up to be like what the install option would do but for future installs I'll probably select the ports/src option)

That seemingly worked fine to compile drm-61-kmod and VirtualBox's kmod on 14.2-R.
 
mer said:
A kernel update MAY trigger a rebuild.
Click to expand...

Is there a way to force that? On Fedora with NVIDIA's kmod, it compiled through akmods which iirc was some kind of automated hook somewhere (dnf or specifically with kernel updates). Basically the kernel would update, then do akmods --force somewhere (I think automatic on next-boot (with black screen/tty) if it didn't build during the GUI update session, but I covered with akmods --force usually before rebooting)

On FreeBSD currently I do freebsd-update fetch install, pkg update, but don't have anything for drm-61-kmod (the plan is to just force a make reinstall clean if I happen to see a kernel update or end up at tty on a boot :p)
 
xibo said:
If a CVE affecting 14.2-RC1 is published today and releng@ pulls a hotfix into 14.2-RELEASE, rerolling the 14.2-RELEASE files before announcing 14.2-RELEASE, the un-announced pseudo-release never existed, and while both are officially unsupported, I'd rather put my bets on RC1 to seaminglessly upgrade to RELEASE than into unanounced-pseudorelease that identifies itself as RELEASE to seaminglessly upgrade to RELEASE.
Click to expand...
I agree in choosing 14.2-RC1 over the "un-announced pseudo-release". However, the RC-s and even the BETA-s are supported*, although in a limited fashion. On rare occasions, they may even receive patches; however, given the short life span of these pre-release versions, in practice these and other improvements will be incorporated in an immediate successor, that is: the next BETA or RC, or ultimately its intended targeted -RELEASE version.

FreeBSD Security Information - Supported FreeBSD releases:
In the run-up to a release, a number of -BETA and -RC releases may be published for testing purposes. These releases are only supported for a few weeks, as resources permit, and will not be listed as supported on this page. Users are strongly discouraged from running these releases on production systems.
Click to expand...

___
* This emphasizes that pre-release versions are of imminent importance in the successful delivery of its targeted release version, and in establishing its production quality.
 
fmc000 said:
Well, it's just one package, maybe two if you use Virtualbox... It's not that you have to rebuild hundreds of them...
Click to expand...
Okay it is one package. What if I have a problem to build it? After installed new kernel you need to reboot and you are in problem because you have driver build on 14.1? Should be kld_list=bla bla in/etc/rc.conf disabled? But in instruction is not mention or I didn't saw. But anyway my 14.1 works good.
 
You must log in or register to reply here.
Back
Top