00:00:26 RhodiumToad: right now it is locked at that line "ugen0.2", let's see what is next 00:03:55 RhodiumToad: it shows a lot of things related with hdaa0 00:04:04 RhodiumToad: is there a way to disable it? I do not need sound 00:10:23 If there is a vulnerability in a package, aprox. how long does it take for the maintainers to address the issue? 00:18:34 RoyalYork: Parallel to your question, how long until it hits the stable branch? It's a bit inconsistent on both sides of the question. 00:19:06 There's also some variabilty in the availability of binary builds, which happen periodically but not instantly. 00:30:31 /close 00:32:32 Ronis_BR: drivers can be disabled in /boot/loader.conf 00:35:43 hint.hdaa.0.disable="1" might do it, you might need to also disable hdac the same way 00:36:29 Im trying to install git-cola, however it doesn't like python 38 due to outstandign CVE 00:36:43 I would imagine installing a newer port of python would do the trick? 00:36:59 are you trying to install from packages? 00:37:13 RhodiumToad, git-cola isn't available in the packages, only in ports 00:37:18 ah 00:38:22 ok, you can set the default python version in make.conf, using DEFAULT_VERSIONS+= python=3.9 00:39:02 Got it.... 00:39:04 thanks! 00:39:44 im loving freebsd bhyve 00:45:11 RhodiumToad, looks like its working now. Thanks. 03:11:54 <_xor> Oh yeah, speaking of bhyve... 03:12:23 <_xor> RhodiumToad: I also had to disable WITH_BHYVE_SNAPSHOT as well as WITH_OPENLDAP the other day to get buildworld to complete successfully. 03:14:51 <_xor> 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 03:14:51 <_xor> 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. 03:20:54 * _xor wishes macOS were VM'able on bhyve 03:21:03 <_xor> Then I wouldn't be required to use my MacBook for iOS development. 04:19:59 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 04:34:56 holy smokes, I have a ramdisk that ballooned up 05:32:59 lib32 shouldn't need lib32 to build as far as I know 05:33:09 what error did you get? 06:23:12 <_xor> Let me try again, one sec. 06:24:49 <_xor> Gah, that is so annoying. I need to do something about this. 06:25:15 <_xor> Can't ssh into the box I'm using to run buildworld. sshd dies if my CPU is under heavy load for too long. 06:25:40 <_xor> Same thing happens with any box I run poudriere on too (unless I rctl the jail or process or whatnot). 06:26:02 dies how? 06:26:34 <_xor> sshd stops running, process is no longer present and nothing is listening on tcp/22. 06:27:02 <_xor> I'll check the log here after I reboot the server to see if it throws any error or core dump message or whatever. 06:27:04 that shouldn't happen as a result of CPU load, but obviously can happen in OOM scenarios 06:27:25 <_xor> Oh yeah, forgot about OOM. Yeah, that's probably it. 06:28:01 <_xor> 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. 06:28:03 * _xor greps 06:28:27 *_oomprotect="YES" 06:28:31 <_xor> Ah, /etc/rc.subr: oomprotect 06:28:34 <_xor> Yup 06:29:08 <_xor> Hmm, so I guess sshd_oomprotect="YES" should work in theory? 06:29:20 yes 06:29:26 (in theory) 06:29:34 (haven't tried it myself yet) 06:30:20 <_xor> 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. 06:30:34 <_xor> So now the easiest thing for me to do is just hard power cycle the box. 06:33:06 <_xor> Yup, box is still responding to ping. It's just not listening on tcp/22. I bet sshd got OOM murdered. 06:33:08 * _xor heads downstairs to the rack 06:41:37 <_xor> 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 06:41:37 <_xor> build). 06:43:20 <_xor> 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 06:43:20 <_xor> 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." 06:44:20 AIX had that in like the 1990s, just a shame nobody else followed suit 06:44:24 SIGDANGER 06:44:57 <_xor> That would have been nice. Give the process a chance to slim itself down before having to potentially be force-killed. 06:45:25 iirc, programs that caught SIGDANGER were given more leeway before being outright killed, too 06:45:40 fortunately i never had to dig into that much 06:45:56 <_xor> 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. 06:46:06 no, it sends SIGKILL 06:46:10 <_xor> oh hmm 06:46:27 <_xor> Makes me wonder what this SIGTERM is then. SIGTERM is 15, right? 06:46:48 the process selection is not like linux, but it's still possible for it to hit processes it shouldn't 06:47:09 SIGTERM is 15, yes, that's the one sent by "kill" by default 06:47:20 also used when shutting the system down 06:47:36 <_xor> Maybe this line isn't from the OOM then. Strange. 06:48:05 yeah, OOM kills have explicit log messages 06:48:43 <_xor> I just enabled sshd_oomprotect="YES", wonder if I need to restart sshd for it to be in effect now. 06:48:48 kernel: pid nnn (cmd), jid nnn, uid nnn, was killed: out of swap space # or similar 06:48:59 yes, you'd need to restart sshd 06:49:45 <_xor> Hmm, still strange. This box has 16GB RAM + 16GB Swap and the only thing running on it was poudriere. 06:49:52 you should be looking at /var/log/messages, not /var/log/auth 06:50:19 <_xor> 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. 06:50:29 <_xor> er, grepped for sshd I mean. 06:52:33 <_xor> All right, buildworld invoked after commenting out WITHOUT_LIB32 in /etc/src.conf. Lets see what happens. 06:53:09 anyway, the top sshd should never get signal 15 unless you have something doing runaway kill commands, or you do a shutdown 06:53:23 or you do service sshd stop (or restart) 06:54:34 <_xor> 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). 07:11:32 I see there is "#define NETLINK_GENERIC 0" in , 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 ? 07:17:16 <_xor> 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. 07:17:32 <_xor> That's what I would guess anyway, and it's what I've had to do in the past for similar issues. 08:01:50 it looks like OpenBSD and NetBSD have source selection for routes, but FreeBSD doesn't. 08:06:32 _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 08:09:02 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 09:18:45 _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? 09:18:48 Hello folks, Is there any tuto for wireguard in 13.2-RELEASE and othe os (13.1-RELEASE or Linux) 09:19:22 I must admit that I am a little bit lost with the new vpn way :-) 09:19:43 on 13.2-RELEASE you need the wireguard-tools package for rc.d script 09:20:19 otherwise it's pretty simple.. just check the official documentation 09:21:01 Ok mage thanks for the wireguard-tools package 09:25:54 we have something like this in production at $work (simplified) https://gist.github.com/silenius/4eded71d66714e1d9ba8a8d0081d274f 09:25:55 Title: gist:4eded71d66714e1d9ba8a8d0081d274f · GitHub 09:26:18 with some pf.conf rules 09:31:05 oh! thanks mage 10:12:19 <_xor> yannd: Ah, that's right, forgot that about libc. 10:12:45 <_xor> yannd: Those doubly-included headers aren't #ifdef guarded? 10:14:10 <_xor> 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). 10:14:55 <_xor> 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. 10:15:07 <_xor> Not terribly worried about it for the time being, will re-visit it later if it keeps happening. 10:28:39 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 10:29:00 the define clash does not impact the rust bindings 10:29:58 (not as a cpp-level clash, I mean) 11:20:48 _xor: i forgot about core dumps, but core dumps are usually logged, too 13:16:41 anybody know this error `getty exiting due to excessive running time` 13:16:49 last mention I find is from 1999 13:17:05 its on my external router 14:28:07 got freebsd/gnome running on x1 carbon laptop almost in no time 14:28:23 few hiccups here and there but mostly missing packages and sysrc 14:42:47 nice 14:42:54 yeah my t480 is working well 14:43:40 I have an X1 carbon I need to fix. 14:44:25 I broke it. . . 14:55:42 CrtxReavr: I used one up last year too. 14:55:55 It'd been off for a while, and it decided it liked it that way. 14:57:07 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? 14:57:35 cwup74: Any chance it's switched to serial? I've seen that happen. 14:57:49 cwup74: If you can get to a serial port, you might see it continuing there. 15:00:54 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. 15:02:21 cwup74: They talk about serial over lan - maybe something here? https://docs.hetzner.com/robot/dedicated-server/maintainance/ipmi/ 15:02:22 Title: IPMI - Hetzner Docs 15:02:28 caught one shell script red-handed by doing sysrc modifications of the kld_list without appending, so it overwrote my video driver 15:03:24 sysrc should always do key+=value 15:03:48 this: https://gist.github.com/dfr/ac4dc043ee3780b690c5887a61f53494 15:03:49 Title: FreeBSD podman tech demo · GitHub 15:05:32 mason: it's a "cloud" VM, not one of their dedicated machines. 15:07:43 mason, this was my daughter's. . . they keyboard quit working on it. 15:09:02 cwup74: There's some discussion that could be useful here, in a bug I opened a few years ago: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241036 15:09:04 Title: 241036 – efifb console lost during install in VM in UEFI mode - switches to serial 15:09:21 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. 15:09:34 cwup74: Comment #8 in particular, in case what you're seeing is what I was seeing. 15:10:25 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. 15:10:59 But I've been putting it off. 15:11:06 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. 15:11:07 Thing is a bloody nightmare to open. 15:11:21 mason, yeah. . . 15:11:26 I always thought you had to pull them out along the cable, but I was confused. 15:29:59 mason: boot_serial=NO does not help with my case, but the PR has some more hints that I can research and test. thanks! 15:30:57 Hope it helps. 16:47:53 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 https://www.ronny-mueller.com/2022/03/09/howto-solve-freebsd-zfs-out-of-temporary-buffer-space/ 16:47:54 Title: [FreeBSD] zfs: out of temporary buffer space – www.ronny-mueller.com 16:54:59 The freebsd-update install I think it creates a snapshot 16:57:49 s2r: Please open a bug report for this. Sounds obnoxious and maybe you'll help others to avoid it. 16:59:26 Hi, anyone know what the state of bhyve + vga-passthrough is in 2023? 17:26:48 * CrtxReavr eyes megaTherion suspiciosly. 17:27:32 How do I use pkg to fix dependencies of an installed package? 17:33:55 :O 17:34:13 mason: A bug about the error? Ok. 17:34:32 CrtxReavr: pkg-check(8) sounds about right 17:36:04 s2r: Yes. And thank you. 17:39:58 mason: btw I could repair it and now it's back online. 17:40:57 Good. 17:43:02 Why does vim seem to debpend on libpython3.9? Can it not work with libpython3.10? 17:43:18 It is the default option 17:43:47 Oh & Python 3.9 is the default version right now. Build your own otherwise 17:44:23 I currently kludged around with libmap, but. . . 17:45:23 DEFAULT_VERSIONS+= python=3.10 python3=3.10 (in /etc/make.conf) 17:46:12 Already there. . . though I should change to 3.11 18:00:18 Interesting AMD Ryzen 5 hangs on 13.2, fine on 12.4, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267782 18:00:21 Title: 267782 – AMD Ryzen 5 hangs on 13.2, fine on 12.4 19:42:25 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? 19:42:54 Here's my loader.conf: https://bsd.to/xDrU/raw and here's my sysctl.conf: https://bsd.to/ZzQo/raw - anything abnormal, weird, absurd, abusive, naughty? 19:42:56 Title: xDrU 19:49:58 these days, loading modules in kld_list is usually favoured over loader.conf 19:51:36 (though you do have to be a bit careful about rc.d's rather nondeterministic order of operations) 19:59:49 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? 20:01:24 hm, do they default to zero? lemme check 20:04:01 looking at 13-stable I see them defaulting to 1 20:04:49 RhodiumToad: Under a fresh 13.2 installation (13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2), they seem to be default to zero.. 20:04:54 No? 20:06:40 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 20:10:11 did the default install create a sysctl.conf or loader.conf ? 20:11:49 RhodiumToad: Yes 20:11:59 Here both of them by the default, fresh 13.2: https://bsd.to/gqKD/raw 20:12:01 Title: gqKD 20:12:25 ok, so the default install turned them off in loader.conf 20:13:45 in the absence of a loader.conf they'd still be on by default 20:13:50 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? 20:13:51 overall 20:14:00 I see.. 20:14:13 I dunno, I disable dtrace entirely 20:22:15 <_xor> 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) 20:23:09 <_xor> I remember when dtrace was being added after Solaris showed it off and people saying, "Screw everything else, just use dtrace." 20:23:44 I actually build WITHOUT_CDDL since i'm not using zfs either 20:23:57 <_xor> Ah 20:24:18 <_xor> Oh yeah, that reminds me, I should check on that lib32 build. 20:24:59 * meena needs to move to a platform where lib32 isn't a thing 20:25:46 <_xor> omg, it built successfully and I thought "That's weird, I think." ...then I noticed that WITHOUT_LIB32=yes was set :| wtf 20:25:49 * _xor sighs 20:26:16 d'oh 20:26:26 <_xor> Before I forget, is it a rule that /usr/src and /usr/obj CAN'T be symlinked? 20:27:03 symlinking /usr/src makes the directory structure of /usr/obj a bit weird 20:27:16 <_xor> It failed if I symlinked it to a sub-dir into a NFS mount I have at /mnt/repos/... 20:27:20 I haven't tried it recently, it's much simpler to nullmount them instead 20:27:39 <_xor> That's what I tried next, for some reason that also failed, but it might have been something on my end. 20:27:42 (nullmounting them definitely _does_ work) 20:28:04 /usr/obj has to be not mounted noexec 20:28:09 <_xor> 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. 20:28:22 <_xor> Ah, that was probably it. 20:28:39 I don't recall if /usr/obj on nfs works, /usr/src on nfs definitely does work since i do that all the time 20:28:55 <_xor> Do you use ccache? 20:29:05 not at present, I do use meta mode 20:30:38 <_xor> 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. 20:31:14 right 20:31:21 <_xor> I also try to keep all mounts in /mnt and just symlink (or mount_nullfs) as-necessary to anything that requires outside of /mnt. 20:31:46 I leave /mnt for scratch mounts and have real volumes in /data/blah 20:31:48 <_xor> Hence the foul-up with the build. I just used rsync to and back for the time being. 20:32:56 <_xor> 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? 20:34:11 <_xor> 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). 20:35:45 no, pretty sure nothing depends on the exact paths. if so, it's probably a bug 20:36:18 but it's been long enough since I tried it that I can't be 100% sure 20:36:31 <_xor> 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. 22:32:11 <_xor> About to grab some food, but before I do, lib32 did fail... 22:32:42 <_xor> "Building /usr/obj/usr/src/amd64.amd64/usr.bin/ldd32/ldd32" 22:32:59 <_xor> "ld: error: cannot open /usr/lib32/libc.so.7: No such file or directory" 22:33:36 <_xor> 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. 22:40:29 huh. 22:40:43 that seems like a bug 22:43:14 a lib32/libc.so ought to exist in /usr/obj somewhere at that point 23:06:15 <_xor> RhodiumToad: https://termbin.com/cf5h 23:15:20 right, so it has no business trying to access the host environment lib32/libc 23:15:39 pretty sure that's a bug somewhere 23:16:09 but I don't know the src makefile infrastructure well enough to find it without spending a lot of time on it 23:18:34 <_xor> Yup, makes sense. 23:19:24 <_xor> 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). 23:20:03 <_xor> 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. 23:21:04 I always build lib32, so I've never noticed this happen 23:21:23 <_xor> 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. 23:22:07 * RhodiumToad grumbles about how meta-mode doesn't exactly help if something makes a trivial change to llvm, causing everything to be rebuilt 23:22:27 <_xor> Meta-mode having an effect also crossed my mind. 23:54:09 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? 23:57:34 Which VPS provider and which FreeBSD version? 23:58:09 V_PauAmma_V: vultr and 13.2 23:59:21 I am installing two, side-by-side, to analyze dmesg and check any differences 23:59:37 I already tries to install in UFS and ZFS. The result is the same.