00:05:53 anexit: delete old snapshot 00:33:35 hm, i think 361a8395f0b0e6f254fd138798232529679d99f6 "routing: do not allow PINNED routes to be overriden" has broken my network config 00:34:51 it used to be possible (at least since november) to configure a /64 on one interface, then configure the same address as a /128 on lo0, which is a bit unusual but useful in niche situations 05:20:32 im running freebsd in a qemu vm. sometimes when im done with a vi file i hit ESC :q! but i get stuck in some weird purgatory and i just have to fiddle to get out 05:22:23 i dont know what im doing to get there so i can stop doing it 05:22:38 it doenst happen with any other os in vi 05:26:41 Sounds like something with the qemu keyboard interface because there is no particular problem with :q! otherwise. 05:29:45 i usually spam esc so ill try only hitting it once 10:28:39 Trying to ESC from qemu? 10:39:00 ba dum tss 14:33:51 debdrup: latest firmware from ~ 2 weeks ago, 2806, seems to have mostly addressed my disconnecting drive failure 14:33:58 * dch is happy again 14:56:39 hi … 14:57:03 running freebsd 14.0-RELEASE-p4 and want to upgrade to 14.2 … 14:57:42 do i need to install 14.1 first or can i direct update 14.0 -> 14.2 ? 14:58:06 thx for answers 15:02:57 sentor: 14.0 to 14.2 should be fine. the only time an intermediate upgrade was needed was to 14.0 from 13.x due to a freebsd-update bug 15:05:02 ivy: thx for the info … 15:13:39 nb, i don't use freebsd-update, so possibly someone else has more informed answer :-) 15:14:13 sentor: I recommend https://rustdate.over-yonder.net/ its much faster, in ports 15:19:20 dch: interessting … I will look to that ↑ 15:35:26 "[freebsd-update is] a fork/exec stress test that sometimes has the side effect of leaving you with an upgraded system" :D 16:18:40 sentor: yesterday i did upgrade 14.0 -> 14.2 and ended with good results 16:28:34 I just upgraded from FreeBSD 14.0 to FreeBSD 14.2 with freebsd-update. Since doing that, I needed to install a port and it failed with the following error: 16:28:40 /usr/include/c++/v1/__algorithm/copy_move_common.h:18:10: fatal error: '__string/constexpr_c_functions.h' file not found 16:29:29 It seems like that should be part of the base system. But freebsd-update isn't saying there's anything else to install. freebsd-update IDS doesn't say it's either. How should I repair my system? 16:29:41 egwynn: did you previously update from 13.x to 14.0? if you did that with a particular buggy version of freebsd-update, it broke your /usr/include/c++ 16:30:08 although it would be odd to have that problem and not notice until now, unless you just didn't compile anything recently :-) 16:30:17 I didn't compile anything recently 16:30:24 let me see if i can find the bug 16:30:38 And yes, I think I did use freebsd-update to go from 13 to 14 a year-ish ago 16:31:25 well the EN is at https://www.freebsd.org/security/advisories/FreeBSD-EN-23:12.freebsd-update.asc but it doesn't tell you how to fix an already broken system, hmm 16:32:00 (maybe just deleting /usr/include/c++/__string and running freebsd-update again fixes it?) 16:32:13 oh, /usr/include/c++/v1/__string 16:32:22 __string is completely missing. But maybe I can move /usr/include/c++ out of the way? 16:35:56 I did mv /usr/include/c++ /usr/include/c++.old; freebsd-update fetch install; # No updates needed to update system to 14.2-RELEASE-p2. 16:36:30 egwynn: you may need to grab 14.2's base.txz from a download mirror, extract it and manually put a correct copy of /usr/include/c++/v1/__string into place 16:37:20 worth a shot i suppose 16:50:57 ivy: that seems to have unstuck things a bit. Kinda sad that freebsd-update wasn't able to put the system back together on its own though. 16:51:41 egwynn: freebsd-update is kind of... not very good (no slight on Colin, i think he'd probably agree, which is why it's being replaced by pkgbase) 16:51:51 I've diff'd the extracted base's usr/include with the host's /usr/include and found some other differences but I'm not 100% sure whether to take action right now on them 16:52:03 got it 16:55:28 Another thing: I installed the latest transmission-daemon in a jail (and have recently upgraded the jail using ezjail to 14.2). But the latest binary package of transmission appears to be ABI incompatible with the jail's base system. I get this when I try to restart it: 16:55:29 ld-elf.so.1: /lib/libcxxrt.so.1: version CXXABI_1.3.11 required by /usr/local/bin/transmission-daemon not found 16:55:57 Best I can tell this is also a problem with how the base system is installed, and probably not a problem with the package itself. 16:57:12 If I do `strings /lib/libcxxrt.so.1 | grep CXXABI` I don't see 1.3.11 in the jail, but I do on the host system 17:25:22 if i null-mount /tmp in a jail while having host's /tmp on tmpfs, would then jail's /tmp be tmpfs too? 18:58:15 :q 19:04:43 angry_vincent: yes 19:05:14 but better if not to nullfs mount, but to `mount -t tmpfs tmpfs /path/to/jail/tmp` directly 19:07:42 egwynn, I forget the details but there was an errata for that. unpack the relevant bits of base, the errata has the details https://people.freebsd.org/~dch/posts/2021-02-23-sideloading-freebsd may be helpful too, esp the exclusions around `tar xvzpf ./base.txz` half way down 19:15:53 dch: oh, thx 19:30:20 test 19:30:52 test 20:03:54 woof woof 20:10:45 dch: it looks that i can use: exec.created="mount -t tmpfs tmpfs /path/to/jail/$jailname/tmp" in jail.conf 20:12:03 https://www.irccloud.com/pastebin/JuGSzyvZ/jenkins.conf 20:12:18 angry_vincent: yep, this is the sort of thing I use here 20:12:32 thx! 20:12:52 note the guard to test, these aren't perfect but it reduces the number of stacked mounts 23:44:03 i get a lot of synfloods on my current server (not bsd) that even when they aren't actively taking my server down, over time they cause my ping times to get progressively longer and longer 23:45:00 with freebsd, hopefully i would be fully immune to something like that, but even so, is there a "quick" easy way to basically fully reset the TCP IP stack? like drop all connections and start accespting them again clean as if I had just rebooted, but without ACTUALLY rebooting