scoobybejesus: Maybe take a look at:

And, yes, you need to update the boot loader/code.

is it normal for my other epairs to leak into a jail?

rtprio: Kinda vague. What do you mean by "leak"?

And are these VM epairs or something? VNET?

vnet, yar

ifconfig |grep e0a_ shows three other jails

From the jail itself?

yes, inside the jail itself

and an unrelated bridge, and the parent interfaces

Not normal in my experience. Each jail only shows it's own epair interface.

hrm, curiously the interface for itself is missing

But it's reachable on the network?

oh shit, it's all wrong

it attached to the bridge, not to vnet

Ah. That would make more sense.

it's not supposed to be

Well, the vnet should utilize the bridge. But, connecting directly to the bridge would take vnet out of the setup.

Of course, I'm not sure what your configuration is, exactly.

But, when I use vnet, I have my bridge on whatever interface and then I create the vnet interfaces for the jails which are members of the bridge.

i have a dedicated vnet -> bridge -> lagg for jails distinct than the lagg for the host

but don't keep detailed notes to repeat the bastille create command as the last time, apparently

rtprio: Fortunately, Bastille is pretty well documented (and somewhat simple.) I wouldn't be surprised if you can find that info rather quickly.

Again, I'm not sure what your setup is, but if the LAGG is already setup, the bridge to that is the same as any other interface and then you'd just use that bridge for VNET.

i just sed s/workinghost/desiredhost/ and replaced the config

rtprio: Did it work?

yeah, once i got the right lines in rc.conf

moving from bhyve to jails turns out to be a pain in the ass

rtprio: Got enough time in on jails to confirm if you perfer jail over bhyve?

For 15.1-RELEASE there is download.freebsd.org/releases/amd64/15.1-RELEASE/base.txz which is the -p0 level. Is there a location to fetch a base.txz that is updated to the current 15.1-RELEASE-p1 version?

I can make one by compiling from source. But at the moment it would be more convenient to just fetch one.

dnp1: well, not really, just started on jails

my bhyve host has a ton more ram, but the jail host is newer/ faster cpu

Hi; the uname on 14.3 has changed after the latest p16 update, it now says "FreeBSD 14.3-RELEASE-p16 #0 -dirty: Tue Jun 30 11:19:56 UTC 2026"

Before it only said "FreeBSD 14.3-RELEASE-p14 GENERIC amd64", does anyone know why?

I don't know anything. But isn't 14.3 end-of-life?

From today :)

It is still under support for another 32 minutes in my timezone. But then that's it. :D

congration

hi!

dead chat :(

nope

oh

ho

hi*

good morning/afternoon/evening (depending on where you are). Morning for me

It's around midnight for me lol

I've been playing Deltarune (on FreeBSD obviously)

hi hhao

okay, I'm not a game player myself

what do you use FreeBSD for?

server (web, mail, database)

and I use it to be in irc (weechat)

so not as a daily driver?

that's what i use it for

i know barely anyone who daily drives it, it's mostly server ppl :(

well not that it's necessarily a bad thing

lots of people in this channel use it as workstation

you just managed to find one who doesn't :)

ah

my friends used to use FreeBSD but they switched back to linux :(

i'm gonna go

cya

Can i use sendto() in capsicum mode ?

I don't see a reason why you shouldn't be able to use it (if you have the right capabilities of course)

I tied to use it on socket with CAP_RECV and CAP_SEND, but i got "sendto -1 errno 94 Not permitted in capability mode".

On UDP datagram socket.

was the socket connected? or did you have CAP_CONNECT? not sure if connecting to some host on the internet is permitted in capability mode

I am doing recvfrom and then sendto.

Sendto to adress got from recvfrom.

seems like a pattern that would be good to support in capability mode, does it work with CAP_CONNECT? if not, then I suggest opening a problem report, likely needs a new capability then for exactly that pattern

CAP_CONNECT doesynt work too.

Thank you for your help.

So, I've a question/problem. I have a jail (via the podman port) that has trouble reaching a bhyve VM on the same system (connected via VNET + bridge). Doing `ping $vm_ip` from the jail nets me a very high packet loss (around 5% on a good day, and upwards from there --- all the way to 100%) --- on Linux end, it looks like iptables is dropping packets due to an INVALID state.

The VM (which is Linux) is bridging a bunch of IPs from its own podman. All but two (10.24.0.1, which routes to the VM's "host", and 10.24.0.3) have this behaviour --- the two exceptions (10.24.0.{1,3}) work 100% perfectly though.

Doing the same ping from the host (not the jail) works perfectly fine, though, regardless of IP.

I suspect the misconfiguration is on BSD end (since it works fine if I don't send the ping from a jail), but I'm not even sure as to where to start looking ..... any ideas? =\

IOW, `[host's] jail -> VM -> podman` is broken for all (except 1), `host -> VM -> podman` is 100% fine.

Dunno if there's a pattern, but from some quick & dirty tests just now:

10.24.0.2 => 91.7% packet loss; .0.3 => 0%; .0.5 => 87.5%; .0.7 => 10.8%; .0.10 => 14.9

(expect a ~5% variance, except for .0.3, where I've never ever observed a dropped packet)

I'm, frankly, flabbergasted at this point. Something's obviously very wrong, but I'm having trouble narrowing it down.

Well, NEVERMIND (I've just narrowed it down to a {docker,podman}-compose problem

)

After update last week, Nextcloud's cron.php started complaining about "ps: cmd: keyword not found" and "ps: no valid keywords; valid keywords:". Anyone knows if this is a known issue?

ibs: update from what to what? if it were a known issue the venue would probably nextcloud

but take a peek at the file and find the ps call

ugh, one of the best decisions I ever made was shitcanning Nextcloud

hodapp: same

switched to a combination of Immich, Radicale, and Syncthing

and I never could understand how Nextcloud could fail so miserably at being behind a reverse proxy

like, 20-30 lines of boilerplate configuration and *still* fucking things up at random

I read here of Nextcloud problems I don't have.

hodapp. What kind of nextcloud reverse proxy problems are we talking about? Works perfectly fine for me

Ozymandias42: obscure problems around login flow and uploads are the ones I can recall. it requires special configuration.

In homelab setups or with SSO?

I should've checked bugzilla instead.. but people are aware and fixes are happening, I'm happy. bugs.freebsd.org/bugzilla/show_bug.cgi?id=296323

Because I use it with two containers. Nginx and phpfpm and have that behind a k8s Traefik ingress as well. And for me everything works. Even caldav and carddav

its caldav "worked" until I looked and it was inexplicably missing 30% of my contacts with no explanation

Ah. That sounds like a red flag indeed

I run NC in a jail (nginx+php_fpm) and the reverse proxy (nginx) in another (and postgresql in even another jail)

Haven't had that happen yet or haven't noticed at least. But makes sense that you switch to radicale then

joemie pretty much my setup. Just jails instead of k8s

You don't use redis or memcache btw?

redis I use indeed, but on a docker instance (on linux)

how do i set up the installer to use an http proxy and also connect to wifi properly?

if i go get a live system then type bsdinstall

it says

"wireless cannot be confiured without making changes to the local system!"

In zfsize, setting quota and refquota the the same value is like a traditional partitioned device? It can got above the value (quota) but is guaranteed that value in space?

can't go*

I think I'm confusing that with refreservation and reservation

list

runxiyu: weird error but it sounds like it needs to put firmware on it?