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.
 
tingo said:
FWIW, this is what I do when I upgrade machines that have kernel modules (mostly intel or amd gfx) loaded. I disable the kld_list before rebooting, finish the install, build the new kernel module (remember to update the ports tree), test it out manually and then enable the kld_list again.
Click to expand...
This sounds like a great idea.

It would be great if that logic could be incorporated into the update process so that it would be more seamless for the end user. Couldn't that be done programmatically? The user could also be informed about the process.
 
tingo said:
FWIW, this is what I do when I upgrade machines that have kernel modules (mostly intel or amd gfx) loaded. I disable the kld_list before rebooting, finish the install, build the new kernel module (remember to update the ports tree), test it out manually and then enable the kld_list again.
Click to expand...
I am doing this all the time but should be as @tOsYZYny wrote
 
tingo said:
How? Remember, the update process of freebsd-update only handles the operating system, not the packages.
And # pkg upgrade only uses packages, not ports.
Click to expand...
Special handling of fragile kmod pkgs should be needed not to make computers unoperable without serial console or spare computers to ssh to the computer with black screen.

Not sure but if pkgbase become default for upcoming 15.0, upgrade to 15.0 or later should use pkg, too, possibly on separated repo.
Maybe pkg upgrade for base, then re-bootstrap pkg itself, etcupdate, then other pkgs. (With some intermediate reboots.)

I want fragile (too strongly depend on kernel or in-tree kmods like [nvidia-]drm-[510|515|61]-kmod) be in base pkg repo per-point-releases.
 
tOsYZYny said:
This sounds like a great idea.

It would be great if that logic could be incorporated into the update process so that it would be more seamless for the end user. Couldn't that be done programmatically? The user could also be informed about the process.
Click to expand...

This also breaks down when loading an outdated kmod causes a panic. Your program to manage that loses control in that case.
 
  • Like
Reactions: mer
cracauer@ said:
This also breaks down when loading an outdated kmod causes a panic. Your program to manage that loses control in that case.
Click to expand...
Yes, that is presently a bug with my current implementation. The user would reboot back into the earlier BE where it detects the same upgrade, so it creates another BE and prompts the user to reboot again, thus introducing a cycle. The user would still be involved as I am today. In that case, it needs to check if there were other BE created. It already checks if there were other unapplied patches. Perhaps it can write additional metadata to the patch file indicating whether it was successful or not. It simply records that it was applied, but failures are a gray area presently.

Today, what I do is:

1. periodic job runs nightly checking for updates (freebsd, packages, kernel), creates a new BE and activates it, then writes what needs patched to a patch file with a name matching the BE, and prompts the user to reboot to apply patch for freebsd, packages, or kernel updates ... (note that 1 update is applied at a time to isolate issues)
2. the user sees the prompt and chooses to reboot
3. system reboots, job runs @reboot applying the necessary updates and checks for further updates, process repeats

The user will be in the loop for the foreseeable future for choosing to apply the patch. This could change as long as the location where the patch is written is separate from the Boot Environments so that history is persistent even after rolling back a BE.
 
You must log in or register to reply here.
Back
Top