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

Schamschula, Thanks for that. So about 18 hours to bootstrap a new release of pkgs. And some hours I forget (3.5 hours?) to compile base on my Thinkpad T480 with 16 GB of RAM to fully bootstrap to a new release. But then it can be installed multiple times easily.

have xlibre running, was as easy as replaxing xorg pkg install with xlibre, nice!

hi

please help, is thise the license for the FreeBSD OS? --> freebsd.org/copyright/freebsd-license

thanks for help

np

The problem is np-complete.

My soul is np-complete.

is there a way to change the default signal handlers from outside of a programm? I would like to write a core dump on sigpipe for a programm which exits because of a sigpipe but the bug doesn't happend when a debugger is attached

MelanieUrsidino, are you writing some BSD poetry?

No

That line sounded good.

Seeing an odd bastille thing; upgraded a bunch of thin jails from 15.0-RELEASE-p10 to 15.1-RELEASE -- two jails report still being on 15.0-RELEASE-p10 via `bastille list` after restart but `uname` inside the jail shows 15.1-RELEASE, the rest of the jails report 15.1-RELEASE and are otherwise fine. Any idea what's going on there?

Upgraded them all the same way.

The mounts related to those jails still seem to be /usr/local/bastille/releases/15.0-RELEASE -- is this a bastille bug?

bastille's jail.conf says 15.1-RELEASE for both jails

boru: do you know if they're using pkgbase or freebsd-update?

This is with pkgbase

I fixed up the mount for one of them as an experiment, but now `pkg check` is failing for most of base.

Not really sure if I trust bastille anymore. This is the second time I've seen this happen.

From the sources it looks like bastille just calls freebsd-version inside the jail, checking to see how that does it

The problem seems to be that it leaves over mountpoints for old releases after updating.

At least, that is what I have been able to discern

This is after an upgrade from 15.0 to 15.1 -- on another box now, 2/3 jails have the same problem. One migrated without any issues at all.

jail.conf -> 15.1-RELEASE, fstab -> 15.0-RELEASE

I don't suppose you're the one who opened this issue for the same bug, lol: BastilleBSD/bastille #1560

Never thought of looking at the tracker, in fact. Good call

So, it was a bug afterall. I guess I'll wait for a fix.

Their pkgbase support is relatively new so I'm not hugely surprised that the first release involving it surfaced some problems

Yeah

Though doesn't seem like a lot of thought went into pkgbase after using it for a whole.

Hopefully they'll figure out how to upgrade before 16.0 comes along...

Starting to regret it a bit.

At the very least, some kind of helper script would be nice. It seems like if you come up with the right set of env vars and commands, upgrading works well, but they're not well documented yet

Aye, but the 15.1 instructions were clear and worked for me.

I just somehow read over them in the relnotes initially.

Sigh. One jail still acting funny; switched the mount point manually, but now `pkg check` fails for all of base. The other jails were fine. Starting to feel like there are gremlins in this NAS.

Definitely mounted 15.1, seems to be failing pkg check for 15.0 packages

Transpired that I need to recreate the pkg database. NFI what happened there during the upgrade with bastille.

The bastille upgrade command sometimes doesn't update the fstab properly. Just check it and do it manually. And then pkg bootstrap and pkg upgrade

This isn't a big deal at all, but just curious - I have an old Dell server with a 4-port Dell-branded (Broadcom) gig ethernet card, and it works fine.

But the Dell labeling has the ports labelled as "1-4" from left to right. In FreeBSD, that turns into bge2, bge3, bge0, bge1 - that order seems to stick between boots.

Is this just a weird Dell thing or an OS-level thing that determines that mapping of ports?

spork_css: Yep. Just a weird Dell thing.

I have many Dell servers with the exact same thing going on.

You can use something like ethname to reorder the NICs if you'd like. I just either cable how they need to be to my liking or just deal with bge2 being primary or whatever.

Gotta choose your battles.

yeah, 100%, I'm not going to fight it, was just curious. and I have a new labelmaker so I'll just slap accurate labels on there.