uskerine, I'd look (specifically) at chapter 3 (quick porting) or the Porter's Handbook. docs.freebsd.org/en/books/porters-handbook/quick-porting

s/ or / of /

i wish i resilvered at 339M/s

Matt|home: that bread looks delicious

Matt|home: how many folds did you do?

its still quite edible, the high density is less structure to support air/bubbles

building the structure can be in the chemistry of the dough/flour and or the structure built during the mix/folding process

structure == gluten basically

Matt|home: +8 to cooking profession granted

trying to boot 15.0 installer on a epyc CPU server panics: madt_parse_apis: double apic id 241

trying to boot 15.0 installer on a epyc CPU server panics: madt_parse_apis: double apic id 241

kerneldove, did you try disabling ACPI like was suggested yesterday?

ya

i tried set acpi_load="NO" and hint.acpi.0.disabled="1" from installer loader then ran boot

CrtxReavr, ^

Same results?

ya

same panic

seeing how tied n computers are these days with ACPI half the time that doesn't work

especiallylaptops

ya doesn't surprise me. it's just weird that fbsd chokes on this double id issue instead of mitigating it. freebsd is server focused, this is a epyc server platform, so wtf

and it's 2021 hw too, now too old/new

i went to switch from uefi to bios but the bios didn't support that. PoS

i wonder if i can disable hyperthreading

kerneldove: can you create a bug for this

i don't think i have a bugzilla account. if i collected all of the data together and posted a link would someone else be willing to? i'd remain available to do any testing, with the caveat that i can only try released iso's like 15.0-R because i have to pick from an iso library my host maintains

so i can't like, try patches and stuff sadly

kerneldove: that makes debugging more difficult, it is best if you create the issue, you are the only one who can answer questions about it

ya

:/

Why are you so hell-bent on 15?

i'm not. there's a 14.3 iso in there too and i tried that too

Same issue with 14.3?

yep

You're not using ventoy by any chance kerneldove ?

no i dunno what that is even

kerneldove: I thought you were quite clear about why things are the way they are

huh?

does anyone know who is working on importing cves into vuxml

(automation)

it was on the mailing list about 6 months ago, I am interested

polarian: vuxml any commiter can edit that database

for some weird reason the xf86-intel drive is very unstable think I fxed my crashes by finally removing that driver and setting the driver to modsetting as the freebsd machine ha sbeen on for 24+ hrs without a freeze

outdated, no longer in use

may have to update to currnt or stable as this mini PC was manu about a month ago and I think its too new for freebsd to run properly

Manufactuer Date: 11/30/2025

cpet: no thats not what I am talking about

there is a team working on automatic vuxml entries from cve databases

it was within the ML but I cant find it now

I thought xuxml was going to be retired and replaced with a more modern database, but maybe I just misunderstood how it would work.

cpet: not hardware but xf86-intel is old, usually modern intel cards work fine with the generic modesetting

o0x1eef: same but I have been told otherwise

soo...

Right, here we go… freebsd pkgbase jail time

Interesting, there appears to be a bug in FreeBSD 15 on aarch64 (arm64) where by default, TCP packets passing through an epair (tun/tap), such as with VNET jails, end up having a bad checksum

polarian: none of the status sheets mention it

DaliborFox: so instead of mentioning it here open a PR for it ?

I'm going to try to reproduce it in a virtual machine tomorrow, trying both x86_64, and if it doesn't happen there then aarch64, and open a bug report about it

cpet: I'll take a look, I've figured out what's going on just today :) The upgrade process has been quite a battle

i thought freebsd change where bridges cant have direct IP's or what not

May I kindly request a link to where the change is described? Though in this case, it seems to be a case of a bug in the epair driver, since tcpdump reports packets with a bad tcp checksum, UDP and ICMP are unaffected, and a workaround (described in the forum post) is to disable "TCP checksum hardware offloading" on the driver

The bridge(4) sysctl net.link.bridge.member_ifaddrs now defaults to 0, meaning that interfaces added to a bridge may not have IP addresses assigned.

Yeah, I think that's unrelated, I don't assign IP addresses to the interfaces added to the bridge, just the bridge itself, and then the interfaces "on the other side" of the epairs

what I've learned is that the FreeBSD-runtime and FreeBSD-rc are not enough to get a jail up and running, although I'm not yet clear on what I do need. I might install FreeBSD-base and make sure it runs at all, _then_ try being a smartass

still, fun process: you need the pkg keys in the right place and somewhere to store downloaded files and it's happy

I'm quite looking forward to messing around with pkgbase as well! Hopefully it'll be faster than freebsd-update, since I've spent the last several evenings upgrading from 14.3-RELEASE to 15.0-RELEASE with that

that reminds me, I need to update, and also to complain about freebsd-update again

If you have VNET jails and they stop working, there's a workaround in the above forum thread

thanks, I'll keep that in mind for my VM

also, migrating from Heimdal to MIT Kerberos is a bit of a pain when going from 14.3-RELEASE, I ended up having to set up a chroot with a 14.3-STABLE snapshot and using that to dump the database into a MIT-compatible format

Thankfully I don't have kerberos running on any of my BSD servers :P I kept those on Debian so that I could more easily use those as AD domain controllers

the version in 14.3-RELEASE does not support the transition... and the version in ports / pkg doesn't support the database format used by heimdal in the base system, which is no longer included by default in 15.0-RELEASE :D

Perhaps that could be more prominently mentioned in the release notes, as a warning in the "Userland Configuration Changes" section

fonks: Fair enough! I decided to set up a FreeBSD server on one of those ARM SBCs as my "network centerpiece" :D

the only real mission-critical BSD system I have is a webserver/RTMP streaming target used for one of my local-insertion cable channels :P it recieves the stream, converts it to ASI, and that goes to my modulator rack where it gets processed by multiple times my net worth in Blonder Tongue modules to become a QAM digital channel

Originally I was using Debian too, but when the time came to upgrade my aging old Raspberry Pi to something beefier, I thought I'd try out something new/different

Oooh, that's really neat!

and then like we talked earlier, that gets processed into analog too since it's a hybrid system

Fun!

Mine is mostly just a NAS and an IRC bouncer, though I do plan on eventually using it to host a web page for my project once it gets into a state where it's ready to actually be used by other people. I'm hoping 2026 will be the year of dopl2_composer! :D

I wanted freebsd-minimal-set, not just the runtime

not sure how to get it to neatly bridge with jib; might handle manually

so i have to move some disks around later in the nas and i label them based on position so i can find them when they fail... forums.FreeBSD.org/threads/from-dev…-name-to-gpt-name.87147/post-674122

does that still hold?

can i just gpart modify -i <part #> -l F01_R01... then zpool set path=/dev/gpt/F02_R02... pool raidz2-0

i'm not sure what zfs will do once the label just disappears

actually i did that wrong. set path=/dev/gpt/F01_R01...