Attempted to upgrade to 14.2-RELEASE today

I attempted to upgrade to 14.2-RELEASE as my system informed me there was an update:

curl -s https://download.freebsd.org/releases/amd64/ | awk '{print $3}' | grep RELEASE | tr -d '"' | tr -d '/' | cut -f2 -d'=' | sort | tail -1

However, I had to revert because even after updating, my system still was showing 14.1-RELEASE-p6. I performed an upgrade, restarted, then ran install, rebooted, and ran install again. I have a custom kernel, but did not rebuild that yet, but shouldn't uname -r show the operating system version, not necessarily the kernel?

Lastly, I see there was no formal announcement, so my script may need some tweaking as perhaps the release isn't quite ready yet and I did an upgrade prematurely. Thankfully I was able to easily revert to the old BE without breaking a sweat, but I could have been in a pickle.
 
Did you follow the correct procedure?

Code:
# user root
# Now the freebsd-update(8) utility can fetch bits belonging to 14.2-RELEASE.
# During this process freebsd-update(8) will ask for help in merging configuration files.

freebsd-update upgrade -r 14.2-RELEASE
freebsd-update install

# The system must now be rebooted with the newly installed kernel before the non-kernel components are updated.

shutdown -r now

# After rebooting, freebsd-update(8) needs to be run again to install the new userland components:

freebsd-update install

# At this point, users of systems being upgraded from earlier FreeBSD releases will be prompted
# by freebsd-update(8) to rebuild or reinstall all third-party applications (e.g., ports installed
# from the ports tree or packages installed by pkg(8)) due to updates in system libraries.

# After updating installed third-party applications (and again, only if freebsd-update(8) printed
# a message indicating that this was necessary), run freebsd-update(8) again so that it can delete
# the old (no longer used) system libraries:

freebsd-update install

# Finally, reboot into 14.2-RELEASE

shutdown -r now

I followed this procedure and it worked perfectly. After that I updated the bootloader, as advised at boot time:

Code:
# user: root
# Mount the efi partition, it's probably already in fstab and getting mounted on /boot/efi. But if you have multiple disks you will have to mount each individual disk separately.
# Do this on the running system, preferably before or right after the zpool upgrade command to upgrade the pools. Or update the boot code right after an update/upgrade of the OS.

cp /boot/loader.efi /boot/efi/efi/freebsd/loader.efi
cp /boot/loader.efi /boot/efi/efi/boot/bootx64.efi

and as the last step I rebuilt the vboxdrv kernel module:

Code:
cd /usr/ports/emulators/virtualbox-ose-kmod
make reinstall clean

All perfectly working at the first try.
 
Oh, you're right, -r is for the kernel.

Hmm, okay, since I have a custom kernel, then I think the first step is for me to rebuild the kernel, reboot, then continue with updating everything else?
 
A new -RELEASE version is official when it has been announced, like FreeBSD 14.1-RELEASE Announcement, and FreeBSD *14.1*-RELEASE Now Available in the freebsd-announce mailinglist.

Perhaps for 14.2-RELEASE, try detecting the correct presence of https://www.freebsd.org/releases/14.2R/announce.asc

Especially when using a custom kernel with all the extra steps of recreating that custom kernel, it seems efficient, and prudent, to wait until all binaries (all over the world) have been synchronised and officially sanctioned, if you are using the binary upgrade path (partly) anyway. Likewise if you'd choose to fully upgrade via source.
 
And even after official announcements, some of the officia mirrors in the world could tame some more time to properly sync with master.

If you cannot find upgrade you want, be patient for some more time, depending on the nearest mirror you're connected to by load balancer to be sync'ed.
 
Why not install 14.2-RC1 if you're in a hurry to get 14.2? It's so far identical to the "14.2-RELEASE" you have spotted, but unlike the "release", RC1 has formally been published by releng@ .

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.
 
If a CVE on 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.
Has something like this ever been a problem with a previous FreeBSD release?
 
Has something like this ever been a problem with a previous FreeBSD release?
Most FreeBSD releases so far had more RCs then innitialy intended, as blocking issues were discovered during the RC phase. Some of them had CVEs grade, too, such as SA-12-06 which was filed against 9.1-RC2.

Finding release blocking bugs is the purpose of the RC phase ;)
 
I was wondering what I missed here, as I updated a machine yesterday to 14.1 and I remember checking what the latest release was.

It is using ZFS on root setup, and no issues.
 
Yup, I reran my installer and don't have video upon installing on a spare system. I need to debug what is going on with i915kms :(.
 
I think I sorted it:

pkg remove drm-61-kmod
pkg install drm-515-kmod
 
Did anyone get the upgrade to install in a non-interactive way? My workarounds seem to fail, as in freebsd-update hangs on a prompt:

Code:
root@Z800:~ # export PAGER=cat; chroot /mnt/be_updated freebsd-update --not-running-from-cron -b / -r 14.2-RELEASE upgrade
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.1-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic kernel/generic-dbg world/base world/lib32

The following components of FreeBSD do not seem to be installed:
world/base-dbg world/lib32-dbg

Does this look reasonable (y/n)?

This worked for previous upgrades.
 
Normally, yes. This time, no, I had to revert Boot Environments. I have a custom kernel and there was still some sort of mismatch between the kernel and the OS. Since my main drive appears to be dying, I figured it'd be best to use another drive.

For me, it takes about an hour to rebuild my system and have it back in the same state it was. I maintain git repositories with my system configuration, so it gets applied automatically like ansible. I have a few identical boxes, so the upgrade process for me looks like running the FreeBSD installer, rebooting to create a BE, then making the system live and see what fails. In this case, I had to tweak the i915 / drm stuff. If that looks good, then I either swap the whole box, or just move the drive to the main box. My main box has an extra NIC for routing purposes, but otherwise, they're identical.
 
Upgraded from working system to 14.2-RELEASE few days back. Everything went well up to first install. On reboot the system hangs on after line
Code:
iic3 (12C generic I/O) on iicbus3
Next attempts failed also. Rollback ,upgrade and again reboot with same results on my Dell Latitude 3400. Now I am on 14.1-RELEASE-p5. Reported a bug. Help me if I have any wrong, as never happened like this.
 
Upgraded from working system to 14.2-RELEASE few days back. Everything went well up to first install. On reboot the system hangs on after line
Code:
iic3 (12C generic I/O) on iicbus3
Next attempts failed also. Rollback ,upgrade and again reboot with same results on my Dell Latitude 3400. Now I am on 14.1-RELEASE-p5. Reported a bug. Help me if I have any wrong, as never happened like this.
rebuild the graphics/drm-61-kmod will fix your issue.
 
You were asked to rebuild the packages, not to install them.


  • drm-kmod packages compiled on FreeBSD 14.1 result in the text console being inoperative when the kernel module is loaded. Recompiling the package from the ports tree will restore the lost functionality. This issue will also resolve itself after the FreeBSD 14.1 EoL, when packages for 14-STABLE will start being built on FreeBSD 14.2-RELEASE.
 
This is one place where use of ZFS and Boot Environments can be very helpful:

Manually create a new BE and through the use of chroot (flags are available on the freebsd-update and pkg commands), one can do the system update, pkg upgrade everything and with a bit of work rebuild drm-kmod as needed. All in the new BE. Once the new BE is complete, bectl activate to activate it for the next boot and then reboot.

I typically do this when going across releases, it makes it easier for me to remember things, it makes sure I have a consistent BE for the new release before rebooting.

If you don't want to try and rebuild drm-kmod in the new chroot BE, simply edit the rc.conf in the new BE to remove i915kms. Then it's simple "update your source trees and rebuild/install as normal".

That leaves you with a working RELEASE-14.1 as a fallback and a new RELEASE-14.2 to test and verify.
 
Back
Top