# How long a major upgrade takes from previous STABLE to most recent STABLE?



## HD Scania (May 5, 2021)

It’s assumed that I have AMD Ryzen 7 4800 series and 32GB RAM, and from 12-STABLE to 13-STABLE currently.
Will also be useful for the next major -STABLE, i.e. from 13-STABLE to 14-STABLE
Asus M712 with AMD Ryzen 7 5800U/5700U, MSi Alpha 17 with Ryzen 7 4800U, and VAIO E15 with Ryzen 7 3700U, are wishlisted in my hardware cart.
To ease for both ZFS `beadm` and my mounts of foreign partitions, my /boot is on an independent ZFS, with my root on UFS.


----------



## balanga (May 5, 2021)

Why are you moving from `12-STABLE` to `13-STABLE` rather than from `12-RELEASE` to `13-RELEASE`?


----------



## mer (May 5, 2021)

Assuming the OP is currently running a ZFS based system and is familiar with Boot Environments (and assuming he means RELEASE, not STABLE) I've done the upgrade by following these steps to install into a new Boot environment (thanks vermaden ):









						Upgrade FreeBSD with ZFS Boot Environments
					

I am known as a strong ZFS Boot Environment supporter … and not without a reason. I have stated the reasons ‘why’ many times but most (or all) of them are condensed here – &…




					vermaden.wordpress.com
				




As for how long it took:  most of the time was spent downloading the new pieces.  Once that was done it didn't take that long.  Overall on a home broadband connection, I'd guess a couple/3 hours.  Doing it by chrooting to a new BE, I was still in multiuser mode and using the system during the process.   I only needed to reboot once.  Since 13-RELEASE is using OpenZFS updating the bootcode is a really good idea before you reboot;  the older bootloader may not be able to boot correctly.  I have not tested for compatibility, I've always just updated bootcode as part of my process.  New bootcode is easy to make backwards compatible, old bootcode has no knowledge of new needs.
When you update bootcode, make sure you are sourceing from the new BE, not the current /boot.

UEFI systems:  I don't have one of those so am not sure if any updates would be needed.

If you are talking about updating from source, I have no idea,  been a long time since I've done that.


----------



## HD Scania (May 5, 2021)

balanga said:


> Why are you moving from `12-STABLE` to `13-STABLE` rather than from `12-RELEASE` to `13-RELEASE`?


I need to test the overall and average speed on my wishlisted new laptops of the major version source upgrades from former -STABLE to most recent -STABLE.


----------



## bsduck (May 5, 2021)

The full upgrade process of my laptop from 12.2 to 13.0 using `freebsd-update` took about 3 hours, but it is far less powerful than your setup, runs on HDD and has /usr/src installed (which takes a lot of time to upgrade).


----------



## SirDice (May 5, 2021)

bsduck said:


> 12.2 to 13.0 using `freebsd-update` took about 3 hours


On my lowly i5 this took less than half an hour (binary upgrades are fast, most of time is going to be spent downloading the updates, not the actual upgrade itself). Building from source however took around 2.5 hours. On my Raspberry Pi 3 it took almost 2 days to build from source.


----------



## SirDice (May 5, 2021)

HD Scania said:


> It’s assumed that I have AMD Ryzen 7 4800 series and 32GB RAM, and from 12-STABLE to 13-STABLE currently.


A guestimate; 1-2 hours to build and about half an hour to install it (including dealing with merge issues).


----------



## bsduck (May 5, 2021)

In my case (i5 too) downloading was fast and what took a long time was the binary upgrade itself, I don't really know what makes such a big difference, is it a matter of disk speed, of /usr/src/ or not, or something else?


----------



## vermaden (May 5, 2021)

HD Scania said:


> I assume UFS root, which even ZFS has BE, but still ZFS on root gets me messed up of managing foreign SSD partitions, which are to be mounted on my FreeBSD-STABLE system.


Boot Environments are also possible on UFS filesystems:








						UFS Boot Environments
					

Yes you read it correctly. The fabulous ZFS Boot Environments – more about them here – – if you are not familiar with this concept – are now also possible on UFS filesystems…




					vermaden.wordpress.com


----------



## HD Scania (May 6, 2021)

vermaden said:


> Boot Environments are also possible on UFS filesystems:
> 
> 
> 
> ...


But unfortunately up to now still very pre-alpha, so i now need to reinstall FreeBSD 13-STABLE with UFS on root but ZFS on /boot
And is `beadm` for sure working with minimally your /boot is an ZFS partition? _Aligato_ for any kind discussions!


----------



## zirias@ (May 6, 2021)

HD Scania said:


> But unfortunately up to now still very pre-alpha, so i now need to reinstall FreeBSD `13-STABLE` with UFS on root but ZFS on `/boot`
> And is `beadm` for sure working with minimally your `/boot` is an ZFS partition? _Aligato_ for any kind discussions!


This sounds like misunderstanding what boot environments will do for you: They are about your whole system (the root fs).

In /boot, you already have the simple mechanism with kernel.old, and the bootcode isn't upgraded unless you explicitly do so. So, getting back as long as you just installed a new kernel is perfectly possible without boot environments.


----------



## HD Scania (May 6, 2021)

Other boot aspects ... I also expect them not to be broken due to the damages dealt at my UFS root, so my /boot is being mounted alone on an independent ZFS partition.


----------



## vermaden (May 6, 2021)

HD Scania said:


> But unfortunately up to now still very pre-alpha,


What is pre-alpha?



> so i now need to reinstall FreeBSD 13-STABLE with UFS on root but ZFS on /boot


Having /boot on UFS while rest on ZFS is pointless and useless. Either use UFS only or ZFS only.



> And is *beadm* for sure working with minimally your */boot* is an ZFS partition?


I never supported that in *beadm* but there are several *beadm* forks that support separate ZFS boot pool or separate UFS /boot partition.


----------



## HD Scania (May 7, 2021)

P


vermaden said:


> What is pre-alpha?
> 
> 
> Having /boot on UFS while rest on ZFS is pointless and useless. Either use UFS only or ZFS only.
> ...


(1) Pre-alpha? Their too early state which is lacked of long term stability
(3) Given a root partition in 35GiB and an /boot partition in 2.5GiB, does my return of FreeBSD use both two partitions formatted to UFS?
(2) The reverse is correctly listened: Root on UFS for use of fstab; but /boot on ZFS for use of `beadm`; but which `beadm` forks will be fine for my return of FreeBSD: both root and /boot are formatted to UFS?


----------



## HD Scania (May 7, 2021)

And i found ZFS commands too complex, unless with years of serious experience in FreeBSD or Illumos, so i’m to temporarily drop getting to master ZFS commands.
Unless responsible of preventing a heavy risk of data losses, servers for example, or you sometimes to often don’t need ZFS.


----------



## zirias@ (May 8, 2021)

Did you read my answer (#11)? Anything you still didn't understand about it?

Boot environments for (just) /boot don't make any sense.


----------



## HD Scania (May 8, 2021)

Zirias said:


> This sounds like misunderstanding what boot environments will do for you: They are about your whole system (the root fs).
> 
> In /boot, you already have the simple mechanism with kernel.old, and the bootcode isn't upgraded unless you explicitly do so. So, getting back as long as you just installed a new kernel is perfectly possible without boot environments.


Solved thanksBut how about UFS root within also all its BE’s, but using ZFS instead as its NAS data slices, esp if responsible as a publicly hosted server?
For server environments not using ZFS data slices has been known of data insecurity, but how and where?


----------



## astyle (May 14, 2021)

SirDice said:


> On my Raspberry Pi 3 it took almost 2 days to build from source


I bet that did not include recompiling EVERYTHING with as many options enabled as possible. I just finished compiling graphics/graphviz from scratch on my system, and that alone took me 7 hours, partly because the deps being compiled included llvm10 and gcc10, which ate up 4.5 hours with my Ryzen 1400.


----------

