Anyone have the link where the guy at Netflix confirms a current branch is working before putting it into production, and he list them?

SponiX: are you referring to stabweek?

most recent one here: lists.freebsd.org/archives/freebsd-current/2025-May/007718.html

kevans: Yes, stabweek is what I was looking for. Thank you for the response

I'm checking out the May branch now. Hopefully it will work well for my new build box

hmm, what are the rules on calling malloc(..., M_WAITOK) with a lock held?

man 9 malloc says "However, malloc(), realloc(), reallocf() and free() may not be called in a critical section or while holding a spin lock."

Hi! I'm pretty new to FreeBSD. I dug out my old FreeBSD install, 14.1-RELEASE-p7, and I'm trying to get it updated. A couple of freebsd-update commands later, freebsd-version says 14.1-RELEASE-p8 but uname says 14.1-RELEASE-p7 (why? was it a purely userspace update?) - and freebsd-update -r 14.2-RELEASE fetch/upgrade/install later, my system has broken video drivers. After reboot, I get some kernel output,

then graphic switches to a blank screen. How do I debug this? I still have the old version (which I'm booted in) for comparison. Old Thinkpad laptop, Intel integrated + discrete GPU, but I think the integrated one is default.

By the way, kld_list="i915kms nvidia-modeset coretemp acpi_video"

I'll try removing that stuff...

cizra: is the tty blank too? (' ')

for me xorg doesn't select the proper monitor when I have both iGPU and dGPU running, i gotta manually select with xrandr

try this badland.io/prime-configuration.md

unwrapped_monad: Not loading i915kms helps. Yes, the TTY is blank (black screen, backlight enabled).

cizra, some intel video cards are very poorly supported unfortunately, I was literally unable to make the driver run on mu dell latitude notebook

the moment I enable the drivers - the notebook CPU usage jumps to 100% everything halts ...

I still able to do remove logins but local screen is not responded

I need i915kms for Sway, though. Poorly supported? Maybe, but it DID run on the previous kernel, 14.1-RELEASE-p7.

I spend a week trying solving this issue, but didn't found any solution

this is not sway related, i had this issues even in CLI

the moment I enable i915 drivers - system stops

I'

dang

Hi, when doing freebsd-update fetch -r 14.2-RELEASE from 14.1, does the system keep old 14.1 packages binaries etc, in other words, does the system degrade on each upgrade ?

Normally older packages from the previous release will work fine on 14.2. Some kmod packages might not work between minor releases so that's somethign you need to keep an eye on.

Infact for the start of 14.2's life the FreeBSD repo packages are built on 14.1.

Also, as of a couple days ago there's a new kmod repo that help with the above issue of having broken kmods between releases.

is there no incremental build when you have compiled 14.2 world and checkout & compile the main branch? (⁠・⁠o⁠・⁠)

not really, no

that's a pretty huge divergence

ooh

my question was more related to

if the upgrade leaves behind traces or not really, packages are cleanly replaced

freebsd-update doesn't update packages but it will recommend when they might be needed.

But with 14.1 being EOL you might want to update them?

skered: Yeah, everything currently be built is with 14.2 though - has been done that way since 14.1 went EOL

ivy: on Feb 22nd, you had an issue with multipath routing and which fields are hashed, did you ever resolve this? i'm trying this again and realising i might have been wrong, and maybe only the destination address is used?

jmnbtslsQE: multipath hashing works better with regard to UDP with "options RSS"

and you probably don't want to use net.route.multipath=1 for routing your VoIP traffic without this

good to know. all of my traffic in this case is TCP over GRE though

this is also all jailed and doesn't touch any physical interfaces, so not sure if RSS is applicable. but good to read about anyway

setting up zfs on an external usb drive. in the past i did that with 1) gpart create -S GPT da0 2) gpart add -l EXTERNAL -t freebsd-zfs -a 1M da0 3) zpool create extrn /dev/da0p1 4) sudo chown -R demido:operator /extrn. just did it this time and forgot to do the first steps, so i just ran 1) zpool create extrn mirror /dev/da0 /dev/da1 2) sudo chown

-R demido:operator /extrn and that's it. they seem to work fine but what's the downside of skipping the previous 2 gpart steps?

tyvm

I think that means you are using the entire drive rather than a drive partition? That's a valid configuration. In years and years past that was the original recommended partition for various reasons.

For your external USB device that is probably okay.

ok so it's the diff between giving zfs entire disk to work with vs giving zfs partition to work with?

For people installing on a system with root on zfs then it's not so good because usually we will put swap on a partition and we might use encryption and such and that needs partitions to do those things.

ahh that makes sense

I assume that "zpool status" will show the full disk device for you?

The other thing that is also problematic is that /dev/da0 is one of the dynamically created names. If you have two of those then you will never know which one will be da0 and which will be da1.

it doesn't go off of guid or smth?

So we also recommend using GPT partitions (because that's the new robust goodness) and then use GPT Labels to label the drive. Then use the GPT label for all other purposes including zfs pools so that the label follows the drive and there can't be confusion.

I put the drive serial number into my gpt labels such as gpt/z0K1G42J7B which is my zero'ith device in the pool with serial K1G42J7B and if it fails I can identify it easily.

Regarding your question about guid, run "zpool status -g" and look at the guid number it assigns.

just a long number

Right. Just a long number. And none of us are remembering it. So though it is used as a unique identifier to zfs us humans pretty much don't track it.

so are you saying it's always better, even if giving an entire external drive to zfs, to start with gpt, then give zfs a partition within it to work with? (even if there's only 1 partition)

so that i can use gpt labels etc

I would say yes it is always better to use a GPT partition but... Is it important in your external USB drive case? I don't know if it is that important at this point for your particular case.

Let's see what other opinions on this from others here on it. How are you planning on using this external USB attached storage?

2 external usb drives in a zfs mirror

But you are not booting off of it and are not running the OS off of it, right? Just using it for data storage?

nope, just storage

That's the main determining point for me. You don't need to have other things in other partitions on it. So I can't think of a hard downside to it.

Do yourself a favor and collect the drive serial number for each drive and make sure you can tell them apart. USB drive controllers and cables and such are not as reliable as internal SATA and eventually something will glitch or fail and it will be useful to know which is which at that time.

Also many times the USB controller will fail and the drive inside is perfectly okay. I know lots of people who have had that failure and then have removed the drive from the USB enclosure and had all of their data on the drive okay.

so for external storage-only, you'd skip the gpt+label step?

if i skip gpt+label, and i set it up using /dev/da0 and /dev/da1, and then i export them, connect some other drive, then connect these 2 again, /dev/da0 will already be in use so they'd get like /dev/da1 and /dev/da2, so then zfs can't import properly? or it still could based on guid, i'd just have a tough time correlating which physical drive is

da1 and which is da2?

demido: it'll detect the pool being on the new drives, and it'll know which drive is which because that information is stored inside the on-disk data

ok so no risk there

so i guess the question is, always gpt partition and label external drives before using with zfs or not?

i think there might be something weird about using the raw device for a zpool on freebsd though. i don't remember if i ever knew of the details. i've always provided zfs with a partition

i would provide a partition

if you find it tedious, it's not too hard to script it

aside from what i do, i think the consensus/typical setup on freebsd is to use labeled partitions. as to whether you must do that, i don't know

from what rwp said above, it seems like not using partitions is also acceptable

if you search online there might be some material on this question

if the norm is to always go first through gpt and labels, then add partitions to zfs to work with, i'll just do that. ty guys

so does that mean i run: gpart add -l extrn0 -t freebsd-zfs -a 1M da#, gpart add -l extrn1 -t freebsd-zfs -a 1M da#, zpool create extrn mirror extrn0 extrn1?

if you're not booting off of them, do you really need to gpart them ?

well they work, so i'm guessing no, but maybe it's nicer to always set up zfs disks the same way?