Solved Jump releases

J

jbo@

Developer
I have a stray system still running 12.2. Is it possible/recommended to upgrade directly to 13.1 or should I first upgrade it to 12.3 and then to 13.1?
 
12.3 was released a few months after 13.0. If you want to be extra careful you can do 12.2 to 13.0 to 13.1 but not 12.2 to 12.3 to 13.1 as this latter upgrade path is likely not tested. But I’d just go straight from 12.2 to 13.1.
 
If that stray system is running ZFS for the root filesystem, jump straight into 13.10-RELEASE in a new BE. Safest, best way to do an upgrade (my opinion).

Even if not, I think you should be ok, just remember to pkg upgrade -f because things like drm kmods will have changed.
 
Do you use boot environments? Then just give it a shot 😏 There's very little that can go wrong, but upgrades from an unsupported release are most likely not tested.
bakul said:
12.3 was released a few months after 13.0.
Click to expand...
This however isn't relevant. Upgrades inside the same major version are always supported and tested (12.2 -> 12.3), as well as upgrades from one to another supported version are (12.3 -> 13.1).
 
Jup, this is running ZFS and BEs are "available".
I certainly plan to make use of BEs but I if there's something I need (or simply can) know upfront I'd certainly prefer to know that know rather than later :)

mer said:
Even if not, I think you should be ok, just remember to pkg upgrade -f because things like drm kmods will have changed.
Click to expand...
This is a small server so nothing fancy. Certainly no DRM. Mainly just running sysutils/cbsd to dick around. Nothing production so if it breaks down it's not a disaster. But that doesn't prevent me from wanting to do things properly ;)

Thanks for the info guys - I'll give this a try once poudriere is done with building 13.1-RELEASE packages.
 
  • Like
Reactions: mer
A boot environment will allow you undo an upgrade but that is usually not what you want. If something goes wrong, reverting to whatever was running is the last thing you’d want to do. You don’t want to remain frozen on a release that will get older and older and make upgrades harder and harder over time. Having an older snapshot is useful for comparison but you’d want to bite the bullet and fix whatever is broken as part of the upgrade. Probably obvious to most of you, just spelling it out!
 
bakul, the advantage of a BE is that you can just go for it, even if you're not 100% sure your approach will work, because you have a 100% reliable rollback strategy. Of course, if plan A fails, you'll try plan B next.
 
BEs greatest advantage is when you are trying something risky, like building a new kernel that may crash. I see a FreeBSD upgrade as more or less a required step. Different use cases. Note that freebsd-update already has a rollback sub-command. So I see BE as simply providing another (& faster) comforting safety net that might give some people more courage :)
 
bakul said:
BEs greatest advantage is when you are trying something risky, l
Click to expand...
I would argue that by definition any upgrade is "risky". :) (see every Windows upgrade since day 0 that has a greater than 0% probability of making your system unbootable)

BEs, especially if you follow some the tutorials/instructions here, give you a nice clean way of doing an upgrade and if the upgrade doesn't work, a simple way to rollback.
basically:
system is running version x.y.z with the latest release packages for it from quarterly
create new BE, and chroot to it.
Inside the new BE, upgrade to whatever version a.b.c you want, inside that BE upgrade all your packages to correspond to version a.b.c.
reboot into new BE and test

If the new BE doesn't boot or something critical doesn't work, reboot into the previous BE and you are up and running.

Now when you create and update into a new BE is up to you. Do you need to for every patch on a release branch? Probably not, but your comfort level drives this. I typically create new BE to upgrade into on major releases, like going from 12.x to 13.0, then 13.0 to 13.1. I know folks that create new BEs for every time they upgrade packages.

Circling back to the OP:
If it's ZFS, I'd just create a new BE and update that to 13.1-RELEASE. The boot code from 12 should be able to boot the ZFS root stuff since you really haven't changed any of that. Be aware that once booted into 13.x if you do a zpool upgrade you should update the bootcode and you may have issues with those pools back in 12.x (13.0 was the switch to OpenZFS, 12.x has the older FreeBSD/Illumos ZFS)
 
This is the procedure I used last time, it's on one of the threads here.
But "why chroot"? Because most of the tools assume you are rooted at the base of your tree.
But some commands allow a "destination" directory so you don't need a chroot.
vermaden has a nice tutorial for upgrading into a BE across releases.

NOTE: gpart bootcode needs to be done on all boot devices, obviously if it's UEFI boot, you need to do something different. The -c on pkg-static does a chroot, so you need to do the mount of devfs command before it. bectl create 13.1-RELEASE bectl mount 13.1-RELEASE /mnt freebsd-update upgrade -b /mnt -d /mnt/var/db/freebsd-update -r 13.1-RELEASE freebsd-update -b /mnt -d /mnt/var/db/freebsd-update install freebsd-update -b /mnt -d /mnt/var/db/freebsd-update install freebsd-update -b /mnt -d /mnt/var/db/freebsd-update install # yes run three times gpart bootcode -b /mnt/boot/pmbr -p /mnt/boot/gptzfsboot -i 1 ada0 mount -t devfs devfs /mnt/dev # pkg needs devfs mounted pkg-static -c /mnt upgrade -f umount /mnt/dev bectl umount 13.1-RELEASE bectl activate 13.1-RELEASE shutdown -r now # only one reboot! bectl destroy -o 13.0-RELEASE
 
bakul said:
– not 12.2 to 12.3 to 13.1 …
Click to expand...

Please see the most recent documentation from the Primary Release Engineering Team.

Via <https://www.freebsd.org/releases/12.3R/> (for a supported RELEASE):

www.freebsd.org

FreeBSD 12.3-RELEASE Installation Instructions

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org

<https://www.freebsd.org/releases/12.3R/installation/#upgrade-binary> there's the upgrade path from 12.2 to 12.3.

Via <https://www.freebsd.org/releases/13.1R/> (for a supported RELEASE):

www.freebsd.org

FreeBSD 13.1-RELEASE Installation Instructions

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org

<https://www.freebsd.org/releases/13.1R/installation/#upgrade-binary> there's the upgrade path from 12.3 to 13.1.

… I’d just go straight from 12.2 to 13.1. …
Click to expand...

No mention of 12.2 in the installation instructions.
 
Oh, BEs are flexible. You can create a new one which will be a snapshot-clone of your current system, not touch it but just upgrade as usual, and in "case of fire", switch over to the "new" one holding the old system.

I think it makes more sense to upgrade the new BE and just throw it away if it doesn't work. One way to do it is chroot(8). But it isn't strictly necessary, freebsd-update(8) knows the -b option, just like you can use DESTDIR with make install[world|kernel], to do the upgrade in some BE mounted somewhere.
 
A simpler option is to create a new BE, activate and reboot. Now you are running under the new BE. And then do the install.

One thing to do *before* you do any of this is to check the size of the EFI partition (using gpart). Make sure it is at least 100MB.
 
grahamperrin said:
Can you upgrade packages whilst changed and then find the log, post-exit?
Click to expand...
I think the method I posted which does a pkg-static -c may do the right thing. I've not checked because I've honestly not cared to check.

The -c does a chroot, but because you are not running it from within a chroot, it should push logs and other data to the currently mounted /var (or where it needs to).
The chroot as shown by vermaden is doing a chroot to the new BE and then running the pkg command within that, so the /var may be different.
 
  • Like
Reactions: mer
bakul said:
A simpler option is to create a new BE, activate and reboot. Now you are running under the new BE. And then do the install.
Click to expand...
Simpler yes. But then you need to reboot again after completing the upgrade to run the upgraded system. The other methods allow you to upgrade the system and reboot once to wind up in the upgrade.
But "sixes and threes" "horses for courses" "your system your choice". It all works.
 
bakul said:
A simpler option is to create a new BE, activate and reboot. Now you are running under the new BE. And then do the install.
Click to expand...
That will work as well. But it will sacrifice an often overlooked advantage of BEs: You can do a full upgrade of everything with just one single reboot :cool:

-- mer, hands, but you were slightly quicker 😀
 
mer said:
… I've not checked … The -c does a chroot, but because you are not running it from within a chroot, it should push logs and other data to the currently mounted /var (or …
Click to expand...

forums.freebsd.org

bectl(8), chroot(8) and pkg-install(8)

Below, no record of installation in /var/log/messages root@mowa219-gjp4-8570p:~ # bectl create example && bectl mount example /tmp/up Successfully mounted example at /tmp/up root@mowa219-gjp4-8570p:~ # chroot /tmp/up root@mowa219-gjp4-8570p:/ # pkg install -r FreeBSD networkmgr Updating FreeBSD...
forums.freebsd.org forums.freebsd.org

I can't find a record with things here being so scattered :-( but I'm almost certain that I have tested -c more than once.
 
bakul said:
Exactly! But to some (including me) one more reboot may be preferable to fat fingering something!
Click to expand...
I've done both methods. They both work fine. The key is pick a process and stick with it. It doesn't matter what anyone else says; in the end the goal is a correctly upgraded system and happy users. I like a single reboot because it only affects me. If it were @WORK I'd do two reboots just to have extra cup of coffee.

grahamperrin Yes I recall all of that, but the steps I posted in this thread are a little different. They don't create the new BE, mount it, chroot into it then upgrade. It creates the new BE, mounts it and then does the freebsd-upgrade command is using the -b and -d arguments to do the upgrade. The pkg-static command uses the -c to "change to this directory before running the upgrade" similar to a make -C. That is different from a chroot to the new BE.
I'll concede you may still wind up missing the information you are looking for because I've not looked for it because of "not caring very much".

jbodenmann Sorry if we've hijacked a little bit.
 
You must log in or register to reply here.
Back
Top