Possible to upgrade from ALPHA?

D

dison4linux

I've done my best to search for the answer to this question, but now its come time to just ask.

Is it possible to upgrade from ALPHA (-> BETA, -> RC) -> RELEASE ?

I've got 11.0-ALPHA4 running right now and freebsd-update just says it can't find any mirrors to work with. One would assume that is simply because the mirrors haven't yet been populated in the way that they will be after 11.0 reaches RELEASE.

So my question is, when the BETAs (& RCs) and finally RELEASE comes out, will there be a way to do a binary upgrade to get there, or is starting from ALPHA a dead end unless one tracks a development branch.
 
Hey,
Sorry to resurrect this old post, but I'm also interesting in doing this and it showed up in searches, so I guess an update could be appropriate

I found those links:

So as far as I understand, it's now possible right?
Anything to consider before doing this, or is just expect to work ™️ as for other types of releases?

Thanks!
 
OK so I gave it a go, but for my case it's not as straight forward as I would have liked:
root@xxx:~ # freebsd-version
14.0-ALPHA3
root@xxx:~ # freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching public key from update2.freebsd.org... failed.
Fetching public key from update1.freebsd.org... failed.
Fetching public key from dualstack.aws.update.freebsd.org... failed.
No mirrors remaining, giving up.

This may be because upgrading from this platform (amd64)
or release (14.0-ALPHA3) is unsupported by freebsd-update. Only
platforms with Tier 1 support can be upgraded by freebsd-update.
See https://www.freebsd.org/platforms/ for more info.

If unsupported, FreeBSD must be upgraded by source.

root@xxx:~ # freebsd-update upgrade --currently-running 14.0-ALPHA3 -r 14.0-RELEASE
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching public key from update1.freebsd.org... failed.
Fetching public key from update2.freebsd.org... failed.
Fetching public key from dualstack.aws.update.freebsd.org... failed.
No mirrors remaining, giving up.

This may be because upgrading from this platform (amd64)
or release (14.0-ALPHA3) is unsupported by freebsd-update. Only
platforms with Tier 1 support can be upgraded by freebsd-update.
See https://www.freebsd.org/platforms/ for more info.

If unsupported, FreeBSD must be upgraded by source.

root@xxx:~ # freebsd-update -v debug upgrade -r 14.0-RELEASE
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching public key from update1.freebsd.org... fetch: http://update1.freebsd.org/14.0-ALPHA3/amd64/pub.ssl: Not Found
failed.
Fetching public key from update2.freebsd.org... fetch: http://update2.freebsd.org/14.0-ALPHA3/amd64/pub.ssl: Not Found
failed.
Fetching public key from dualstack.aws.update.freebsd.org... fetch: http://dualstack.aws.update.freebsd.org/14.0-ALPHA3/amd64/pub.ssl: Not Found
failed.
No mirrors remaining, giving up.

This may be because upgrading from this platform (amd64)
or release (14.0-ALPHA3) is unsupported by freebsd-update. Only
platforms with Tier 1 support can be upgraded by freebsd-update.
See https://www.freebsd.org/platforms/ for more info.

If unsupported, FreeBSD must be upgraded by source.
Click to expand...

So there is apparently nothing on the freebsd-update servers for 14-ALPHA3.
Then while looking around I saw this interesting suggestion: https://forums.freebsd.org/threads/freebsd-update-fetch-fetching-public-key-failed.1280/#post-7950
Thus I tried this:
root@xxx:~ # env UNAME_r=14.0-RELEASE freebsd-update -v debug fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
pub.ssl 800 B 14 MBps 00s
done.
Fetching metadata signature for 14.0-RELEASE from update2.freebsd.org...
latest.ssl 512 B 9 MBps 00s
The command rsautl was deprecated in version 3.0. Use 'pkeyutl' instead.
done.
Fetching metadata index...
b89ca988bdcae5cd783a4d4206d2b019af727ee2b20d49 225 B 4388 kBps 00s
done.
Fetching 2 metadata files...
/usr/libexec/phttpget update2.freebsd.org 14.0-RELEASE/amd64/m/1ac7a980345e7c878ade17a001dd24bd45770cd4bd05fb26e3fac27f53ea16c2.gz 14.0-RELEASE/amd64/m/e63e1d3ad9524
f7e820798743fc7c0470319edd680e84e296504713a957c3a9f.gz
http://update2.freebsd.org/14.0-REL...a001dd24bd45770cd4bd05fb26e3fac27f53ea16c2.gz: 200 OK
http://update2.freebsd.org/14.0-REL...743fc7c0470319edd680e84e296504713a957c3a9f.gz: 200 OK
done.
Inspecting system... done.
Preparing to download files... done.
Fetching 105 patches...
(...)
http://update2.freebsd.org/14.0-REL...0dc9b8d96386dd194f813c1ebace5fcd3e130d96d9.gz: 200 OK
done.
The following files are affected by updates. No changes have
been downloaded, however, because the files have been modified
locally:
/var/db/mergemaster.mtree
The following files will be updated as part of updating to
14.0-RELEASE-p7:
/bin/df
/bin/freebsd-version
/bin/mv
/boot/kernel/autofs.ko
(...)
/usr/share/zoneinfo/zone.tab
/usr/share/zoneinfo/zone1970.tab
/var/db/etcupdate/current/etc/defaults/rc.conf
/var/db/etcupdate/current/etc/periodic/daily/480.leapfile-ntpd
Click to expand...

Thus it wants to replace quite a lot of files and it seems I could move forward with the install, but I'm currently a bit unsure if I can reasonably expect it to succeed...
Any opinion?
(Let me know if you prefer me to continue in a new thread)
 
gwarf said:
So there is apparently nothing on the freebsd-update servers for 14-ALPHA3.
Click to expand...
There isn't a "14-ALPHA3"; there was however a "14.0 ALPHA3"; it still lives in the source tree, see below. 14.0-RELEASE is nearing its EOL. Leading up to its past release there were various "versions" available, they probably existed as snapshots and/or binary images that have a (very) short life span. The same holds for any 14.1 ALPHA-s. After ALPHA-s, BETA-s and RC-s have served their purpose, I think they not tend to stay available as snapshot images for obvious reasons.

gwarf said:
Then while looking around I saw this interesting suggestion: https://forums.freebsd.org/threads/freebsd-update-fetch-fetching-public-key-failed.1280/#post-7950
Click to expand...
That's from a very long time ago (FreeBSD 7); things change over time. Release Engineering is not set is stone either, though it is fairly stable and does not change often in a significant way.

Support for "versions" of anything else than FreeBSD X.Y-RELEASE and (the most recent incursion of) -STABLE from for example stable/14—if and when they exist—is (very) short lived during a release cycle and in the run up to that. AFAIK the ALPHA-s always start in main, AKA "HEAD" of the source tree repository.

That progresses to the BETA-s and those are in the stable branch (e.g. stable/14). What follows next in the process leading up to an official release is the issuance of release candidates, the RC-s (preferable just one). The final step leads to the official release of a -RELEASE version.

Remember the process of release engineering and the steps just before that are responsibility of the lead of the Release Engineering (currently Colin Percival) and his team. Further info: 2024 FreeBSD Developer Summit: Release Engineering updates.

If you want to use and track FreeBSD -STABLE, I suggest you subscribe to the stable mailing list; for "HEAD"/main aka FreeBSD -CURRENT there's the current mailing list. See the FreeBSD Handbook for further info.

FreeBSD 14.0 had the following sequence of events:
  1. ALPHA1 in main aka "HEAD"
  2. APLHA2
  3. APLHA3 switch to stable/14
  4. APLHA4
  5. BETA1 switch to releng/14.0
  6. BETA2
  7. BETA3
  8. BETA4
  9. BETA5
  10. RC1
  11. RC2
  12. RC3
  13. RC4
  14. RC4-p1
  15. FeeBSD 14.0-RELEASE
That rather long sequence of events was probably due to some big changes; one of them was a major incorporation of a new version of openSSL ("OpenSSL has been upgraded to version 3.0.12. This is a major upgrade from version 1.1.1 [...]").

If you want to examine more closely what happens in the FreeBSD source trees, I suggest you have a look at the developers handbook and get acquainted with git; a starting point: Using Git for FreeBSD Development

For a better insight in the relation of various FreeBSD branches and its related "versions" and to get hold of what's going where when you are using certain branches with git, have a look at the excellent SVG of anlashok here. With the above info, you should be able to get an idea where ALPHA-s, BETA-s and RC-s are located; note: not all (sub)branches are in this graphic.
 
Hi Erichans,
Thanks for your reply!

Sorry the 14-ALPHA3 was a typo in my post, as visible in the code excerpts it was all about 14.0-ALPHA3.

My issue is that I had to take over the maintenance of a few FreeBSD hosts that got deployed with 14.0-ALPHA3 by a former admin that was probably eager to use FreeBSD 14.0... (and there is even an internal build host with some bhyve VMs running 14.0-CURRENT, but this one will be for another day).
I'm currently trying to find the suitable way to move them form 14.0-ALPHA3 to a proper release like 14.0-RELEASE (as a first step, hoping it will be easier) or just 14.1-RELEASE, so that I will be able to update them in a clean/easy way.
I've been looking at using freebsd-update for this as I would like to avoid building/updating from source if I can.
 
(I have no experience with pkgbase; it won't be officially included in a -RELEASE until 15.0-RELEASE as I understand it.)

Apart from the extra work from the additional step in between, it should be even money to go from 14.0-ALPHA3 -> 14.0-RELEASE -> 14.1-RELEASE or directly to 14.1-RELEASE. 14.0-RELEASE is going to be EOL at the end of September. I have a slight subjective preference to go to 14.0-RELEASE first in your "alpha" case, but I have no experience to back that.

Read the release notes for 14.0-RELEASE (not out when 14.0-ALPHAx was issued) and 14.1-RELEASE carefully. If your system does not use UFS as a root file system, but uses ZFS on root, create a BE (Boot Environment) before upgrading, see the Handbook [edit: only seems to mention boot environments] and Managing Boot Environments.
 
Last edited:
I've also been having a subjective feeling about 14.0-RELEASE as an intermediate step, sometimes feeling baby steps are less dangerous, but I tend to think that in the end it should be quite the same.
It's indeed running ZFS on root with some encrypted volumes, I will backup these and prepare a BE, thanks for the advice and the pointers.
I now feel a bit more confident about this going OK without too much problem, thanks :)
 
Thanks all, I was able to do the update from 14.0-ALPHA3 to 14.0-RELEASE then to 14.1-RELEASE without (too much) issues.
The only issue is that I "only" lost remote access at some point, when doing the userland update for 14.1-RELEASE, not exactly sure why, but apparently related to the DHCP network configuration that was not blocking, and too quickly some bridges and wireguard configuration were done and not working properly (had to review and update conf). And as there was no way to have a remote access to the console, I had to get help by a colleague... :) I reviewed/fixed all these and it seems that now all is fine 🎉
I manually created new boot environements following https://klarasystems.com/articles/managing-boot-environments/, and saw that in fact freebsd-update was also creating some, so I didn't lacked of backup boot environemnt but it's not yet clear to me how this compares to the manual ones, will have to clarify this.
 
From 14.0-RELEASE (non-patched) to 14.1-RELEASE, expect problems.

gwarf said:
… lost remote access at some point, when doing the userland update for 14.1-RELEASE, …
Click to expand...

From security advisories FreeBSD-SA-23:19.openssh and FreeBSD-SA-24:04.openssh:

"… Restart the applicable daemons, or reboot the system. …"
 
gwarf said:
[...] saw that in fact freebsd-update was also creating some, so I didn't lacked of backup boot environment but it's not yet clear to me how this compares to the manual ones
Click to expand...
Automatic or manual, both create BEs. Doing it yourself, manually, gives you an active role and the choice of an apt naming scheme for management purposes. The automatic creation and naming scheme are controlled by the CreateBootEnv parameter, see freebsd-update.conf(5). My view: take active control of BE management; use the auto-creation as a fallback for example in the process of freebsd-update(8) when BEs are not being created manually (forgotten or not yet known).

BEs are basically managed bootable ZFS cloned snapshots*. Snapshots are created nearly instantaneously and are at the point of their creation practically free of charge. However, the administration and storage requirements of them over time are not (space wise, the diffs in between snapshots and your running OS are the determining factor); I've written more about that here. Further info:
Understanding what is and what is not contained in a BE on a standard ZFS on root filesystem layout is important. A very short description you'll find at Boot Environment Structures in bectl(8). Basically, a (predefined) set of system files and directories are incorporated, through the specific use of ZFS datasets (=filesystems) and mount options in the root pool. You can, if you so desire, adapt that scheme to your needs. See for example ZFS Powered Magic Upgrades from ca. 4 min. onwards where Allan Jude explains that on his laptop he has /usr/local included "as part of the OS" and therefore included in BEs versus on various servers where he has not included /usr/local. Carefully look at the ZFS root pool layout on your system because there have been some changes; a fresh 14.1-RELEASE should have zroot/home mounted at /home, that differs from the layout as presented by Allan Jude.

Upgrading remotely with BEs​

- the bootonce feature can be your lifesaver -

Consider using the boot once feature of bectl(8): bectl activate -t <myBE> (Managing Boot Environments). For example when relying on remote SSH access only, then you may not have easy access to the console and its BE boot options while booting. Just being able to powercycle to boot into the previous working BE may come in handy.

As a final note: be careful with using zpool-upgrade(8), even more so when upgrading remotely; see here.
___
* Snapshots, especially recursive ones, play an important role in ZFS replication, but that's a another topic.
 
Last edited:
That's what Allan Jude wants to avoid in ZFS Powered Magic Upgrades; also, no more >>>> conflict markers. A very small number of configuration files are symlinked.
 
You must log in or register to reply here.
Back
Top