02:20:49 What are some good alternative browers for freebsd.. issue with Firefox so im looking elsewhere 02:32:32 Nvm install chrome via linux-installer 05:13:41 oxbar: chromium 06:11:49 how do i determine what version of freebsd i'm on? 06:13:37 uname -KU ? 06:14:38 i assume 1402000 means 14.2 06:17:17 my assumption is that it's something like that, but my assumptions have been wrong before 06:18:03 lol mine too, fair point 06:38:56 freebsd-version -kru (installed kernel, running kernel, installed userland) 06:40:35 neat 06:40:38 yup 14.2 06:41:49 i'm trying to make myself a 100% comprehensive guide to setting up a bsd web and mail server from scratch, so i can easily recreate the process and feel confident enough to ship out a collocated freebsd box 06:49:52 so i'm looking at the manual - the real manual - and it says you run pkg and that runs a baby pkg that actually installs the real pkg 06:50:10 is that still accurate, or does freebsd now come with the full real package manager already installed? 06:53:09 the problem with having pkg in the base system is that it would couple releases together 06:53:50 i appear to have the full pkg installed, and i'm trying to figure out if i installed it without noting it, or if its already there 06:54:31 pkg is not in base, you have to install it (by running the base pkg, which does that for you) 06:54:49 ok i must have failed to write that in my notes 06:58:03 well, it will do that automatically the first time you try to use pkg (it will ask you of course before installing anything, but not sure if it gives you more hints what is going on or if it just looks like when pkg updates itself) 06:58:36 yeah i must have done that already and not noted it 06:58:40 i'm going to start over and note it 06:58:50 i wonder how pkgbase will handle this, it would be weird that the tool to update base isn't shipped in base 07:05:31 this might be a question nobody knows anything about, HOWEVER 07:06:04 when i shutdown with `shutdown -h now`, the machine shuts down. But the hardware is a Mac, and it doesn't acutally power down the machine. It jsut sits there at like a dead prompt 07:06:12 is there a way to make shutdown also power down the hardware? 07:06:23 i have no idea if this will also be an issue on PC hardware 07:10:55 GoSox: you want shutdown -p, not shutdown -h 07:11:50 ahhhhh 07:13:00 confirmed 07:29:44 wow the drive formatting that freebsd uses, REALLY confuses macos 07:30:01 which isn't actually a problem, the real install will be on an HP server. but its kinda funny 07:40:37 anybody know how linuxlator decides what sound device to use? 07:41:08 I have sysctl hw.snd.default_unit=2 which works everywhere except linuxlator 07:42:44 oh crap, it looks like macos saw the hdd and ssd, and automatically turned it back into a fusion drive :/ 08:35:26 i feel like i could design a general purpose GUI for freebsd and other unix systems that could be good enough and polished enough that people could really use it for popular general computer use 08:35:31 i should get on that some day 09:08:46 GoSox, https://xkcd.com/927/ 09:08:51 :) 09:09:01 hah 09:09:33 i would make a GUI that is based visually on MacOS 8 from the 90s, but functionally based on peak Mac OS X from the mid 2010's 09:09:53 and then have some options in settings to make certain functions windows-like to make those people happy 09:10:14 i would be interested in seeing your work product in this regard 09:10:46 Wasn't there a bsd derived os with a mac looking gui? 09:10:48 i truly don't even know where to begin, and i don't see myself ever having time to do it. 09:10:51 hello something? 09:11:09 well macos itself is based on nextstep 09:11:22 and also there was BeOS way back when which ran on macs but was not macos 09:11:37 hello system 09:11:38 apple was going to buy it and make it macos, i forget the story but that never ended up happening 09:11:46 yeah, it's called helloSystem 09:12:16 never heard of that 09:13:48 said mac looking ui is called hellodesktop 09:15:03 ive seen a lot of "mac like" UIs and they problem is they all seem to focus on the cosmetic ways to look like macos, but they ignore the fore functionality of the desktop that we mac guys really care about 09:16:17 my point was that if this is something you want to do, maybe talking to those guys would be worthwhile, to avoid duplicating effort 09:17:07 if it ever happens, which is unlikely, i would specifically want to start my own thing from scratch, and do everything exactly the way i want. 09:17:12 but don't hold your breath 09:59:12 hello, which program do you use to scan for vulnarabilities? I'm already using pkg audit but I'm looking for something for programs not installed through pkg 09:59:43 ideal something like $> get_cve_for geoserver,mapserver,a,list,of,programs 10:45:20 Is it possible to use ftruncate to punch holes in memfd-backed memory in FreeBSD? 11:48:01 isnt memfd a Linux syscall which was ported to linuxolator (the Linux compat layer) 11:48:24 I dont know the low level very well 11:48:52 ivy: thanks will take a look :) 12:02:11 > The memfd_create() function creates an anonymous shared memory object, identical to that created by shm_open() when SHM_ANON is specified. Newly created objects start off with a size of zero. The size of the new object must be adjusted via ftruncate(2). 12:35:41 where scared to death, seeing this message post install of lsof: lsof: WARNING: compiled for FreeBSD release 11.1-RELEASE-p6; this is 11.1-RELEASE-p4. 12:36:28 after checking all versions found that this is the post message in the lsof package itself ... 12:36:31 https://www.freshports.org/sysutils/lsof/ 13:10:06 'lo world ! 13:11:30 From here (France - RENATER provider), we can't join www.freebsd.org with IPv4 (IPv6 is ok) 13:17:47 ping 96.47.72.77 does't respond, mtr stops to 96.47.66.42 (other providers in france are ok) 13:21:46 dgeo no problem from here. 13:26:57 LXGHTNXNG: I could have just man'd it, embarrassing on my part 13:27:26 I assume the freebsd memfd_create is different from the Linux one hence linuxolater implementing its own one? 13:37:24 Hi 13:38:16 i'm trying to use dlib-cpp under FreeBSD (through the PHP dlib wrapper) and I encounter trouble since PHP crashes at its end due to a callback of an "unknown" address during __cxa_finalize call 13:38:54 after trying to find the problem, it seems it comes from dlib-cpp. 13:39:22 with a simple example program (dlopen libdlib and dlclose and exit) it reproduces the crash 13:40:04 it seems that dlib register a callback function called during cxa_finalize which is not unregistered when dlclose is performed 13:40:20 i don't know how to debug that.. if someone has an idea? 13:40:29 runxiyu: for memfd (which is really shm_alloc(2) wrapped in libc), ftruncate just reserves swap and pages are allocated on write(2) except in case of superpage-configured memfd 13:40:33 iirc 13:41:13 polarian: interface is compatible, native one inspired by linux 13:42:24 but on freebsd we created a shm_open2 to support some of the extra properties that a shm wants and we wrap that in libc instead of implementing it as its own syscall 13:42:32 s/shm wants/memfd wants/ 14:04:34 nobody knows for my quesiton? 14:05:26 kevans: thanks 14:06:48 titou: can you throw up a pastebin or something with your simpler reproducer? 14:07:11 is bytecode affected affected by reciprocal tarrifs too ? 14:07:20 s/affected// 14:08:42 hmm using -j with pkg when the jail is a vnet jail causes it to hang on "Updating FreeBSD repository catalogue...", both the host and jail have network access... 14:09:25 "pkg: An error occured while fetching package" yeah it cant fetch them weird 14:09:28 kevans: here is a simple example which crashs: https://pastebin.com/edABC2hG 14:09:34 probably you have to manage VNET jails from the inside of the jail 14:09:38 if i remove the dlclose line, it works very well 14:09:59 mzar: possibly, it depends on how pkg -j is implemented 14:10:25 does it download the pkg on the host, and then install it into the jails path... or does it attempt to pull the pkg from within the jail 14:10:30 * polarian doesnt know :P 14:11:33 the benefits of VNET jails are overestimated 14:11:54 mzar: is it worth the added headache? not really 14:11:59 does it provide network isolation from the host? yes 14:12:05 does it provide layered network filtering? yes 14:12:51 but does this make a big enough security improvement to justify the headache and the longer setup? ehhhh 14:14:26 network performance gets degraded by VNET and more CPU cycles are needed, so it's also agains green computing, buy whocare 14:14:29 s 14:14:52 ok I can answer the question of where pkg is executed, its within the jail because I cant fetch from within the jail, but I can ping other hosts 14:14:54 weirddd 14:18:34 mzar: that is like saying IPv6 is more eco friendly because it does not require a nat 14:18:46 titou: oy, that's hairy 14:18:54 the amount of energy we are talking here is negligable 14:18:56 fraction of a watt 14:20:26 polarian: sure it is, ip6 doesn't require recomputation of checksums if packet is forwarded 14:21:20 kevans: do you have ideas about how to debug that? 14:21:49 do you guys know what happened to koobs ? I haven't seen him here since a while 14:22:07 mzar: we are talking about very little amounts of energy 14:22:34 OK, so let's reducy byteflow 14:22:40 *reduce 14:23:03 mzar: lets not bother with security features like encryption, it wastes cpu cycles too and slows things down 14:23:15 why bother with firewalls, all that packet matching takes cpu cycles 14:23:17 and slows down packets 14:23:48 it would be great to list the functions which will be called by cxa_finalize but I don't know how to access to this list without modifying the libc... 14:24:01 titou: the problem is that that's not an application problem 14:25:04 for sure... i'm afraid it's a FreeBSD libc bug? 14:25:12 libc/rtld, yeah 14:25:23 but why it only appears for this libray?! 14:26:23 this bug is documented since many years.. 14:26:30 (at least 5 yaers) 14:30:12 do you know somone / a mailing list which will be able to help me solving this bug? 14:31:07 I was trying to distill it down into a simpler test case, but it's not as cut and dry as it looked initially 14:33:59 kevans: why? 14:46:04 titou: basic __cxa_atexit stuff is fine, so it's not just a global object trying to do teardown, and dlib doesn't seem to be doing anything too crazy on its own at first grep 14:47:40 titou: I'd recommend hacking up a libc that prints what it's doing at __cxa_finalize time and try to get a feel for all of the cxa_func's that are running when you do not dlclose it 14:48:26 for basic global object dtor that gets a __cxa_atexit, we seem to be doing fine and everything looks good 14:48:59 :/ 14:49:00 so you're kind of looking for functions that are out of the ordinary in some way 14:49:27 it means recompile libc with debug enabled.. it's quite boring to do :) 15:02:31 polarian: one alternative is pkg -r $jail_root , with the repositories being configured in the host not the jail 15:03:09 jmnbtslsQE: ooo thats a cool tip, thanks... 15:03:26 the thing is I need http access within the jail... and I cant figure out why the packets are being dropped, icmp works 15:03:40 tcp is explicitly passed 15:03:45 but the host drops the resposne 15:03:46 if a connection can't be made, i'd think that's a firewall issue somehow 15:03:59 yeah but pf is stateful, why the fuck would it drop a response?? 15:04:07 I have one idea of what it could be 15:04:07 is a connection made? 15:04:13 jmnbtslsQE: yup 15:04:37 maybe it's an ssl problem, or an MTU problem (where the response is too large to fit in the MTU of one of your interfaces) 15:04:38 I tcpdump'd my router, the response reaches WAN, and I get the response back from WAN, and it is indeed passed to the host 15:05:22 hmm MTU problem is possible... its on a wireguard interface and I had to drop the MTU a while back because packets wouldn't pass via wireguard 15:05:31 I found 1325 was a safe MTU to ensure packets passed... 15:06:05 but to be honest, I dont this is MTU 15:07:06 it's something where there should be clues in tcpdump at various places 15:07:54 if a response packet doesn't make it through, it should be clear on tcpdump which is the last interface to see it 15:11:39 but it's also worth noting, technically the treatment of packets during the tcp handshake could be different from the firewall's standpoint than for packets once the connection is established 15:11:53 not sure how that would happen here there for pf 15:11:59 though* 15:14:43 jmnbtslsQE: pf is stateful, if the packet passed originally, it will always pass, in fact it bypasses pf entirely in the network stack 15:15:07 which is why if you change pf rules you should also flush your state table 15:15:28 so the response *should* pass 15:16:34 pf does still see the stateful packets but if it has state for a packet it probably decide to not evaluate anything in the ruleset (don't remember) 15:17:02 indeed 15:17:12 there was a talk on it at fosdem which I watched 15:17:49 https://fosdem.org/2025/schedule/event/fosdem-2025-4306-a-packet-s-journey-through-pf/ 15:17:53 very good talk 15:18:16 OK 15:18:40 s/watched/attended/ 15:19:19 polarian: do you actually rdr your http packets to the jail? 15:20:15 SKull: this shouldnt be needed 15:20:48 if I put in an inbound rule for the jail interface this would affect non-stateful packets 15:20:49 polarian: that depends on the setup 15:21:09 the weird thing is ICMP passes which is really weird 15:24:36 so just doing user@host: curl fails? 15:25:14 where host is the actual jail host. 15:26:13 kevans: that's very interesting! I guess I got the trick.. 15:27:37 i'll try to make a simple example to recreate the bug 15:36:48 kevans: in fact for an unknown reason i can't reproduce __cxa_atexit is called during a call to a callback during __cxa_finalize which then is not called during this call (__cxa_finalize called during dlclose). Then it is called during the last __cxa_finalize call which is performed at the end of the process... 15:45:51 titou: libdlib pulls in so many other shlibs that I have to wonder if the problem is actually in libdlib or in one of the shlibs it pulls in 15:51:25 polarian: you can also optimise encryption and make it more green by the transition from RSA to ECDSA 15:51:57 titou: I trivially debunked that by trying the reproducer with all of the dependencies, so nevermind 15:51:58 mzar: imma just assume you are an eco extremist which fixates on small insignificant environmental issues, and misses the bigger picture 15:52:48 think of how wasteful the web is, and then tell me some security measures are too bad for the environment 15:53:57 polarian: I really don't care 15:54:32 then why comment on my use of vnet jails if you dont? 15:56:22 I like to stir the pot from time to time 16:32:51 > Trace/BPT trap 16:32:59 Ungoogled Chromium crashes 16:33:04 Any pointers to debug? 16:44:56 runxiyu: where'd you install it from 16:45:22 packages 16:45:22 yeah probably a packages vs ports issue again 16:45:52 if you make sure that all the dependencies are the right versions, using the right ABI and so on, and it still crashes, running it under gdb might provide some hints 16:46:01 although you'll probably need to rebuild the debug version with DCHECKs enabled for any more information 16:46:10 another worthwhile thing to check would be if regular chromium also crashes 17:40:58 titou: it's something about this thread_destruct_helper 17:41:12 threader_destruct_helper 18:41:06 kevans: in fact by hacking the libc i hit the problem into dlib. That's why i told you why it crashes 18:42:31 the problem come from calls to __cxa_atexit called into a callback called during __cxa_finalize. The new callback added by __cxa_atexit is not executed during the current __cxa_finalize call and stay into memory until __cxa_finalize is called with DSO set to NULL at the end of the procress 18:42:48 unfortunately the library has been unloaded from memory thus the callback doesn't exist anymore 18:44:20 this is due to a static class intance loaded during an "atexit" function which needs to call its destructor once it is no more used 18:44:29 the problematic line in dlib code is: threads_kernel_shared.cpp:49 18:46:29 titou: oh, sorry, I guess I misunderstood. that's a lot easier to write a reproducer for 18:48:03 i thought but i didn't succeed yet :) 18:48:24 the last thing is that it is easy to correct.. 18:48:42 but it needs to update the FreeBSD libc code.. 18:52:46 I succeed ! 18:52:50 hmm, I thought I had it, but it also crashes if I don't dlclose: https://people.freebsd.org/~kevans/atexit-repro.c 18:52:59 toss yours this way? 18:53:45 something like that 18:53:50 it's almost the same 18:54:40 the fact that your initial one doesn't reproduce without dlclose() may be a coincidence, I suppose 18:55:05 my example code works if dlclose is not performed and crash if dlclose is performed 18:55:21 it crashs the same way as the dlib one during __cxa_finalize code 18:55:31 i'll write it the same way as you 18:55:39 oh, I'm dumb. I recompiled the shared object again, not the non-shared bits 18:56:09 artifact of trying to write both into a single self-contained file to pass along easier :-) 18:57:52 https://pastebin.com/497zVc2m 18:58:08 but you got the trick! 18:59:09 in fact one of the easy way to solve this bug would be to execute again __cxa_finalize if more than one callback is called during the last __cxa_finalize 19:00:37 it also would be possible to set a flag which indicates that cxa_finalize should be called again if the DSO passed to __cxa_atexit functions is the same as the one currently in use during the __cxa_finalize call 19:01:22 i could try to write something 19:03:44 what's the idiomatic way to disable(in the same way as accompished by devctl disable ) a pci device during boot, before the modules in kldload list are loaded? 19:10:29 where should I send the buggy example program and the associated patch? 19:11:57 titou: throw it on bugzilla and send me a link 19:12:32 this is why: I finally got i915kms and xorg to work with my iGPU even when my dGPU(which causes a kernel panic when i915kms is loaded), but right now I have to manually run devctl disable pci0:3:0:0, then manually load the driver, then I can start the X server 19:12:42 obviously I'd like to do all of this automatically on boot instead 19:13:20 when my dGPU is present* 19:15:50 I got 19:15:50 nextcloud-php80-25.0.2 in 13.1-RELEASE in an iocage on TrueNAS. I upgraded it within nextcloud to 28. Now I want to upgrade it to nextcloud-php84-31.0.2. I'm not sure what that will do to the nextcloud databases. Also pkg upgrade wants to remove nextcloud. I would rather upgrade php8 to 8.3 or 8.4 to upgrade nextcloud within nextcloud 28 >29 > 30 > 31 I didn't want to risk dataloss or loss of the nextcloud database. 19:21:22 and also, for later, I want to do this in a way that doesn't stop me from attaching the device to bhyve later on, cause I wanna try to port the linux driver to FreeBSD, and it'd be nice to not have to reboot every time I test it 19:22:08 kevans: my patch solved the bug 19:25:31 floogy: performing upgrade from the CLI is advised 19:26:14 but you can try risky path if you have full backup of the database 19:27:28 floogy: what was used as database backend on TrueNAS ? 19:31:56 kevans: do you know which kind of component is concerned? kern? not sure.. 19:32:00 I think mariadb 19:32:00 well, the way stuff it handled currently for pkg nextcloud-php80 and nextcloud-php84 have nothing to do with each other, so it doesn't know that you would want to install nextcloud-php84 now, replacing nextcloud-php80 19:33:04 It wouldn't replace nextcloud-php80? 19:38:50 nextcloud is just a tarball, you extract it and run php script to upgrade 19:39:12 I have never been using FreeBSD package 19:43:16 titou: call it bin 19:49:43 kevans: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285870 20:12:00 does no one know how to do this? I would've thought it was a fairly simple thing to do, but I can't find the manpage that tells me how 20:28:31 mtll: i thought it was in the bhyve section of the wiki 20:29:18 https://wiki.freebsd.org/bhyve/pci_passthru 20:29:47 floogy: take a backup of both files and sql before doing anything 20:30:29 well yes, but right now I just want to know how to disable the pci device before i915kms is loaded by kld 20:30:35 I'll set up the bhyve stuff later 20:37:46 i believe it's the same approach 20:41:19 oic, nice, bit of a hack, but since I will be using it for bhyve anyway, an appropriate one, thanks 21:14:27 how to compile a port with a specific compiler (for instance gcc) ? 21:24:06 If you are writing the port currently and it needs a specific compiler USES=compiler https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-compiler USES=llvm https://docs.freebsd.org/en/books/porters-handbook/uses/#uses-llvm or USE_GCC=yes https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-use-vars and if you aren't writing the port, then why do you want to choose the 21:24:08 compiler? 21:49:55 nimaje: because the PHP wrapper use mangled C++ function names which are only compatible with the gcc output (for dlib-cpp) 21:51:32 but thank you for the answer 21:52:55 I would have expected that to come up when the port was written, not when someone tries to build it