heston76, If the system is running a database server or also anything that loads modules from files (emacs comes to mind) are good to stop before upgrading the files on disk. Booting to single user mode guarentees that nothing else beyond the minimum is running. So that's a good safe procedure. But on say a git-daemon server serving files on disk there is little problem with upgrading while the system it

running but the running system is little more than single user mode anyway.

On machines running database servers I always do a full database dump and shut down the database before upgrading. It's my paranoia! Can always load the backup if needed. (If you need more availability then using replicated databases keeps one online always as the other is upgraded.)

rwp: speaking of upgrading with pkgbase, what is the proper sequence for adding a Poudriere jail for the new release? With freebsd-update I could provision it after the second restart, i.e. after userland was updated.

Schamschula: You can just wait until you're fully upgraded

You don't need to worry about it during the upgrade

rwp: I guess I was noticing more the explicit indication _not_ to reboot until you have progressed all the way through from intallkernel through etcupdate.

heston76, Did I accidentally insert a reboot between upgrading the userland and the ports/pkgs? I may have because I usually do reboot there. But I thought I had said to simply upgrade userland then upgrade ports/pkgs then cleanup remove old libs.

The reason not to reboot at that step is that likely ports/pkgs will fail due to shared libraries missing with the new userland until the ports/pkgs are upgraded to the new version linked against the new libraries.

I once had changed my root shell to /usr/local/bin/bash and found myself with a broken root shell after that problem during upgrade. I had no way to log into the system! D'oh! I used a Boot Environment to save it, mounted the future default, fixed the root shell back to /bin/csh (it was csh then, it is sh now), and then booted back to the default Boot Environment to continue. That's the type of problem that can occur if you reboot

in the middle at that step.

So now I change the toor account to use /usr/local/bin/bash and don't touch the root shell. (The reverse would also be a good choice. Either way.)

With pkgbase (which is new and I have almost no experience with yet) I worry that the kernel and userland are being upgraded on disk together and it is missing that first kernel upgrade in isolation step. But it might be in there and I am just missing it. I'll need some time to learn the pkgbase procedures before I am comfortable with it.

Schamschula, With poudriere there is a little bit of a dependency issue bootstrapping a new release. I am going to back away from the microphone on this topic because I am not an expert on this particular detail. I think you are right that you would want to do it after the userland is updated, so that packages get built against the new userland. That will take some time to build up all of the new pkgs so that they can then be

I'm pretty sure that I will just stick to building stable on my repo and just nfs mount the clients to install. Worked well this last round.

installed. This feels like the case but please let me say that I am not an expert on local poudriere and pkgs.

heston76, I think you have a good process doing it that way and nothing significant changes with it for this release.

rwp: That's what I was thinking. I've always done it that way under freebsd-update. As long as pkgbase updates userland along with the kernel, Poudriere should be happy. And, yes, the first build always takes a long time, as there are multiple compilers to be built.

I am curious how long this takes for you in your environment to build the pkgs for you?

The first build for 15.0 was 17:35:13 for 640 packages. This is an old Dell T320 with 64 GB RAM