4 ms·

I'm a fairly new FreeBSD user and this will be one of my first major upgrade. What should I be aware of when performing major upgrades? On Linux, I would avoid

I'm a fairly new FreeBSD user and this will be one of my first major upgrade. What should I be aware of when performing major upgrades? On Linux, I would avoid it and just start from a clean system. Curious what more experienced users thoughts are.

rwky 3y ago
I've had some issues with the opensmtpd port when upgrading from 13 to 14 which is probably due to the openssl upgrade. Apart from that the upgrade process tends to be pretty simple the updater warns you of any potential problems. As with any upgrade take a backup first so you can restore to 13 if you need to.
olavgg 3y ago
Compared to RHEL, CentOS, FreeBSD upgrading is a breeze. Debian is easiest. I have done like 100 different upgrades of FreeBSD and most has been without any issues. If you use Jails, you have to upgrade them also, there are guides for this.
adamddev1 3y ago
I just upgraded to FreeBSD 14 from 13 and it was fairly clean. It asks you to evaluate diffs for a few config file changes. The only issue I had was that sudo was uninstalled for some reason so I had to go back to my server console, go in as root and re-install sudo.
bell-cot 3y ago
With care - and upgrading a test system or two first to re-familiarize myself - it's worked fine for me. Two tips: - Understand `gpart bootcode` (or equivalents), and be really sure that your low-level bootcode gets upgraded. - If you're running zfs, `zpool checkpoint` can give you a way to rewind the entire state of the pool to a prior point. Used with some care, it can be extremely useful. Or just reassuring, as your "Plan B".
- waynesonfire 3y ago
  This is interesting. I was just playing around with a VM that had mirrored ZFS root and I wanted to test if I could boot from either mirror--it requires a bit of hand-holding since /etc/fstab seems to hard-code the gpt label of the boot device making it difficult to boot from the mirror without first changing that reference. I didn't realize this and went down a rabbit hole of trying to recreate boot partitions which I found interesting. With that said, I'm curious whether the upgrade procedure updates the bootcode on both drives in the mirror. --- Slight tangent. The reason for playing around on the VM was that when I installed FreeBSD, I selected the zfs root auto-fs feature. It created a zfs partition that spanned the entire disk which I later decided that I didn't want. My goal was to shrink the zroot, and I was able to accomplish that using zfs send / receive and re-creating the partition withe the desired size. Fun exercise. I need to revisit the installer to see if I'm able to provide any parameters to tune the size of the zroot. I really didn't want to create the filesystems manually from the installer shell.
inferiorhuman 3y ago
If you're talking about a home lab or workstation environment I would 100% back everything up and start from a clean system. Go back to FreeBSD 9 or 10, in-place upgrades have consistently bit me in the ass. Installer getting wedged, problems upgrading the boot loader, disk labels, freebsd-update getting wedged, you name it. If you're talking about a production environment, ideally your machines are more-or-less immutable anyways in which case you wouldn't be upgrading in place anyhow.

rwky 3y ago

I've had some issues with the opensmtpd port when upgrading from 13 to 14 which is probably due to the openssl upgrade. Apart from that the upgrade process tends to be pretty simple the updater warns you of any potential problems. As with any upgrade take a backup first so you can restore to 13 if you need to.

olavgg 3y ago

Compared to RHEL, CentOS, FreeBSD upgrading is a breeze. Debian is easiest. I have done like 100 different upgrades of FreeBSD and most has been without any issues. If you use Jails, you have to upgrade them also, there are guides for this.

adamddev1 3y ago

I just upgraded to FreeBSD 14 from 13 and it was fairly clean. It asks you to evaluate diffs for a few config file changes. The only issue I had was that sudo was uninstalled for some reason so I had to go back to my server console, go in as root and re-install sudo.

bell-cot 3y ago

With care - and upgrading a test system or two first to re-familiarize myself - it's worked fine for me. Two tips: - Understand `gpart bootcode` (or equivalents), and be really sure that your low-level bootcode gets upgraded. - If you're running zfs, `zpool checkpoint` can give you a way to rewind the entire state of the pool to a prior point. Used with some care, it can be extremely useful. Or just reassuring, as your "Plan B".

waynesonfire 3y ago
This is interesting. I was just playing around with a VM that had mirrored ZFS root and I wanted to test if I could boot from either mirror--it requires a bit of hand-holding since /etc/fstab seems to hard-code the gpt label of the boot device making it difficult to boot from the mirror without first changing that reference. I didn't realize this and went down a rabbit hole of trying to recreate boot partitions which I found interesting. With that said, I'm curious whether the upgrade procedure updates the bootcode on both drives in the mirror. --- Slight tangent. The reason for playing around on the VM was that when I installed FreeBSD, I selected the zfs root auto-fs feature. It created a zfs partition that spanned the entire disk which I later decided that I didn't want. My goal was to shrink the zroot, and I was able to accomplish that using zfs send / receive and re-creating the partition withe the desired size. Fun exercise. I need to revisit the installer to see if I'm able to provide any parameters to tune the size of the zroot. I really didn't want to create the filesystems manually from the installer shell.

inferiorhuman 3y ago

If you're talking about a home lab or workstation environment I would 100% back everything up and start from a clean system. Go back to FreeBSD 9 or 10, in-place upgrades have consistently bit me in the ass. Installer getting wedged, problems upgrading the boot loader, disk labels, freebsd-update getting wedged, you name it. If you're talking about a production environment, ideally your machines are more-or-less immutable anyways in which case you wouldn't be upgrading in place anyhow.