RhodiumToad: right now it is locked at that line "ugen0.2", let's see what is next

RhodiumToad: it shows a lot of things related with hdaa0

RhodiumToad: is there a way to disable it? I do not need sound

If there is a vulnerability in a package, aprox. how long does it take for the maintainers to address the issue?

RoyalYork: Parallel to your question, how long until it hits the stable branch? It's a bit inconsistent on both sides of the question.

There's also some variabilty in the availability of binary builds, which happen periodically but not instantly.

/close

Ronis_BR: drivers can be disabled in /boot/loader.conf

hint.hdaa.0.disable="1" might do it, you might need to also disable hdac the same way

Im trying to install git-cola, however it doesn't like python 38 due to outstandign CVE

I would imagine installing a newer port of python would do the trick?

are you trying to install from packages?

RhodiumToad, git-cola isn't available in the packages, only in ports

ah

ok, you can set the default python version in make.conf, using DEFAULT_VERSIONS+= python=3.9

Got it....

thanks!

im loving freebsd bhyve

RhodiumToad, looks like its working now. Thanks.

Oh yeah, speaking of bhyve...

RhodiumToad: I also had to disable WITH_BHYVE_SNAPSHOT as well as WITH_OPENLDAP the other day to get buildworld to complete successfully.

Oh, and one question actually...is there a target to specifically just build lib32 or something? I've got base.txz and kernel.txz, but for completeness sake, I'd also like to generate doc.txz and lib32.txz. I'd imagine the former is just generated from the docs repo, but not sure exactly how to build the latter. When I commented out the line that

was disabling it in src.conf, the build failed with a message about it not being able to actually find lib32 (yes, I did clean beforehand), so it made me wonder if it had to be bootstrapped somehow.

Then I wouldn't be required to use my MacBook for iOS development.

I have a bhyve VM that keeps crashing and I'm not sure why: (bhyve), jid 0, uid 0, was killed: failed to reclaim memory

holy smokes, I have a ramdisk that ballooned up

lib32 shouldn't need lib32 to build as far as I know

what error did you get?

Let me try again, one sec.

Gah, that is so annoying. I need to do something about this.

Can't ssh into the box I'm using to run buildworld. sshd dies if my CPU is under heavy load for too long.

Same thing happens with any box I run poudriere on too (unless I rctl the jail or process or whatnot).

dies how?

sshd stops running, process is no longer present and nothing is listening on tcp/22.

I'll check the log here after I reboot the server to see if it throws any error or core dump message or whatever.

that shouldn't happen as a result of CPU load, but obviously can happen in OOM scenarios

Oh yeah, forgot about OOM. Yeah, that's probably it.

Isn't there a a _oom rc knob in rc.subr or something? Or was that just part of the specific script I was looking at? I thought I remember seeing it as part of the rc framework.

*_oomprotect="YES"

Ah, /etc/rc.subr: oomprotect

Yup

Hmm, so I guess sshd_oomprotect="YES" should work in theory?

yes

(in theory)

(haven't tried it myself yet)

Wellp, going to see. It's especially annoying because that's a headless server and for whatever reason the console KVM wasn't able to establish a video connection to it.

So now the easiest thing for me to do is just hard power cycle the box.

Yup, box is still responding to ping. It's just not listening on tcp/22. I bet sshd got OOM murdered.

Is there a specific signal that gets sent to when the kernel decides to kill a process due to OOM? I remember seeing something like SIGOOM at some point, but that might have been Linux-specific. I'm looking at /var/log/auth and I see "sshd[74739]: Received signal 15; terminating." in it from last night (which I think does line up with a running

build).

I mean I could see one of two things: Either process tries to allocate some memory and gets back an OOM return code in whatever function it uses to do so, and so has to handle it accordingly (e.g. release memory, warn + try again later, exit process, whatever)...OR, kernel sends a signal to the process, which looks like SIGTERM in this case. Though

I wonder if something like SIGOOM does exist, then that would be the way the kernel would basically tell the process, "Running out of memory here, either release some or you're going to die soon."

AIX had that in like the 1990s, just a shame nobody else followed suit

SIGDANGER

That would have been nice. Give the process a chance to slim itself down before having to potentially be force-killed.

iirc, programs that caught SIGDANGER were given more leeway before being outright killed, too

fortunately i never had to dig into that much

So I take it FreeBSD sends SIGTERM in response to OOM scenarios? Doesn't FreeBSD use a different method for process selection to kill? I think I remember Linux just picking random processes.

no, it sends SIGKILL

oh hmm

Makes me wonder what this SIGTERM is then. SIGTERM is 15, right?

the process selection is not like linux, but it's still possible for it to hit processes it shouldn't

SIGTERM is 15, yes, that's the one sent by "kill" by default

also used when shutting the system down

Maybe this line isn't from the OOM then. Strange.

yeah, OOM kills have explicit log messages

I just enabled sshd_oomprotect="YES", wonder if I need to restart sshd for it to be in effect now.

kernel: pid nnn (cmd), jid nnn, uid nnn, was killed: out of swap space # or similar

yes, you'd need to restart sshd

Hmm, still strange. This box has 16GB RAM + 16GB Swap and the only thing running on it was poudriere.

you should be looking at /var/log/messages, not /var/log/auth

I grepped all of /var/log for ssh, only entries found were in messages and auth. The one in messages was from weeks ago and expected.

er, grepped for sshd I mean.

All right, buildworld invoked after commenting out WITHOUT_LIB32 in /etc/src.conf. Lets see what happens.

anyway, the top sshd should never get signal 15 unless you have something doing runaway kill commands, or you do a shutdown

or you do service sshd stop (or restart)

No idea. It's pretty rare for it to happen and the only times I've remembered it happening was when the system in question was under heavy load for an extended period if time (which was always poudriere and maybe buildworld, but I don't remember that happening during a buildworld, only poudriere bulk).

I see there is "#define NETLINK_GENERIC 0" in <net/if_mib.h>, and recently with 13.2 the same token defined more standardly in netlink.h with a different value. That's at least a problem to the Rust libc crate, which already exports the old define. Any idea how to handle that ?

You would either have to run cbindgen again for the libc crate (usually from build.rs) to re-generate the FFI module from the system headers, or you can just generate a patch for that line.

That's what I would guess anyway, and it's what I've had to do in the past for similar issues.

it looks like OpenBSD and NetBSD have source selection for routes, but FreeBSD doesn't.

_xor: the libc crate is not using cbindgen, but that's not the crux of the problem. It looks like there are now 2 macros with same name expanding to different values, without even bringing Rust in the picture

now the logical separation into different header files mitigates the problem for C, and it becomes a big problem for the Rust binding which try to import everything into a single namespace, but there is still potential for Bad Problems when a given C file includes those 2 headers

_xor: if sshd gets a SIGTERM that should leave a trace. if it gets oom killed, that should leave a trace, so that only leaves SIGKILL, from a process?

Hello folks, Is there any tuto for wireguard in 13.2-RELEASE and othe os (13.1-RELEASE or Linux)

I must admit that I am a little bit lost with the new vpn way :-)

on 13.2-RELEASE you need the wireguard-tools package for rc.d script

otherwise it's pretty simple.. just check the official documentation

Ok mage thanks for the wireguard-tools package

we have something like this in production at $work (simplified) gist.github.com/silenius/4eded71d66714e1d9ba8a8d0081d274f

Title: gist:4eded71d66714e1d9ba8a8d0081d274f · GitHub

with some pf.conf rules

oh! thanks mage

yannd: Ah, that's right, forgot that about libc.

yannd: Those doubly-included headers aren't #ifdef guarded?

yannd: Or am I misunderstanding the underlying problem? I'm not sure about libc in this specific case since bindgen isn't an issue, but I do know that bindgen offers namespacing options to split it up (not that it would help here).

meena: If by trace you mean a coredump, then there aren't any that I saw. If by trace you mean log messages, there weren't any that I found.

Not terribly worried about it for the time being, will re-visit it later if it keeps happening.

the problem is that libc already exports NETLINK_GENERIC as a const = 0, for the old usage - and to export netlink bindings we need to export NETLINK_GENERIC = 16

the define clash does not impact the rust bindings

(not as a cpp-level clash, I mean)

_xor: i forgot about core dumps, but core dumps are usually logged, too

anybody know this error `getty exiting due to excessive running time`

last mention I find is from 1999

its on my external router

got freebsd/gnome running on x1 carbon laptop almost in no time

few hiccups here and there but mostly missing packages and sysrc

nice

yeah my t480 is working well

I have an X1 carbon I need to fix.

I broke it. . .

CrtxReavr: I used one up last year too.

It'd been off for a while, and it decided it liked it that way.

I got one of those fancy new ARM64 VMs from hetzner and support was nice enough to provide a 13.2 boot-only iso, but unfortunately when the kernel starts the console goes blank and I'm stuck. are there any boot options I could try?

cwup74: Any chance it's switched to serial? I've seen that happen.

cwup74: If you can get to a serial port, you might see it continuing there.

mason: I don't see any way to get a serial console. HTML5 video console only. selecting output modes in the boot loader (video only, dual + video first, etc.) makes no difference.

cwup74: They talk about serial over lan - maybe something here? docs.hetzner.com/robot/dedicated-server/maintainance/ipmi

Title: IPMI - Hetzner Docs

caught one shell script red-handed by doing sysrc modifications of the kld_list without appending, so it overwrote my video driver

sysrc should always do key+=value

this: gist.github.com/dfr/ac4dc043ee3780b690c5887a61f53494

Title: FreeBSD podman tech demo · GitHub

mason: it's a "cloud" VM, not one of their dedicated machines.

mason, this was my daughter's. . . they keyboard quit working on it.

cwup74: There's some discussion that could be useful here, in a bug I opened a few years ago: bugs.freebsd.org/bugzilla/show_bug.cgi?id=241036

Title: 241036 – efifb console lost during install in VM in UEFI mode - switches to serial

I ordered a new one, and carefuly took started taking the thing apart to replace the keyboard, but the little connectors that the razor thin ribbon cables for the keyboard and touchpad stymied me. . . I didn't understand how they work and broke them.

cwup74: Comment #8 in particular, in case what you're seeing is what I was seeing.

I've since found a place to order those connectors (aliexpress), but I need to re-open the thing and count the number of pins so I order the right size.

But I've been putting it off.

CrtxReavr: Ah, those things... I watched a video recently because I had to open one and they've always baffled me. Evidently you can *lift* them.

Thing is a bloody nightmare to open.

mason, yeah. . .

I always thought you had to pull them out along the cable, but I was confused.

mason: boot_serial=NO does not help with my case, but the PR has some more hints that I can research and test. thanks!

Hope it helps.

is there any way to boot back to a previouos freebsd snapshot? I'm upgrading to 13.2 release and I get a zfs error out of temporary buffer space. It seems the bootloader is broken. I'm downloading a memstick image (13.2R) and following the steps from ronny-mueller.com/2022/03/09/howto-…d-zfs-out-of-temporary-buffer-space

Title: [FreeBSD] zfs: out of temporary buffer space – www.ronny-mueller.com

The freebsd-update install I think it creates a snapshot

s2r: Please open a bug report for this. Sounds obnoxious and maybe you'll help others to avoid it.

Hi, anyone know what the state of bhyve + vga-passthrough is in 2023?

How do I use pkg to fix dependencies of an installed package?

:O

mason: A bug about the error? Ok.

CrtxReavr: pkg-check(8) sounds about right

s2r: Yes. And thank you.

mason: btw I could repair it and now it's back online.

Good.

Why does vim seem to debpend on libpython3.9? Can it not work with libpython3.10?

It is the default option

Oh & Python 3.9 is the default version right now. Build your own otherwise

I currently kludged around with libmap, but. . .

DEFAULT_VERSIONS+= python=3.10 python3=3.10 (in /etc/make.conf)

Already there. . . though I should change to 3.11

Interesting AMD Ryzen 5 hangs on 13.2, fine on 12.4, bugs.freebsd.org/bugzilla/show_bug.cgi?id=267782

Title: 267782 – AMD Ryzen 5 hangs on 13.2, fine on 12.4

Planning to upgrade from 13-REL to 13.2-REL, however I have two modified files for the sake of network/web server performance (that's the main duty of my server), and trying to decide whether do I really need those settings or not, could you please take a look at those both files, I'd love to get your feedback on the lines within there, perhaps few or many of them are now obsolete/unnecessary, when it comes to 13.2?

Here's my loader.conf: bsd.to/xDrU/raw and here's my sysctl.conf: bsd.to/ZzQo/raw - anything abnormal, weird, absurd, abusive, naughty?

Title: xDrU

these days, loading modules in kld_list is usually favoured over loader.conf

(though you do have to be a bit careful about rc.d's rather nondeterministic order of operations)

RhodiumToad: Well, thanks for those great tips, however just wanted to ask if I have anything unnecessary within those files FOR 13.2.. Like, now I can see that kern.geom.label.disk_ident.enable="0" and kern.geom.label.gptid.enable="0" are not needed anymore, as they're already default to zero. As well as, no more aio_load="YES", as it's already activated in the kernel.. Anything else you guys might give feedback/idea?

hm, do they default to zero? lemme check

looking at 13-stable I see them defaulting to 1

RhodiumToad: Under a fresh 13.2 installation (13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2), they seem to be default to zero..

No?

they show as 1 in my 13-stable vm, and I haven't found anywhere I'm setting them, and the code shows 1 as the default

did the default install create a sysctl.conf or loader.conf ?

RhodiumToad: Yes

Here both of them by the default, fresh 13.2: bsd.to/gqKD/raw

Title: gqKD

ok, so the default install turned them off in loader.conf

in the absence of a loader.conf they'd still be on by default

Do I really need this enabled/disabled; security.bsd.allow_destructive_dtrace, when it's only a web server? Any performance downgrade side-effect of that option?

overall

I see..

I dunno, I disable dtrace entirely

RhodiumToad: You don't like it or you're just more comfortable with other tools and don't have reason to use dtrace over them? (actually asking)

I remember when dtrace was being added after Solaris showed it off and people saying, "Screw everything else, just use dtrace."

I actually build WITHOUT_CDDL since i'm not using zfs either

Ah

Oh yeah, that reminds me, I should check on that lib32 build.

omg, it built successfully and I thought "That's weird, I think." ...then I noticed that WITHOUT_LIB32=yes was set :| wtf

d'oh

Before I forget, is it a rule that /usr/src and /usr/obj CAN'T be symlinked?

symlinking /usr/src makes the directory structure of /usr/obj a bit weird

It failed if I symlinked it to a sub-dir into a NFS mount I have at /mnt/repos/...

I haven't tried it recently, it's much simpler to nullmount them instead

That's what I tried next, for some reason that also failed, but it might have been something on my end.

(nullmounting them definitely _does_ work)

/usr/obj has to be not mounted noexec

I also wondered if a hardlink would work, or maybe use a separate NFS mount directly at /usr/src and /usr/obj, but I didn't have the time to mess wit hit.

Ah, that was probably it.

I don't recall if /usr/obj on nfs works, /usr/src on nfs definitely does work since i do that all the time

Do you use ccache?

not at present, I do use meta mode

I have snapshots of each build (e.g. 1301506, 1302505, etc) on my main file server, and that includes a copy of /usr/src, /usr/obj, pkgbase repo, *.txz, etc. But I don't want to do the actual build on my file server, hence NFS the relevant dirs on my file server to the actual build machine.

right

I also try to keep all mounts in /mnt and just symlink (or mount_nullfs) as-necessary to anything that requires outside of /mnt.

I leave /mnt for scratch mounts and have real volumes in /data/blah

Hence the foul-up with the build. I just used rsync to and back for the time being.

Should `make delete-old delete-old-libs` work if I do it directly inside of /mnt/repos/freebsd/1302505/src, or does it expect those targets to actually be invoked from /usr/src?

I could be wrong, but I got the feeling that parts of the build process expect a fixed path of /usr/src and /usr/obj, though they should be changable with OBJDIR=... (or whatever that macro is called).

no, pretty sure nothing depends on the exact paths. if so, it's probably a bug

but it's been long enough since I tried it that I can't be 100% sure

Good to know. Going to try it here soon when I finish updating the remaining systems to 1302505. If it fails then I'll save the logs.

About to grab some food, but before I do, lib32 did fail...

"Building /usr/obj/usr/src/amd64.amd64/usr.bin/ldd32/ldd32"

"ld: error: cannot open /usr/lib32/libc.so.7: No such file or directory"

That's what made wonder about bootstrapping for a second, because at a glance, that seems like it's looking for a lib32 so to actually build lib32 itself.

huh.

that seems like a bug

a lib32/libc.so ought to exist in /usr/obj somewhere at that point

RhodiumToad: termbin.com/cf5h

right, so it has no business trying to access the host environment lib32/libc

pretty sure that's a bug somewhere

but I don't know the src makefile infrastructure well enough to find it without spending a lot of time on it

Yup, makes sense.

I wasn't sure if it was actually trying to access /usr/lib32/libc.so.7 or if just said that due to a chroot or something (didn't want to assume that it didn't do that).

I checked src.conf and src-env.conf as well just to make sure dirs weren't being unknowingly set somewhere, but I didn't see anything.

I always build lib32, so I've never noticed this happen

It's nothing critical in my case since I haven't installed lib32 for quite a while, but it's probably something that should be addressed if it comes up for anyone that might.

Meta-mode having an effect also crossed my mind.

Hi! When I install FreeBSD manually (from ISO) in a VPS, it takes 2 min to boot. However, when I use the same FreeBSD version but configured by the VPS provider, it boots in seconds! I am trying to copy the configuraiton without luck. What should I look to make a full copy of the configuration?

Which VPS provider and which FreeBSD version?

V_PauAmma_V: vultr and 13.2

I am installing two, side-by-side, to analyze dmesg and check any differences

I already tries to install in UFS and ZFS. The result is the same.