/quit

ketas: ketas

mia cpet came

ketas: hi

ketas: not mia i just dont like libera

ketas: the whole # for every chat topic upsets me

a what

#freebsd has one # only :p

yea but if we start talk talking about purple bunnies people get upset

and redirect to #freebsd-purple-bunnies

who colored the bunnies anyway

some asshole

special easter ones?

named ketas

is it like bikeshed

ketas: msg

yourve been summoned

˜/43

44

does FreeBSD bootloader only show the Boot Environments option if there are multiple boot environments? I did root on ZFS, and bectl is showing default and so forth, but I wasn't seeing Boot Environments in the bootloader

...nevermind, just realized that the first freebsd-update takes cares of this

hodapp: yep

don't rely on freebsd-update, create BE's on your own

perhaps we can add command switch to freebsd-update to skip BE creation

the plan was to create them on my own (going to try to clone an existing system into this), but first I wanted to verify that the boot loader handled them at all

yes, it works fine

bectl create newbename - that's all

no need to clone anything

I meant "clone" in the more generic sense, not as in ZFS clone - I've a FreeBSD installation outside of this ZFS pool, and I'm aiming to get it inside of one

that's why I use FreeBSD: it has seemless BE support.... but everything else is failrly lagged behind ;-p

BEs are ZFS thing

yes, I know that much

if you want to create new BE from scratch, let's say install 14.3 into one BE and CURRENT into another one, it's supported, but you have do it by hand

have to go, bbl

later

good morning

hm, so if I understand right how this works, I could: boot to my shiny new root-on-ZFS install, make a new boot environment, mount all the FSes from that, cp/untar my existing FreeBSD install from the other drive over top of this

and this would be relatively non-destructive since my original BE would still be around, in case I mangle something in the copy

hodapp: That's doable if you maintain the bootloader. Sure.

ek: what's involved in maintaining the bootloader? I'm not as familiar with this on the FreeBSD side

Just keep the bootloader in tact on the new zfs-on-root install. Don't overwrite that, and you should be fine.

Or, snapshot it to be safe and roll back if it gets goofy.

Yeah, planning on snapshotting regardless until I have things kosher

I don't yet have a good understanding of what resides in the filesystem, and what is in ZFS settings/metadata

There's a lot of information out there if you're curious. At the moment, I wouldn't worry too much about metadata.

Just get your datasets backed up and transferred and you should be all set.

Settings you can take a look at using "zfs get all path/to/dataset"

I meant as far as what metadata pertains to booting/environments, e.g. I know there is bootfs property

Ah. Gotcha;.

It's not terribly involved (for the most part.) Maybe take a peek at wiki.freebsd.org/BootEnvironments

Hey, I've got a bit of an interesting network issue and I lack experience with this. I've got a system on OVH, and its networking is pretty simple. I've got a bridge and I've got a jail on this bridge, and I've got a VNET jail using epairs on it. The a side of the epair is on the bridge, and the b side is in the jail. Now the complication: I've got this random floating IP, and they say "it's attached to

the host, so use the host's gateway". I can't set that as the default route inside the jail until I can reach it, so I route add -host thatgateway -iface my internal epair, the b side, since that's what I can say.

I'll grab a pcap in a while when I get the chance, but I'm curious if there's some reasonable way to structure this.

Alright, so, pcap on the bridge, I'm seeing a bunch of: ARP, Request who-has <gateway> tell <floating>, length 28

hodapp: you can create new BE with "bectl create newbe", it will be clone of the runninb be or begin with empty dataset: 1. create new ZFS dataset zroot/ROOT/newbe 2. set mountpoint=/ and canmount=noauto for this dataset 3. populate it with files 3. reboot and enjoy

mzar: just cloning from running should already set up the various mount points, right?

bectl create clones and promotes this dataset to be potential rootfs

that

...that's what I mean

thare are no really any mounpoints except /

BE is usually plain /

thought it had /usr, /usr/local, /var...

so they wont't be cloned

uness exist on root dataset

thought -r did that

I am not using -r but perhaps it's for people who have nested something inside root dataset

like zroot/ROOT/default/anotherdataset

do you have /usr on different dataset ?

I did default root-on-ZFS setup, but not booted into it now so can't look

let's say homes and for example zroot/var/log can be shared between BEs

but I'm just going off of what bectl man page says with 'Boot Environment Structures'

ha.. you have to check it, learn everything from hier(7), do some experimentation and you will become expert

no worries, our community is strong, we are still runnig FreeBSD since ZFS is tightly integrated with this and appreciate pjd@ work on ZFS implementation, tsoome@ work on boot loader enhancemtents and kevans@ work on scripting BE booting with lua

did it I miss anything? please correct me

the default root-on-ZFS setup is built in a way that most of the system is shared between BEs

post update to 14.2, trying to pkg update yields "pkg: Setting ABI requires setting OSVERSION, guessing the OSVERSION as: 1400000"

freebsd-version -kru gives 14.2-RELEASE-p1, 14.2-RELEASE-p1, 14.2-RELEASE-p3

uname -UK gives "1402000 1402000"

How do I get it to set OSVERSION according to what it really is

sysctl kern.version:

well, only the major version matters for pkgs ABI, so the gussed value should be ok-ish th

hey, is it possible to convert a mirror vdev (2 disks) into 2 vdev mirrored 2 disks?

today I have 2 disks. they are part of a pool, single vdev.

I have additional 2 disks (C and D). I would like to have C and D as a single vdev mirror, to be part of that pool

ending up with a pool with 2 vdevs (each vdev being a mirror =A+B and C+D)

is there a way to make that expansion (add new vdev) on the fly?

cybercrypto: Absolutely.

Oops.

cybercrypto: Absolutely can be done on the fly.

cybercrypto: so you are starting from mirrored zpool and want to have pool consisting of two mirrored vdevs ?

in either way, it can be done on the fly, like ek said

eki: I lost connection. back now.

eki: I certainly missed your messages.

cybercrypto: I only replied that you can certainly add additional vdevs on the fly to add a secondary (or additional) disk mirror.

ek: to realize that setup I would simply use the zpool add mypoolname newdiskc newdiskd?

cybercrypto: I suppose it depends. Are you trying to add a new 2-disk mirror to the same zpool?

I didn't completely follow exactly what you were requesting. I just know there isn't much you can't do on the fly with ZFS.

Oh, yes. You are adding to the same pool.

It was weather or not you wanted all 4 disks to be mirrors or just A+B (as vdev) and C+D (as vdev) which I wasn't sure.

To just create an additional 2-disk mirror for the two new disks in the same zpool, you can use: zpool add

Ex: zpool add poolname mirror disk1 disk2

it depends, one can have in a poo1 either 1. a morrior of two vdevs consisting of two drives each or 2. two vdevs consisting of 2 mirrored drives each, the capacity will be the same, the latter is more common setup, described above by ek

mzar: thanks. I am not concerned about capacity. I will use mirror vdev with 3 disks each. (each vdev have fault tolerancy of 2 any 2 disks). My question is related on expansion of that pool using new disks.

ek: yes, thats is what I am trying to clarify.

cybercrypto: Okay. I wasn't sure what you meant by "expansion of the pool."

But, if you just want to add a secondary mirror, it's pretty straight forward.

mypool today = 3 disks mirrored (single vdev)

Keep in mind that the secondary mirror will not be a mirror of the first mirror. Just a new set of disks that will mirror each other.

the pool I am trying to achieve = vdev-mirror-0 (3disks) + vdev-mirror-1 (new 3 disks)

Okay. Then "zpool add mypool mirror disk1 disk2 disk3" is what you're looking for.

ek: yes. thats what I would think how to realize that setup.

Excellent. Have fun!

thank you all, cheers

cybercrypto: Sure thing.

And, the beauty of ZFS is, if that setup turns out to not be what you want, you can destroy and try something else. All on the fly.

So long as you don't mess up your current mirror setup, you can really break anything setting up the new disks.

s/can/can't/

yay ZFS ~(^o^)~

badkat: indeed :)

cybercrypto: please don't hesitate to read manuals, this excellent FreeBSD handbook chapter by A. Jude docs.freebsd.org/en/books/handbook/zfs and do some experimentation

cybercrypto: TL;DR: truncate -s 10G drive{1,2,3,4} && zpool create tank mirror ./drive1 ./drive2 mirror ./drive3 ./drive4

this way you will learn a lot

test, do experiment, break testing setups, and you will learn from this

cybercrypto: echoing mzar, and MWL's and Jude's "Mastery: ZFS" and "Mastery: Advanced ZFS" books supplement above-mentioned handbook part well if you want to dive deeper.

cybercrypto: That said, these were written back when FreeBSD used ZFS stack ported from OpenSolaris and before FreeBSD switched to OpenZFS (or implementing parts of ZoL? not sure here tbh) but I believe that all the content from these books applies. It's mostly high-level and userland commands stuff which has not changed.

cybercrypto: ZFS is flexible, but one tip: use "zpool labelclear" when moving drives between vdevs, mirrors and pools

might as well zero it out, who knows if i still works

then you would

if drive was correctly removed/detach it shouldn't be necessary

mzar: You don't really need a drive to be "correctly detached" and a proper shutdown. ZFS is self-repairable. No need for `fsck`. Importing filesystems between different OSs works flawlessly. Back when FreeBSD had extremely shitty support for my WiFi card (AX200 chip) with only 2.4GHz support, I used to dual-boot my ThinkPad with FreeBSD and Debian on a 2TB NVMe. I had a small UFS partition for

FreeBSD, EXT4 for Debian and kept my data on a large ZFS. Whichever OS I used I was just importing the ZFS stuff and it "just worked". The single downside was that there was no ZFS-native encryption and I was unable to use FreeBSD's geli nor Linux' LVM.

that man that I watch yt and I see this black filth fucking black should be kept as slaves as they are not allowed to speak in public bro I feel so sorry nazis diddnt win ww2 and put these all where they brelong in the stables or crematories. Why do we feed these filthy fucking niggers belong to jail instead of just gassing them. Worthelss as their kind are booming uselesss babies and commiting crimes.

Only thing worse than a nigger is a nigger defender

regis: it was about "zpool labelclear" not shutdown

psionic: are you a FreeBSD user ?

mzar: Got it. I read it along "unexpected power loss". That said - ZFS is resilient in such cases. I've worked with large-ish UFS arrays years ago, where a power loss resulted in 2-3 hours of customer support responding to customers with apologies and asking ops whether we can "just cancel this fsck thing". Sadly, higher-ups there made such decision a few times and it didn't go well. They got a

quick fix and customer support got "weird tickets" shortly after.

Please poke staff in #libera-hotline if they return with that behavior.

Bahhumbug: about ZFS ?

Bahhumbug: I got it

er. fuck

*lol*

Bahhumbug: The stats thing in #libera's topic didn't come back with anyone.

regis: Sorry, tab fail

mason: To be blunt we're rarely on stats p.

regis: ZFS works like hell, but to make it even more resilent you need to run zfsd(8), do you ?

mzar: zfsd just does reporting

gAy_Dragon: Ah, you did this? Not a mechanism based on what I quoted on priv sent to mzar?

it was not, we dont actively scan PMs for most things (generally just dox information)

it was me being a bit tired, missing someone else did something, and apparently failing to read

This is 7th Monday, also known as Monday Eve.

has anything bad happened here ? regis: was your connection affected ?

mzar: nah, just an unexpected reconnect ;)

ha.. klined, nice

mzar: Back to the topic at hand: I'm using ZFS as "ZFS on root" since became a viable option on FreeBSD 9 (CLI setup like it's 1995 and RedHat or 2000 and Gentoo, before ZFS was a thing offered via bsdinstaller). My experience with data loss and overall recoverability is that as long something is written onto the filesystem, it just "is". No need for `sync` and a proper OS shutdown procedure

(which on FreeBSD kinda requires `sync` with UFS). It's wonky with some fast storage used as ZFS SLOG but that's an edge case.

s/bsdinstaller/bsdinstall/

regis: no worries, same here, I am also addicted to ZFS FreeBSD user and former RedHat user

mzar: I've switched a small-ish hosting company from keeping user data on UFS to ZFS. All this stuff was still rsync'd to backups sporting Debians with DRBD (I don't know it well but they appeared to be certain about having snapshots with their disaster recovery plan). Long story short: it went flawlessly. And whenever they had a Samsung HDD go nuts and had syslogd flooded with HDD CRC errors or

whatnot, they pulled it live, replaced, and only then just replaced in via `zpool` commands. Much less hassle than their earlier `gmirror` setup, and in case if the system would die for any reason (usually a hardware failure), there's no hours-long `fsck` after you boot it back up.

regis: neat, unfortunately, FreeBSD is still a bit lagged behind

mzar: I only joined this company due to being compatible with and knowledgeable with OS they were using.

mzar: That was some 14 years ago.

can one still find and apply for such a job now ?

probably not, skilled devs are transitioning to better paid jobs, can AI fill this gap contributing to FreeBSD project ?

if you've not written it, why should we read it?

who did ?

mzar: I know a few here in Poland but it's a shit pay and with small businesses get an overload of irrelevant tasks doing which you don't progress. You need to find the time to do the tasks which are relevant to how you want to evolve. Not worth it. Startups stuck as it's usually chaos and any proof of concept becomes a product. Corporations pay shit but you can easily find a place to learn and do

what you want. Choose your poison.

s/stuck/suck/

regis: i will not drink this hemlock cup

mzar: tl;dr every options destroys in in some way. It's either a burnout at a startup where you need to stay for a year to grab stock options and it's (usually) a year of pure chaos, established small company with shit pay and no street cred unless you do something really incredible there and NDA allows you to brag about it later, or corpo where it's easy to just DM people on Slack/Teams/whatever

to get onboard their project and eventually get noticed if you do something well.

I'm hoping someone can help me with a funny routing problem I'm trying to conquer: bpa.st/5MWQ

At home I have vnet jails that have no problem running dhclient and getting an address, but they're on the same network as the host. This OVH "additional IP" is on a whole 'nother /24 but I'm told that if I get packets to my host's default gateway, they'll be handled properly. The trick is that I can't ping the jail from the host, nor the host or the gateway from the jail.

mason: you need to add an address to the bridge on the host and add appropriate routes to your host and your jail

satanist: So both the bridge and the epair in the jail have E.F.G.H?

no you need to have an address on the bridge acting as gateway for your jail

The bridge has an address - A.B.C.D - and that works fine for the host.

I tried setting A.B.C.D as the gateway for the jail, but was stumped.

this might also work, but you still need to add a route to A.B.C.D on your jail and a route to E.F.G.H on your host

mzar: regis: ek: many thanks.

Would the host-side route just be: route add -host E.F.G.H -iface bridge0 then?

And the jail-side route: route add -host A.B.C.D -iface epair0b ?

yes

and then also in the jail: route add -net default A.B.C.D

correct

I'll try it again. Pretty sure that was in there at one point.

don't forget to enable routing on the host with gateway_enable="YES" / net.inet.ip.forwarding=1

I've had that variously on and off as well. Let me set all that up and I'll make a noise

I'm also not sure if this works on freebsd (it does on linux), you might need also add an address to the bridge (which is imho a cleaner setup)

Yeah, I'm kind of thinking I can do this in a fairly straightforward way with namespaces on Linux. But I'm hoping not to give up on getting it to work in FreeBSD.

something like ifconfig bridge0 inet E.F.G.I/32 (might work better when you use the complete /24 on both sides

)

All of that set, and still something's not quite right. Running pcaps on both sides, and I see packets trying to reach the floating IP through the host, but not getting through. Oddly, the jail's pcap only sees some random multicase traffic.

multicast*

have you your external interface in the bridge?

A.B.C.D, yes.

And the a-side of the epair.

I'm going to do some testing with different addressing and see if I can verify that traffic can flow correctly between host and jail without any real addresses in play.

I feel somewhat like somehow this is fighting me because the floating IP is out of nowhere. My home set-up uses epairs and has no problem, but's a unified address space.

sorry my explanaiton only works with routing not bridging your uplink

hrm

So, home equivalent server, I don't need net.inet.ip.forwarding set, and there's no special routing on the host side to get things to the jails.

I'm using what's essentially wiki.freebsd.org/MasonLoringBliss/JailsEpair

yes when you bridge your uplink and your jails alltogether you don't need to set net.inet.ip.forwarding

My understanding is that if things are throwing packets for the floating IP at my host, since that's a bridge, the backing epair will get that traffic and be able to respond. This has to be some oddity with routing.

but doing this might bring other problems, for exaple your uplink might only deliver your traffic to the mac of your nic

Hm, so, does the MAC matter once the bridge gets the packet?

I'm assuming that once the bridge has it, at that point it cares about the IP.

it depends

no the bridge works on layer 2, the ip-address doesn't matter (in most cases)

Do I need to manually inject the jail's MAC into my arp table or something, then?

it depends

Hrm, hrm, work is picking up. I'll dive back into this once my shift is over. (I cover weekends sporadically.) Thank you for your pointers thus far! If I figure it out or get stumped further I'll let you know.

I would recommend to remove the uplink nic from the bridge and use proper routing

Alright, I can certainly try that.

Thank you.

Hooray, weekend coverage is done and I get tomorrow off. I'm going to split the networking and try a pure routing approach now.

Is there an easy way to select what installed kernel gets used?

<-- goes to have a look at the handbook to see if this is covered

SponiX: see man loader.conf, specifically the kernel option

hmm, I installed a "minimal" and "nodebug" kernel with pkgbase yet I don't find them in /boot/

I'm surprised *how* difficult it is to find any kind of documentation on running pipewire on FreeBSD.