oh wow, reading WindowMaker, I get a blast from the past

yeah, that was hot in 1998

I managed to cram everything into a Sun workstation case I picked up, so figured I should use a period-correct window manager :)

what is the equivalent to pam_env in freebsd?

(the shell agnostic environment variables thing)

Is there a reason freebsd defaults to quarterly ports instead of latest? It's not like fixed are backported to quarterly. it seems more like just a snapshot of the tree every quarter

sfox: Theoretically fixes are backported and quarterly is the more stable option. And aspirationally.

theoreticlly?

in my experience software stays broken when it's already been fixed in latest, like opensmtpd, crystal, shards

ye

you too?

i'm just a drgn

Obviously it doesn't work like it should. But fixing it seems better than defaulting to current.

i just want to know how to set my expectations. Fixing the problem with latest and then backporting it seems like a lot of extra work most maintainers aren't going to do

Is there a better way to use a bluetooth headset with freebsd then running a bunch of terminal commands every time i want to connect it?

pairing is weird

reviews.freebsd.org/D43545 < - long awaited

Title: ⚙ D43545 WIP: sound: implement asynchronous device detach

Why is it that I somehow can't have fcitx5 and fcitx5-qt installed at the same time? And why does fcitx5-qt install zh-fcitx5 as a dependency?

And why does FreeBSD constantly auto-remove ja-fcitx5-anthy?

Makefile for each port may have something in CONFLICT variable

ja-fcitx5-anthy might have been installed as a dependency; after that something had been removed, nothing depends on it; so ja-fcitx5-anthy gets removed. One thing you could do is install ja-fcitx5-anthy yourself; then it will be marked as not-autoinstalled for "pkg" to not remove it

... via "pkg autoremove"

repost: Where can I find a list of well supported ARM SBCs?

Farooq, there's links here for your specific ARMvX architecture: freebsd.org/platforms/#_supported_platforms

Title: Platforms | The FreeBSD Project

hey guys, i've got an nfsv4 server going on some old hp mini i had floating around and set up as a freebsd machine to temporarily provide some storage to my linux desktop box for a script i'm running.

i can mount the share and create files, but unfortunately the script also wants to chown files to some arbitrary service user.

at the moment, all i get is "chown: changing ownership of 'testfile': Invalid argument" when trying to chown anything. i really don't care about security and just need this additional storage for a few hours before i will decomission the server again

is there a quick fix?

Grabunhold_: the quickest fix is to use NFSv3 instead, if that's an option. for NFSv4, i would start by making sure the NFSv4 domain is the same on both machines - for freebsd that's nfsuserd_flags="-domain example.com", not sure about Linux off hand

(also, make sure nfsuserd is actually running)

lw: i have a custom linux kernel going and iirc it doesn't have nfsv3 support any more, i didn't think i'd need it any more (v4 worked fine for me as long as i didn't need that chown call...)

i could recompile the kernel with v3 again, but i'm not in a good position to reboot the client machine (for reasons haha)

ok, i'd start by checking the domain then, that sounds a bit easier

okay, gimme a sec

Grabunhold_, can't load a module?

CrtxReavr: i'm in the middle of an upgrade and already got the sources for the next kernel onto the system, the old sources are gone... i could reinstate all that, but i always wanted to beat nfsv4 into submission

lw: okay, we went from "invalid argument to "operation not permitted"

The downside of NFSv4 is you no longer get to argue with neophyte firewall admins about the nature of RPC protocols.

Grabunhold_: does the user's uid match on both systems? that's still a requirement for non-kerberized nfsv4

CrtxReavr: but if you're using NFSv4.0, you can argue about the callback port! fortunately 4.1 removed that...

lw: i created a user with uid 250 on the nfs server for this purpose, but it seems it's more about the chown call being not permitted then about a missing user

Title: /etc/exportsV4: /zroot/nfsroot -network 192.168.3.0/24/etc/zfs/exports/z - Pastebin.com

(the /etc/zfs/exports was generated by zfs set sharenfs)

Grabunhold_: does the file have the correct owner on the server? if you created it with the wrong domain set, it might be owned by nobody or something like that

lw: i just chown'd it on the server, that succeeded. it's now displayed with the correct username on the server.

but chowning it from the client still results in "operation not permitted", even if the chown wouldn't actually have to change anything

oh, the problem might be unrelated to NFS - freebsd doesn't allow you to give away files by default (or possibly at all) so you might need to chown as root

i'm chowning as root (on the client)

unless you are root, in which case check the nfs maproot option on the server

maproot=root?

i think so, yes, i've never tried allowing root access though

i think that did it

oh wow, i tried it for a user with a differing UID out of curiosity and even that worked correctly

local user id 1000, remote user id 1001

with NFSv4 that partially works but it will cause odd problems in a situation i don't remember off hand

running "chown username testfile" as root from the client did "the right thing", locally on the client "ls -n" lists it as 1000 and on the server it's 1001

istm that NFSv4 was supposed to do away with the requirement for uids matching, which is why the whole domain thing exists, but in practice it only partially works in actual implementations

i noticed that, too

(iirc it's something like, you can create a file as a user, ls -l shows it's owned by you, but you can't actually access it as owner because the real uid doesn't match, which is even more confusing than how it was with NFSv3)

i found this interesting tidbit on some mailinglist (that's why the formatting is so bungled) pastebin.com/WXjeuidD

Title: A lot of servers interpreted section 5.8 of RFC3530 to mean that client=s shou - Pastebin.com

interesting, i didn't know the server could control that. i wonder if that is, or should be a configurable option on freebsd

came from here: linux-nfs.vger.kernel.narkive.com/s…aw-uid-gids-reenabling-the-idmapper

Title: "NFS: v4 server 127.0.0.1 does not accept raw uid/gids. Reenabling the idmapper."

lw: many many thanks for your help. this is the very first time (and i've been trying on and off every few years!) that NFSv4 is working for me outside of what's doable with "mapall=nobody" present

i know it's not optimal, especially from a security standpoint. but being able to simply have that old beat-up mini-server from the closet provide a few gigabytes of storage temporarily to a machine in need on my personal LAN w/o samba or kerberos is a huge boon

CrtxReavr, Does this mean all aarch64 cpus are supported?

Farooq, I can't comment with any competance. I just know of the page.

Farooq: it's definitely not the case that all AArch64 SoCs are supported, even if the CPUs are. i don't know of an up to date list off hand though

i'm still not sure if nfsuserd_flags="-domain mylan.example.com" actually needed the actual domain. i haven't set that domain up on the linux machine in any way except that it's provided by my dhcp server as the local domain. not sure if some systemd automagic somehow configured something that in the end allowed the nfsv4 client to to it's thing

Farooq, did you click on the links under 'TARGET_ARCH' and look at the specific hardware support?

i'm staring at the disk i/o and network i/o blinkenlights of the nfs server with joy :D

i saw someone was working on Marvell CN913x support at some point, i wonder if that ever happened

Worked up procedural notes on installing to zfs on RPi4s from a SD card image. The current version of the notes are for 14, with info about details not tried with 13.2 (which worked without some settings). So, yes, RPi4's can boot to an all zfs system. disfinite.org/Notes/FreeBSD/arm64/fbzfs

tmp_: i just did more or less the same thing here about half an hour ago. found some outdated information claiming rpi4 can't boot from gpt, but fortunately that turned out to be a lie

I've been booting RPi4's from gpt since I got one. I tried with an RPi3, but that didn't work.

is there an off topic freebsd irc channel?

yes, #freebsd-social

thanks

Anyway, the procedural notes are almost, but not quite, a shell script.

Hello

listening on IPv4 interface wlan0, 192.168.100.104#53

creating IPv4 interface wlan0 failed; interface ignored

How on earth is this possible?

The DNS server fell

and kept being as started and running

Need more context, I think. (I need to be away in about five minutes, but until then....)

tmp_: i guess wi-fi got disconnected

and in that point it tried to reassign ip

Does it still show up in ifconfig ?

s/it/wlan0/

inet 192.168.100.104 netmask 0xffffff00 broadcast 192.168.100.255

i haven't done anything to wlan0

though, named was restarted. it didn't work but now does

but as for me this is not welcome

that is silently broken, from my point of view

Hmm. I'm getting the impression the startup script assumes it needs to create wlan0, which would only work on boot, depending on the hardware setup and other things.

since the dns wasn't working, and i wasn't aware of that

i did: # service named restart

but until that no-no-no

no working DNS and this error message

presumably the network disappeared for a minute or several

# dmesg | grep rtwn

warning: KLD '/boot/kernel/rtwn.ko' is newer than the linker.hints file

rtwn0 on uhub5

I think figuring this out will dig into the named.conf rc.conf and possibly other things. Not sure just what's relevant at the moment. And, I'm getting called away.

rtwn0: <Realtek 802.11n NIC, class 0/0, rev 2.00/0.00, addr 3> on usbus1

rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R

rtwn0: at uhub5, port 3, addr 3 (disconnected)

how is that possible that rtwn0 disappeared for some time? no idea, literally

Power supply hiccup? I've seen that hit usb devices, especially on unpowered hubs or devices fighting for limited supplies.

the electricity grid could be wonky these days...

though the power supply unit is very strong, in my opinion

could be connected with tragedy of Dniprohydroelectrics or something...

I've worked with systems that provided 600mA to each pair of USB ports. USB 2 specifies that each device may need up to 500mA.

usbconfig will tell you something about each device's current draw.

And I'm out of time.

sorry... okay

ugen3.2: <Realtek 802.11n NIC> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

listening on IPv4 interface wlan0, 192.168.100.104#53

creating IPv4 interface wlan0 failed; interface ignored

I reattached to separate port

The DNS is not working, again

that's what i have, too

06-Jun-2017 00:00:01.127 error: creating IPv4 interface igb2_vlan200 failed; interface ignored If we restart our server it will bind "ok" for couple of hours until interface is dropped once again.

how do i do that bind9 stopped losing interface completely, if that disappeared for a while?

how on planet could it help some person from the internet? Solved by enabling Code: allow-recursion { trusted;}; allow-recursion-on; in named.conf

can someone explain how do i use that explanation?

"bind drops privileges and loses interface | The FreeBSD Forums"

this one is exactly what i receive -> "One of the binding only lasts couple of hour until we have a message saying :"

"06-Jun-2017 00:00:01.127 error: could not listen on UDP socket: permission denied 06-Jun-2017 00:00:01.127 error: creating IPv4 interface igb2_vlan200 failed; interface ignored"

though, i haven't seen permission denied

this part corresponds to my situation "If we restart our server it will bind "ok" for couple of hours until interface is dropped once again."

what does this mean? "Solved by enabling Code: allow-recursion { trusted;}; allow-recursion-on; in named.conf"

Title: Bug #1796164 “After interface/IP changes, bind9 can fail to resp...” : Bugs : MAAS

This also seems to be relevant

is interface-interval 0;

automatic-interface-scan yes;

supported on freebsd?

looks like the situation wasn't changed by these statements listening on IPv4 interface wlan0, 192.168.100.104#53

creating IPv4 interface wlan0 failed; interface ignored

CrtxReavr, yeah but the list there seems incomplete

I want to buy this and I wonder what features are supported: libre.computer/products/aml-a311d-cc

my goal is having a cheap BSD computer as a secondary one. ARMs are both new, fancy and efficient so I thought it might be the choice

if ARM is not well supported, the other option is buying a cheap second hand x86_64 machine

Farooq: FreeBSD works fine on aarch64, but i don't know about the rest of the HW on there

Farooq: ARM64 (ARMv8) in general is well supported (ARMv6 is deprecated, and ARMv7 probably will be before long) but the nature of ARM means that it's impossible to guarantee support for every random SoC

the only reason I want BSD is to learn and experience different things. I'm mainly a Debian user

lw, dstolfa, A311D has mainline Linux support for 98% of hardware features

part of the problem is SoC vendors usually only provide Linux support, so for FreeBSD someone has to sit down and test it and write whatever code is needed

lw, sounds interesting

That's also what I thought too

But I haven't got experience with bare metal programming

fwiw, the rpi4 works well with freebsd, the M1 Macs do not (but someone is working on that at the moment)... i was looking at the ClearFog devices recently but they don't seem to be supported :(

I've bought a cheap STM32 to get started with Rust no_std programming on it

if you're just looking for interesting hardware, freebsd does have RISC-V support and possibly things are a bit more standardised over there (? not sure though)

lw: i think you'll find arm is more standardized sadly

dstolfa: that's a shame, i thought perhaps riscv would have looked at what happened with arm and tried to avoid it

i'm sure riscv will get there, it's just not there yet

RISC-V SoCs are too weak ATM

I've heard if you emulate RISC-V on x86 it'll be MUCH faster

I have many dreams to achieve. One of them becoming a part time no_std developer

if you want fast ARM, FreeBSD does work well on Ampere, but i assume you're looking for something a bit smaller than that :-D

man Ampere is cool but 3000

I'm looking for sub 100

yeah, that was my reaction too

i might mail arm@ about the SolidRun stuff this week because that seems like a good option for mid-range arm

SolidRun is the name?

It's from Israel

solidrun is the vendor solid-run.com they make boards based on a few different SoCs for both desktop/server and network use

I'm from Iran

Title: Proven Embedded Edge Computing & Network Solutions | SolidRun

They might execute me for buying from Israel

ah i can see that being awkward, i didn't know they're in israel

Farooq: yeah, definitely do *not* take that risk for an soc

rpis might be available maybe? you will probably want to come up with a cooling solution and all that, but might be easy to get

on second thought it's very promising might be worth the risk :D

I either live and have a cool SBC or die

I'll keep a finger on the Esc button to pause the game anytime I sensed danger

V-T60: I'm back, sorry about the delay.... Looking back at what you added, I'm betting things based on 'allow-recursion' are completely unrelated to what you're running into. Access settings within named(8) cannot have anything to do with the existence of a network interface. The issue you describe is entirely in the category of the sheer existence of wlan0 and named(8) binding to it at all. Any internal 'allow' deals with what the service does with

requests it gets.

Farooq: If you go the RPi4 route, there's at least one case for it that's built to act as a heat-sink.

i have one of those (the FLIRC case), it works pretty well, idle temp is ~38C compared to ~52C with no heatsink

so ~14C of cooling

V-T60: 'interface-interval' and the like aren't specific to any platform.

lw: Yeah, I'm working with multiple RPi4's in FLIRC cases. Two of my own and a bunch of clients.

the only thing i don't like is you can't access the GPIO header without removing the thermal pad, which is annoying if you want to briefly attach a serial console or something

i need a new case for one rpi4 that has no cooling, i'm going to try something else for that and see if it works better

V-T60: I don't think setting 'interface-interval' to 0 would help though. That would make named(8) silent disconnect from wlan0 whenever it disappears/reappears. While still running.

tmp_: for me interface-interval 0; didn't help

but allow-recursion and allow-recursion-on helped

set on trusted

with trusted being localnets; localhost; 192.168.100.0/24;

so wlan0 can't reply to query, but lo0 is active perfectly fine

V-T60: As expected for interface-interval. But the 'allow' settings don't relate to connecting to an interface. Just what to do with data after it comes in. So the latter point to a different problem.

i guess 127.0.0.1:53 accepts instead of 192.168.100.104:53

though it was for 192.168.100.104:53, 127.0.0.1:53 has right to reply 192.168.100.104:53 query with such setting

(talking with words i can explain this)

i totally checked it

Okay. I'm just looking at the binding to wlan0 issue. From what you written, to phrase it as I understand it, the system boots, sets up wlan0, named(8) starts, binds to wlan0, and works for a while. Then wlan0 disappears(?) briefly, named(8) tries to reconnect, but can't and stays stuck disconnected until restarted.

How about 'interface-interval' set to 1. That would have named(8) rescan interfaces once per minute. Which seems kind of excessive, but it would give it a chance to actually reconnect less than a minute after wlan0 reappears. If my understanding of the problem is on the right track.

tmp_, libre computer alta already has a heatsink

Anyway, I have my own question for the crowd. Is there a tool to return the gptid if given a partition device name (such as da0p2)?

I can extract it from geom, if nothing else, but that takes some work to incorporate in a script.

tmp_: perhaps something involving sysctl kern.geom.conftxt?

% sysctl kern.geom.conftxt|awk '/PART ada0p1 / {print $15}'

516e7cb5-6ecf-11d6-8ff8-00022d09712b

Nice!

tmp_: yeah, that's correct. i also thought of interface-interval being set to 1, but haven't tried

If you're on -CURRENT, you should probably check this: lists.freebsd.org/archives/freebsd-current/2024-March/005782.html - it's the new system of stabilization week, and it's in effect as of this week; so now's an excellent time to update.

Title: March 2024 stabilization week

debdrup: i've been meaning to try that, although i only updated src yesterday... maybe i'll check it out

i guess it's better to update at the *end* of the week though :-D

lw: that kind of defeats the point.. :P

debdrup: isn't the point to encourage more people to use -current? i mean, great if people want to help find bugs, but even if they just update at the end it means more users for -current

(which = more bugs found in general)

lw: the idea is to let people have a point where it's "safer" to jump onto current or update current, because there won't be things like INO64 or other breaking changes.

debdrup: right, but from what i remember about Gleb's initial mail about this, at least part of the reason for doing all of this is to encourage more people to use -current, perhaps e.g. people who use 14-stable at the moment

I'm not sure how much benefit there is in updating at the end of the week, because -CURRENT is pretty darn stable as-is. This is more of a way to signal that during this week, it's as stable as it gets.

in which case it might make sense to encourage people to update at the end of the week, when the obvious bugs have been fixed

lw: sure, that was the stated goal - but it's not that -CURRENT is more stable during that time, it's that it's as stable is it gets.

..oh, I said that.

Brain tired.

lw: if there are obvious bugs, they'll likely have been fixed before stabweek.

(Term coined by Glen, but it amuses me)

debdrup: if it's not more stable at the end of "stabilisation week" then what's the point?

Judging by lists.freebsd.org/archives/freebsd-current/2024-March/005785.html, the week may end early.

isn't the whole point to iron out obvious bugs to produce a 'stable version' of -current

lw: there's a subtle distinction between "more stable" and "as stable as it gets"..

lw: Got dragged into a call just before checking your sysctl suggestion. Now that I've taken a look at it, that returns the raw partition type.

I assume you remember INO64? Stuff like that _will not_ be introduced during stabweek. Does that make it make sense?

i don't understand what you're saying at all... if it's "as stable as it gets" then it must be more stable than it was at some other point

otherwise it would be equally stable at all times

lw: no, because that implies that it's unstable when stabweek isn't in effect, which isn't really the case.

i don't consider stable/unstable a binary. -current is generally stable, but at the end of stabilisation week, i'd expect it to be *more* stable than it normally is

or, at least, that people have *confirmed* it's currently "quite stable", fsvo 'quite'

Your decision. Ultimately, if stabweek gets more people using -CURRENT, that's great.

It's not necessarily something I'd claim everyone should do, though.

The point of stabweek is make it easier to test FreeBSD.

is it? or is it to make it easier to use -current in any situation (desktop, server, ...)?

or, i mean, both

Title: FreeBSD CURRENT stabilization cycle

I was just looking for that. :D

in any case though it's a good idea and i'm glad someone is putting the effort into making it work, i hope other developers will get on board too

i'm trying to use daemon(8) to run a shell script as a service... what am i missing here? le-fay.org/tmp/30d/HblyJP.txt

the service is running, so i don't know why stop is complaining

ah, it's because i set procname= in the rc.d script

It'd be excellent to have docs.freebsd.org/en/articles/rc-scripting updated with a section on how to use daemon(8)... *hint hint*

Title: Practical rc.d scripting in BSD | FreeBSD Documentation Portal

sure i'll put it at position #372 on my list of things to fix in freebsd :-P

that page could do with a rewrite in general, it has like 3 pages of consequetive 'Notes', kind of hard to read

debdrup, funny you mention that. Refreshing it has been on my to-do list for ages.

so i decided to ditch OSPF for this and use BGP... next problem: the BIRD documentation doesn't seem to match the actual software... "next hop self" is documented but not accepted

er, wrong channel!