Hi. Can someone please currently fact check if the current freebsd version supports the built in wifi chip for the raspberry pi 3 or not?

i would be surprised

Matt|home: wiki.freebsd.org/arm/Raspberry%20Pi says no

how i go about about updating thin jails? would then simply make buildworld/installworld/make distribution with DESTDIR=/path/to/jail a way?

angry_vincent: That wouldn't be a thin jail any more. For my part, I avoid all the complexity and just don't use thin jails. Especially now with pkgbase, creating jails is *fast*. In fact, I've stopped using zfs send/receive to do it - the pkg based installs are *fast*.

I agree with mason . there's still some other benefits to zfs send/recv, but thin jails were a bad idea even 10 years ago. the problems outdo the benefits.

what's worse is that with pkgbase, 'thin' jails can have a whole new meaning :-)

Thin jails would be nice in a situation with limited storage on disk. I've not switched to pkgbase yet so will reserve opinion on that.

antranigv: curious what sort of problems are you referring to? I'm trying to learn jails and pros/cons hence the query.

'bsdinstall jail /some/jail' is also quite nice for thick jails.

mns: I was resisting until enough people had bled on it, and the pkgbase installer still breaks with distressing regularity, but to give you an example, a jail I built the other day with FreeBSD-set-minimal-jail-15.1 takes a whopping 137M, and that's a fully functional certificate authority server.

Current iteration - will likely change as I learn more: wiki.freebsd.org/MasonLoringBliss/PkgBaseChroot

a thin jail is more complicated because you have to create the tree manually, then mount it via nullfs in a custom fstab, and you have to rinse and repeat that process for every jail.

mns: Strong word of advice - if you're just starting off with jails, use the base system tools to manage them. Only change if you encounter difficulties. The base tools are quite usable.

(And if you encounter difficulties, ask here on or a mailing list before giving up!)

i agree with mason - start with a thick jail. use 'bsdinstall jail /some/path' to populate it. add something to /etc/jail.conf.d/name.conf, then jail -c name, youre pretty much good to go at that point.

fwiw I don't think thin jails are a bad idea, but they're not a good first step.

mason: I had initially started with bastille, but I wasn't learning anything. I dropped that and switched just working with jail.conf, especially once you could include files in it from /etc/jail.conf.d. As I've learnt a little more, I've started using variables, so most of my jails are similar. 137MB is pretty small. What is FreeBSD-set-minimal-jail-15.1 ?

i'd like to see if i can convert most of my jails to podman containers

mns: It's a pkgbase package that is tuned for jails, as opposed to VMs or hardware.

kevans: I was looking at that this morning. Docker networking still seems opaque to me.

I think dch is trying to improve the situation

he put out a call for ignorant buffoons like you and me somewhere else, this may be a good opportunity for us :-D reviews.freebsd.org/D58179

For Linux boxes, I quite like LXC, but I fear it rotting. So I've been pondering Docker. But everything is a struggle: "How do I get this to act like FreeBSD?" And I win the struggle most of the time, but lately I've been giving up more and just using FreeBSD jails. :P

Looking.

(i haven't had a chance to look yet, but if there's something still unclear we should complain about it)

Oh, neat.

Yeah. I'll do that. The green part on the right is pleasing.

i'd be quite happy to just rebuild my things upon an updated base container rather than updating them in-place

kevans: Ah, alright, that makes the appeal immediately visible then.

mostly i'm still thinking about storage organization and what i need to provide on the host for persistence

isnt that a problem that thin jails solve? well, i mean, you can share a common base system that is updated in just one place.

yeah, i mean- in-place updates are fine, but realistically most of my stuff touches very little from base and even if there is something custom there, I probably want to blow it away and do things 'better'

well, not necessarily

hold on, i think my baby's getting into some shit again

thin jails pose different risks; sure, you can update base in-place just once, but then you have to manage the logistics of package updates for all of these other things

hm right

depending on the nature of the base upgrade, that's not great

updating packages in the jails is a problem regardless of whether you have thin or thick jails, no?

minor version updates are fine, but if you need to do a major version hop then you're signing up for fun since you can't just do one jail at a time in isolation

mns: yes, but the question is whether I have to bring down all of my thin-jails or can do one thick jail at a time

kevans: good point, I've not had that many jails to run into that yet.

jails can get pretty interesting, you can also configure them to just contain a single binary and its dependencies. so less than the base system.

either way, in a container model I can presumably rebuild the container with an updated base and achieve pretty minimal downtime as I swap the container into production, modulo things that may require data migration (thinking of, e.g., postgres upgrades)

bsdrobert: how would you do that?

kevans: Or stuff them into Kubernetes and have a rolling upgrade! But don't do that.

you can do that by copying a binary on the host system, and all of its shared libraries (via ldd), then copy them over, so it's something you'd script.

i have written the script but dont really want to share links here, search github for anonssh

will do bsdrobert

thanks

Hm, looking at the live example at whiskey.skunkwerks.at/en/books/handbook/containers I immediately want to start changing things.

whiskey, skunk and austria with a dash of freebsd.

mns: i think this conversation has inspired me to take that code and turn it into something like 'minijail $(which irssi)'

I'll have to go through the Containers stuff now too.

Would be nice to use similar tooling to the rest of the world

mhm.

sure, to an extent.

So, I'm really curious about this. Shouldn't pkgbasify set "enabled: no" in /etc/pkg/FreeBSD.conf?

s/no/yes/

It exists as "no" after running it.

mason: I think you'll be pleasantly surprised with pkgbase.

So, pkgbasify creates a new FreeBSD-base.conf file in /usr/local/etc/pkg/repos that has it set to yes.

That overrides the /etc/pkg/*.conf files.

I haven't used pkgbasify in a while, so I'm not sure how much more refined it is now (since I've been on pkgbase already.) But, I do recall needing to point the pkgbase certs to a different location?

... or the certs they're looking for didn't exist and I had to pull those manually or something.

Other than that, it's been quite solid ever since.

ek: Ah, sure enough. Thank you.

ek: It appears to have done everything on its own.

Sure thing.

Yeah. I would assume it's much more revised by now since it's becoming the norm/default moving forward.

The update process is much faster. Instead of waiting for 45 minutes for a "freebsd-update", it only takes ~30 seconds for a pkg upgrade. Vast difference.

Yes, I'm loving that.

It's pretty nice!

Also crazy handy for jail updates as well. Everything is just so much easier and faster.

Not that I don't appreciate freebsd-update. This is just a much more streamlined option.

to use pkgbase, do I need to be on 15.x? or will I be able to use it on 14.4 which is what I am on at the moment.

mns: you can use it on 14.x, but it's a little unfriendly

(e.g., you'll need to watch more closely for landmines when upgrading because 14 doesn't have the notion of sets?

s/?/)/

Got it. Maybe that's another reason to get me motivated to move to 15. Most likely 15.0-STABLE

mns: You can definitely use pkgbasify to convert to pkgbase on 14.x. It's not terribly difficult. Like kevans said, just keep an eye on the first bits to make sure there aren't any errors or hiccups.

After that, you're pretty much all set.

But, I would pkgbasify and then use pkgbase to upgrade to 15. Might as well since it only takes a few seconds.

It isn't tedious.

ek: oooh that's a good point, that is what pkgbase is for anyway, so might as well use it for that. I just need to get some external storage for backups. I have a mini-pc with 8GB RAM and 128GB of storage (I think, have to see how I can find out the exact amount)

there used t b a magical diff invocation on the PkgBase wiki to pick up what packages you're missing that the repo has and vice-versa

but its my main system so don't want to have anything mess up.

though i guess if you're upgrading 14.x -> 15.x, you probably just upgrade to 15 and then immediately install a set

fwiw, i used pkgbase for a long time before 14.x successfully, so it certainly won't blow anything up

how did you use it before 14.x, didn't it come out with 14.x ?

it's existed in the tree for much longer than that

oh

I haven't gone tripping through the srouce tree

the first iteration of my personal pkgbase builder was committed in 2016

oh wow!

at the time i would've only been using it for embedded things, but it was more or less reasonable

I thought this was a new thing, so its not really new.

It's been in dev for a while. I've been using it for about 5 years myself.

no, though there was a lot more recent work on it

the basic idea has been set for many years, recent evolutions made it a lot more user-friendly

Most definitely. It's very easy to use now.

Got it.

alright downloaded pkgbasify

will go through it and see what it does and prepare accordingly