luke_jobless_sb, If it was helpful than great! But for me it was just a Today I Learned thing about FreeBSD. Or almost learned.

It turns out that resolvconf is still being called to overwrite /etc/resolv.conf with DHCP acquired nameservers.

I think probably it is being called through the DHCP pathway. I think if converted to a static IP assignment that it will stop. Will find out in a moment.

But I had to jump afk and am gone again. It's Halloween evening here and stuff is happening.

you can also write protect the file, that way stuff like resolvconf can't even if it wanted to

htwo things... 1. lists.freebsd.org/archives/freebsd-questions/2024-October/005910.html who is responsible for the freebsd website info? 2. anyone interested in the sidenote on that email (London BSD meetup/miniconf), please PM :D

(sorry for bumping ML stuff here, it doesn't feel like anyone uses the ML anymore)

polarian, visit #bsddocs on irc.efnet.org

CrtxReavr: ugh... another IRC network?

Well, it's um. . . a lot older than this one.

One could argue it's the original IRC network.

CrtxReavr: why are they on a different IRC network than here anyways

seems counter-productive

Why are we here, would be a more valid question.

well efnet.org the first thing on the landing page is they had a data breech

I could tell you, but it would not be rays of sunshine.

sooo

thats seems lik ea starter

why does freebsd make it so difficult to speak in the right place, they have 101 mailing lists for god knows what... which nobody actually posts to... OpenBSD misc@ may be chaos but at least I know where to stick stuff...

I think I should use both sqlite and postgresql in a same environment. I remember there was some stuff I had to be careful. Do you know any?

It's definitely down the DHCP path that updates /etc/resolv.conf even if resolvconf has been disabled.

If one sets a static IP address then it does not overwrite it.

luke_jobless_sb: i don't see any reasons why one would need to be careful with both of those

rwp: do you not want your resolv.conf to change, depsite using dhcp client?

I started the setup using DHCP but it is going to replace another server with a static IP. So eventually it is going to have a static IP.

Therefore no, I did not want it to be overwriting the /etc/resolv.conf file as I was configuring it.

Of course I could set schg making it immutable. That's a long time honored method. But I knew I would eventually have it statically assigned and until then would just put up with it messing with me.

I also figure that eventually I will figure out what's down the dhcp path that is ignoring the configuration to not use resolvconf and then fix it.

i would just set supercede domain-name-servers in your conf file but if you want to use the schg hammer sure

The only reason not to use schg is if there is a yet bigger hammer.

But better is that I actually understand what's down the DHCP path that is causing it to ignore the configuration. And understanding it there is probably a way to do it anyway.

do any VNC servers handle copy and paste between the guest and the host? I have a bhyve running Linux and I connect to the UEFI vnc using tiger vnc on a mac. it works great but not being able to cut and paste between the mac and linux sucks

It's been a few years since last running VNC with anything, I ran tigervnc at the time, but I recall being able to copy and paste between the VNC frame and the native X frame.

iirc dhclient has always updated the resolv.conf

I'm a very documentation driven person. If the docs say to do something in a certain way then I do something in the documented way.

And conversely if the docs say that configuring something with X causes behavior Y then I expect that doing X will cause Y.

In /etc/default/rc.conf it says <<resolv_enable="YES" # Enable resolv / resolvconf>> and if YES enables then NO must disable. Right? That's the document contract.

It's failing that contract. Therefore I consider it a bug.

Is it a really bad bug? No. Is it a showstopper bug? No. I can deal with it. But it is failing the contract.

remember, write protection solves it permanently

the whole need for resolvconf is to allow several possible services alter, and it's not alone so

resolv.conf, resolvconf which has reseolvconf.conf

plumb the depths as you please, however

the only more extreme method is using a sdcard and disallowing writes altogether!

got a file-backed /dev/md0 that reports its busy & won't `mdconfig -du md0`

- checked `fstat |grep md0` and `mount md0` which have nothing

and found that I forgot to `zpool export` it

lesson for future me!

I created a jail and I'm trying to start samba inside it but I get many errors, one of them is "ld-elf.so.1: Shared object "libgnutls.so.30" not found, required by "liblibsmb-samba4.so"

s2r: How did you install samba in the jail, and how are you starting it?

vkarlsen I used pkg install

s2r: Is everything up to date? Are you missing gnutls?

did you get a warning at the pkg update step about versions mismatches? you might need to freebsd-update

I created it usind cbsd. Can I run freebsd-update inside the jail?

Don't do it from inside the jail

Run it on the host with the -j <jid> param

vkarlsen, will try right now

Check the actual version inside the jail first

14.1p5

So the ABI should be the same.

That should be fine

"Could not create kernel backup directory"

I'm finding that my system is loading the linuxulator's kernel modules overnight, even though I'm not intentionally using anything that relies on them.

Anyone experience something like this?

What's the best way for me to figure out what's causing the modules to be loaded?

rafe: The kldload man page has a section on the autoload of modules that might be helpful. You might also want to grep for "linuxlator_load=", or: kldload linuxulator

linuxulator_load= rather

FreeBSD 14.2-STABLE is out, time for release party !

for real? :o

freebsd.org/releases/14.2R/schedule - ohh the beta's coming out today

mzar: use the correct terminology please. Release is still over a month away

i'm in my excited state regardless! a new release means the potential for newer hardware support.

right now freebsd and ghostbsd support everything on my Dell Inspiron 15 except the wireless NIC. i'll keep reading and try to get the Linksys WUSB6300 dongle working.

TyphoidTed: indeed... thats especially true for my non-x86/64 arch world

I don't run anything in x86/64

Even my current 2 FreeBSD boxes are ARM64

Tenkawa: 14.2-STABLE is released

FreeBSD 14.2-STABLE (VBSD) #52 stable/14-n269449-46d30932876f: Fri Nov 1 08:20:26 CET 2024

Tenkawa: so you don't run any 32-bit x86 machines either?

mzar: that is "not" the release build...

RELEASE builds begin

29 November 2024

-

14.2-RELEASE builds begin.

Tenkawa: that's not RELEASE, just STABLE being released

Incorrect

I am kidding you NOT

because there would be no need for

RC1 builds begin

22 November 2024

-

First release candidate.

that

nope

why would you do betas and rc's... "after" stable.... that's pointless

Tenkawa's right. the development branch for it has begun and the 1st beta is to be released today. that's all.

one can build BETAs or RCs, but when you follow stable/14 then you go short path

mzar: I did this for a living...

OK, same here

i tried...time for my walk

have a nice walk TyphoidTed

mzar: I do see why its named that way... poor naming conventions..

Be back later too.. Need to work on an arch (RV) that FBSD is still way behind on.

Tenkawa: the naming convention is the same since the early beginning ;-)

back. and ty mzar :D

When egrep is CPU-bound. . .

correction. X -configure pukes bunnies in kernel space, but startx just works.

ober: That's kind of expected since "X -configure" hasn't been recommended for years now.

Well, as far as I remember anyway.

ek, IIRC you pointed me to a patch to fix a memory issue which caused a slowdown after some period of runtime? Thanks! That helped hugely!

I believe that patch is now in RELEASE just normally now.

However, it helped a lot but I just thought I was mention in passing that things are still not as good in 14 as in 13. I never noticed any problems in 13. In 14 even with that memory issue fix things still periodically chunk up for which restarting Firefox and also rebooting immediately restore performance too.

I think there is still yet another issue hiding in there somewhere.

ek: good to know. thanks

rwp: Glad I could help! Shame you're still seeing issues, though.

morning

ek, Things are definitely hugely improved! No doubt! It isn't as bad now as initially. And bad now is just more like 15% as bad as the previous pauses. Things are better. I just think there is at least one more issue hiding in there somewhere. Anyway, THANKS!

good afternoon luke_jobless_sb. sorry to see you're jobless rn.

Does anyone knows if the FreeBSD summit will be live broadcast ? freebsdfoundation.org/news-and-even…t-calendar/fall-2024-freebsd-summit