new files

What creates them?

quickwit a search engine that's run by daemon in a rc script

but wait it's the -o option of daemon

so i guess daemon does

Quoting from daemon(8), "-o" paragraph: "If the file does not exist, it is created with permissions 0600." daemon(8) can't know what will go into the file, so has to be prudent. If you want the file world-readable, touch it before running daemon so it exists.

i was even reading the man page don't know how i forgot that!!

does anyone else have problems fetch packages from the official pkgbase repo for 14.0?

i can fetch from my own (locally compiled) pkgbase repo, but not from the official pkg.freebsd.org mirrors

pkg update -f -r base works

but pkg fetch -o /tmp -r base FreeBSD-clibs fails

it dies with an exit code != 0 but doesn't write any errors to stdout/stderr

does it make sense for a pid file to be +x?

No.

crest: there definitely seems to be an issue on aarch64, not sure about amd64

meena: are you getting the same behavior on aarch64?

e.g. pkg install failing with exit status 21 without an error message

crest: gist.github.com/igalic/162ddc534e4141cffdf4dd36b13556b5 this seems bad.

Title: gist:162ddc534e4141cffdf4dd36b13556b5 · GitHub

looks like at least some official pkgbase repo mirros are broken?

crest: so, this machine is in germany; lemme try my local amd64 vm

I've change mac address of a freebsd machine using ifconfig_vtnet0_alias0 and now I have too lines in ifconfig: ether and hwaddr. Which one will be broadcasted ?

never mind,that's already up to p6

meandrain: it should be the one you set

arp show the ether one ... so it seems to be ok

meandrain: iirc ether is the active one an and hwaddr is only displayed if ether has be changed to make it posssible to still track the interfaces by their hardwired default mac address

nice

meena: so you're most likely hitting the frankfurt pkg mirror by default

crest: if i switch to a different mirror, the error is the same.

meena: i see the same problem

so I reckon the issue is with (14:)FreeBSD:aarch64

not just aarch64

i'm unable to pkg update -r base with the example base.conf from the wiki

let's start a thread on pkgbase@?

sure

you said you're getting the same issue? on amd64?

I update my CURRENT dev VM every other day, and it doesn't have that issue

also lists.freebsd.org/archives/freebsd-pkgbase/2024-April/000398.html

Title: Re: FreeBSD kernel version 0

if bapt@ says this is the one and only correct fix and it won't be fixed by restoring the old pkg behaviour that means it will take an errata release to get the fix into releng/14.0

crest: agreed.

I can't seem to get .login_conf locale working

I set the charset to UTF-8 and set the locale to en_GB.UTF-8 and nothing...

I have generated the db too

I run locale as my user, and I still get C.UTF-8

I have restarted my laptop and also relogged in

Did ypu log out and back in?

yes

OK

Tbat looks like a more-coffee-than-I-have-in-my-bloodstream problem.

damn... anyone else got any ideas on what I could try?

i may be late to this whole conversation (true statement, very little coffee) is locale in userland apps NOT taking over from your .login_conf?

voy4g3r2: I set them in .login_conf, then generated the db, then rebooted and relogged in, nothing... running locale I can still see C.UTF-8 is the locale

does locale -a show en_GB? or just C?

voy4g3r2: both of them are elements of them yes

if I grep the list, they will both appear

(with en_GB having different charsets too)

could you put your locale output in dpaste.org please?

voy4g3r2: dpaste.org/ouinx

Title: dpaste/ouinx (Python)

you said you updated the .login_conf, is that located in your $HOME dir and once you do that you rebuild the database with: cap_mkdb

cap_mkdb $HOME/.login_conf (whereever you have it)

SHOULD set the en_GB for that user and leave the system wide configuration intact

voy4g3r2: yes I did that

want me to dpaste that?

sure

I've moved a FreeBSD 10.x running machine into bhyve, but now I get this: pastebin.mozilla.org/rp8Ofua8 Any idea how to find the problem ?

Title: Mozilla Community Pastebin/rp8Ofua8 (JavaScript)

meandrain: you move a FreeBSD 10.x install to a newer FreeBSD host? upon moving this machine to a bhyve instance, you are receiving the above message?

yes

the host is 14.0

Let's say, that I send an unrelated TCP packet with RST or ACK flag set to a FreeBSD server. Such packet will get dropped. Is there a counter for example under /proc or visible with for example netstat, which counts such dropped packets?

meandrain: how is your bhyve? do you have debug=on for the image? does that give more details for you?

no, I will do that

I don't know how to enable debug in bhyve

find your .conf file for the bhyve instance and add an entry like this...

Title: dpaste/ypdZy (Bash)

this is a configuration for a -CURRENT bhyve instance but the focus should be the last line

this is my bhyve start script: pastebin.mozilla.org/nTtecdee

Title: Mozilla Community Pastebin/nTtecdee (JavaScript)

oh crap, i use vm-script sorry

so my option won't work, i forgot about that

my issue might be the bhyveload line ... the -d part

because I am not using zfs

well I am using zfs zvol for drive

i am looking through man bhyve_config

there is a way to link the gdb to the bhyve image

crest: okay, i *am* seeing the issue on amd64, too

mrtnt: blackhole(4) has a couple MIBs for sysctl(8) that let you tweak exactly how the blackholing works, but I don't believe there's a counter as such. However, FreeBSD will generate syslog messages if it spikes above 200, then limit it to 200. To find out the source, you'll have to use tcpdump or an IDS/IPS - the latter of which can be achieved by setting up a monitoring port in ipfw using the tee

rule, that you can then probabilistically filter using dummynet.

crest: gist.github.com/igalic/b566c56b251486576ea7b36b3bc230ee

Title: gist:b566c56b251486576ea7b36b3bc230ee · GitHub

meena: which pkg version are you running?

1.21.2?

mrtnt: siftr(4) might be worth investigating, though.

crest: 1.21.2, which just updated

crest: see, i usually start my PkgBase upgrades with: pkg upgrade -r FreeBSD pkg

1.21.2 was committed on 2024-04-23 to ports

voy4g3r2: dpaste.org/dHsCN

Title: dpaste/dHsCN (Python)

siftr(4) is quite interesting, and I wish more people knew about it.

but i don't know how fast (or slow) the arm64 builders are

ohhh the indexing is wrong

neovim isn't displaying it though

crest: would be nice to see a comparision

between what?

polarian: isn't there the `lang=` missing?

ridcully: hehe

yes...

thanks for pointing it out

crest: like, where is the build-queue between the different arch's builders.

meandrain: i would get the gdb options going for your bhyve, unfortunately i do not know EXACT syntax (man bhyve_config) and see if it gives yuou more details.

yea, I'll try to catch a kernel dump

voy4g3r2: thank you!

debdrup: thanks, I'll check the siftr(4)

voy4g3r2: I solved the problem, I kind of had a feeling that I've messed up with rsync of older files over newer os. So I delete everything new from the partition and rsync older machine to a blank partition, the restored boot. And now I can mount the root in bhyve

nice!

if you have the data on a zfs , i have found great success with zfs send and zfs recv

it is "quicker" than rsync .. but awesome

polarian: everything good from your side?

i got a slew of meetings coming up and will be going dark

voy4g3r2: yup

it works now

apart from claws-mail not detecting the locale :/

its still trying to load C dictionary for hunspell (which I dont have)

polarian: awesome, the hunspell may or may not be related but progress is always good

I hotswap removed and re-inserted a disk in my zfs pool, now it shows as removed

diskid/DISK-PHYF117400FZ1P9DGN REMOVED 0 0 0

its name used to be da56

I see in the logs that da56 was properly seen by FreeBSD

try zpool replace

and if I do zfs replace -f diskid/DISK-PHYF117400FZ1P9DGN da56

it errors out with: /dev/da56 is part of active pool 'ssd_bkp'

err

zfs replace -f ssd_bkp ..

zpool status

probably u need -f or clear disk manually (with dd for example)

Title: dpaste/krpD (Plain Text)

without formatting…

I did use -f

I haven't written to the zpool since I removed/inserted the drive

I really need to wipe it clean before trying again ?

last1, try: zpool attach ssd_bkp da55 da56

maybe add -f

I mean: zpool attach -f

yeah, that's what I ended up doing

attach, have to resilver, etc

not ideal :|

ye

and then detach diskid/DISK-PHYF117400FZ1P9DGN

meena: did you catch the discussion on the pkgbase list about the changes in pkg 1.21?

crest: nah, i was staring at broken pytest output all day

f/window close 14

ugh, sorry

autojoin add

autojoin add --run

i got a pf block out going on. any way i can sniff what protocol it is and stuff about the connection attempt?

See pflogd(8).

is there a preview of release notes (or something to that effect) for 14.1 anywhere?

Not yet, that I've seen.

how can i say where fetch should dl a file to?

-o then absolute path?

So the manual page says.

hm didn't work

jexec -l testjail fetch -a -o /tmp/file.zip https://...

running that in a scripted bsdinstall fwiw

wait nvm

ya it did work my bad

I'm coming from mostly GNU/Linux experience. For elevating privileges, is it reasonable to install the sudo package and allow members of "wheel" group to elevate? Or is there are reason to only $ su - into root and do things therein?

I use sudo and wheel group membership as you mentioned. Others prefer doas instead. I would say both are reasonable approaches.

Thanks V_PauAmma_V

only embers of wheel group can su to root, so the direct difference is about if you know root password or not.

s/embers/members/

Thank you, I was curious if that pattern was a "no no" or somehow not appropriate to FreeBSD

For managing packages, if I do # pkg update; pkg upgrade, as well as # freebsd-update fetch and # freebsd-update install , does that bring my machine fully up to current?

managing updates***

Sorry I guess I shouldn't say "current" since I understand that to be a different thing in this context. I just want to know how to patch a machine so it is fully up to date with regard to security patches to the system, any libraries, packages, etc

This would be a 14.0 install

`freebsd-update fetch install' is for the base freebsd system, similar to RHEL's `dnf update' without any additional repos enabled/installed

the pkg update upgrade commands you mentioned are for pre-built packages, yes

What "pkg upgrade" gets you to depend on whether you're using quarterly packages or latest packages. (Quarterly is the default, but sometimes security fixes don't make it to it until the next quarter.)

s/depend/depends/

Thank you both

See wiki.freebsd.org/Ports/QuarterlyBranch.

Thank you. Regarding that point about security fixes not making it into the current quarter, would best practice be to target "latest", say in the case of having something edge-facing... a web server for instance?

Like if I were deploying a public-facing nginx instance and want to keep it as secure as possible with regard to any library updates

Steeve: in my opinion, that's not a simple yes/no question

but if you believe the latest is the safest, then yeah you'd probably want the latest possible updates

Understood, thank you

Problem with "latest" is the constant churn, which can increase your workload if you need (or want) to check each update for breaking changes, which sometimes happen, depending on upstream's stance on backward compatibility.

Yes makes sense

Thank you both, appreciate the input

V_PauAmma_V: are missing security updates in quarterly really a thing then? i've always been a bit suspicious about running it but didn't have any specific examples

markmcb: freebsd.org/releases/14.1R/relnotes - but there's nothing there

Title: FreeBSD 14.1-RELEASE Release Notes | The FreeBSD Project

the releng branch hasn't even been created yet, relnotes can't really happen until then someone people are still pushing new changes to stable/14

lw, from my own experience of late 2019, soon after switching from PC-BSD to FreeBSD, there was a security update to sudo that didn't make it to quarterly. That's when I switched to latest. Since then, I've occasionally seen people complain about relatively few security updates being applied to quarterly - whether because maintainers don't request them, committers don't apply them, or both, I can't

say.

lw: thanks. i recall prior to 14.0 there was a non freebsd site that had lots of detailed notes on what was coming. seemed fairly informal, but it was insightful.

Was that Phoronix by any chance?

to be fair, everything on that site looks informal

'informal' is certainly one way to describe it

I think the harsher words I want to use aren't permitted in this channel. "be civilized" being in the /topic and all :)

failed to chown ... bad file descriptor <- what can cause that over and over in a jail during pkg install ...?