anexit: delete old snapshot

hm, i think 361a8395f0b0e6f254fd138798232529679d99f6 "routing: do not allow PINNED routes to be overriden" has broken my network config

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

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

i dont know what im doing to get there so i can stop doing it

it doenst happen with any other os in vi

Sounds like something with the qemu keyboard interface because there is no particular problem with :q! otherwise.

i usually spam esc so ill try only hitting it once

Trying to ESC from qemu?

ba dum tss

debdrup: latest firmware from ~ 2 weeks ago, 2806, seems to have mostly addressed my disconnecting drive failure

hi …

running freebsd 14.0-RELEASE-p4 and want to upgrade to 14.2 …

do i need to install 14.1 first or can i direct update 14.0 -> 14.2 ?

thx for answers

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

ivy: thx for the info …

nb, i don't use freebsd-update, so possibly someone else has more informed answer :-)

sentor: I recommend rustdate.over-yonder.net its much faster, in ports

dch: interessting … I will look to that ↑

"[freebsd-update is] a fork/exec stress test that sometimes has the side effect of leaving you with an upgraded system" :D

sentor: yesterday i did upgrade 14.0 -> 14.2 and ended with good results

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:

/usr/include/c++/v1/__algorithm/copy_move_common.h:18:10: fatal error: '__string/constexpr_c_functions.h' file not found

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?

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++

although it would be odd to have that problem and not notice until now, unless you just didn't compile anything recently :-)

I didn't compile anything recently

let me see if i can find the bug

And yes, I think I did use freebsd-update to go from 13 to 14 a year-ish ago

well the EN is at 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

(maybe just deleting /usr/include/c++/__string and running freebsd-update again fixes it?)

oh, /usr/include/c++/v1/__string

__string is completely missing. But maybe I can move /usr/include/c++ out of the way?

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.

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

worth a shot i suppose

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.

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)

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

got it

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:

ld-elf.so.1: /lib/libcxxrt.so.1: version CXXABI_1.3.11 required by /usr/local/bin/transmission-daemon not found

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.

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

if i null-mount /tmp in a jail while having host's /tmp on tmpfs, would then jail's /tmp be tmpfs too?

:q

angry_vincent: yes

but better if not to nullfs mount, but to `mount -t tmpfs tmpfs /path/to/jail/tmp` directly

egwynn, I forget the details but there was an errata for that. unpack the relevant bits of base, the errata has the details 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

dch: oh, thx

test

test

woof woof

dch: it looks that i can use: exec.created="mount -t tmpfs tmpfs /path/to/jail/$jailname/tmp" in jail.conf

angry_vincent: yep, this is the sort of thing I use here

thx!

note the guard to test, these aren't perfect but it reduces the number of stacked mounts

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

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