Hacker News Reader

Comment by asveikau | Hacker News Reader

I actually think there is nothing wrong with the upgrade process. What about pkg-style makes it better? On those other systems you still need a reboot for kernel changes to take effect.

View on HN

It's more the number of reboots and invocations of freebsd-update. Since these are all manual steps, you need to keep track of where you are and invoke the next step manually.

The current process for upgrading FreeBSD is roughly, assuming that you're just using packages and not ports is:

* freebsd-update upgrade

* freebsd-update install

* reboot

* freebsd-update install

* pkg upgrade

* reboot

* freebsd-update install

* (optional) reboot

In comparison, the process for upgrading OpenSuse Tumbleweed, assuming that you're just using packaged software, is:

* zypper dup

* reboot

If the base system were managed by pkg, the FreeBSD version of the process should probably look a lot like the OpenSuse Tumbleweed version. Condensing upgrades down to a two-step process seems like it will be a significant quality-of-life improvement to me.

But if there are ABI breakages in base (say, a new syscall used in libc) you want to boot the new kernel with the old userland, then get the new userland later.

At least, I have heard this explanation in the context of OpenBSD, and assume it may also apply to FreeBSD.

I believe that's the same in FreeBSD as well. I also think it's a solved problem in the Linux world - OpenSuse Tumbleweed sometimes rebuilds every package because they've changed libc. Apart from watching 2000+ packages get updated, there's really no impact when this happens.

To solve this, the updater could create a new boot environment[0], install everything in that boot environment using as many passes as required, then reboot into that environment. OpenSuse already does a similar thing[1], though I don't know how well it works.

[0] https://www.freebsd.org/cgi/man.cgi?beadm

[1] https://news.opensuse.org/2018/05/15/transactional-updates-i...

The situation on linux is actually different because the kernel and glibc are maintained separately and the syscall ABI is treated as a boundary between components.

Any time a new syscall is wrapped the userland maintainers need to account for what happens when run on an old kernel and typically have some fallback logic.

Sounds like a great yak-shaving opportunity, to write a script that automates it

Which everyone does, if one has more then 2 machines ;)

I absolutely agree. I run FreeBSD on my NAS to take advantage of ZFS but every time I update it I have to Google the process or find my notes since it's incredibly non-intuitive.

I have a detailed set of instructions to follow when I'm upgrading my home server, plus notes from each time I've upgraded it.

At this point, I've only got two services (postgresql and mosquitto) which run on bare metal, everything else is in VMs. Once I move those off of FreeBSD the upgrade process will be greatly simplified (well, as simplified as FreeBSD gets anyway).

freebsd-update prints out what you need to do next at each step though. If it wants you to reboot and run it again it says that.

Or you just read the printout until it says fetch first ;)

I think there's value to having base separate from pkg, too. The way we ran FreeBSD at the two companies I worked where it was used heavily was to manage base and other things separately.

For base updates, we'd usually shut down services, install kernel and userland, and reboot --- I know this isn't the proper order, but most of the time the new userland is compatible enough to reboot (and you can usually power cycle if that doesn't work out). For updates where rebooting would be hard this way, we'd do it the right way, but then you need to add an extra reboot after installing userland, or restart all the services from base. If needed, we'd install the compat packages after the reboot. We would not update ports/pkg/etc at the same time; old binaries are expected to continue to work on a new system (and generally do). In house binaries are either compiled on the system they run, or centrally on a machine (or chroot/jail) running the oldest release on the fleet.

Generally,

When you need to upgrade software not from base, because of security updates or new features or ennui, you do that isolated from base changes. The only complication here is if you haven't updated base recently enough, pkg may provide binaries you can't run, and ports may provide software you can't compile (this one takes longer).

We would generally only update base for exceptional releases, or when it became hard to update non-base software on older releases. However, new machine installs would get the most recent release we had tested.

Reply on news.ycombinator.com