00:24:39 oh wow, reading WindowMaker, I get a blast from the past 00:31:06 yeah, that was hot in 1998 00:32:14 I managed to cram everything into a Sun workstation case I picked up, so figured I should use a period-correct window manager :) 00:48:23 what is the equivalent to pam_env in freebsd? 00:48:51 (the shell agnostic environment variables thing) 04:28:24 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 04:30:13 sfox: Theoretically fixes are backported and quarterly is the more stable option. And aspirationally. 04:30:32 theoreticlly? 04:30:56 in my experience software stays broken when it's already been fixed in latest, like opensmtpd, crystal, shards 04:37:20 ye 04:42:24 you too? 04:42:46 i'm just a drgn 04:45:42 Obviously it doesn't work like it should. But fixing it seems better than defaulting to current. 04:47:52 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 04:56:47 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? 04:57:05 pairing is weird 06:17:34 https://reviews.freebsd.org/D43545 < - long awaited 06:17:36 Title: ⚙ D43545 WIP: sound: implement asynchronous device detach 07:47:53 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? 07:49:41 And why does FreeBSD constantly auto-remove ja-fcitx5-anthy? 07:50:32 Makefile for each port may have something in CONFLICT variable 07:52:20 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 07:58:34 ... via "pkg autoremove" 10:24:33 repost: Where can I find a list of well supported ARM SBCs? 13:11:18 Farooq, there's links here for your specific ARMvX architecture: https://www.freebsd.org/platforms/#_supported_platforms 13:11:19 Title: Platforms | The FreeBSD Project 15:04:23 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. 15:04:23 i can mount the share and create files, but unfortunately the script also wants to chown files to some arbitrary service user. 15:04:23 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 15:04:27 is there a quick fix? 15:07:49 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 15:08:21 (also, make sure nfsuserd is actually running) 15:09:05 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...) 15:09:33 i could recompile the kernel with v3 again, but i'm not in a good position to reboot the client machine (for reasons haha) 15:09:51 ok, i'd start by checking the domain then, that sounds a bit easier 15:11:29 okay, gimme a sec 15:12:23 Grabunhold_, can't load a module? 15:14:42 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 15:15:52 lw: okay, we went from "invalid argument to "operation not permitted" 15:16:25 The downside of NFSv4 is you no longer get to argue with neophyte firewall admins about the nature of RPC protocols. 15:16:25 Grabunhold_: does the user's uid match on both systems? that's still a requirement for non-kerberized nfsv4 15:16:47 CrtxReavr: but if you're using NFSv4.0, you can argue about the callback port! fortunately 4.1 removed that... 15:18:47 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 15:19:00 https://pastebin.com/Nct3KNU1 15:19:01 Title: /etc/exportsV4: /zroot/nfsroot -network 192.168.3.0/24/etc/zfs/exports/z - Pastebin.com 15:19:20 (the /etc/zfs/exports was generated by zfs set sharenfs) 15:19:22 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 15:21:27 lw: i just chown'd it on the server, that succeeded. it's now displayed with the correct username on the server. 15:21:27 but chowning it from the client still results in "operation not permitted", even if the chown wouldn't actually have to change anything 15:22:15 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 15:22:30 i'm chowning as root (on the client) 15:22:31 unless you are root, in which case check the nfs maproot option on the server 15:22:42 maproot=root? 15:22:55 i think so, yes, i've never tried allowing root access though 15:23:07 i think that did it 15:24:09 oh wow, i tried it for a user with a differing UID out of curiosity and even that worked correctly 15:24:16 local user id 1000, remote user id 1001 15:24:43 with NFSv4 that partially works but it will cause odd problems in a situation i don't remember off hand 15:24:50 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 15:25:28 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 15:25:53 i noticed that, too 15:26:14 (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) 15:28:48 i found this interesting tidbit on some mailinglist (that's why the formatting is so bungled) https://pastebin.com/WXjeuidD 15:28:49 Title: A lot of servers interpreted section 5.8 of RFC3530 to mean that client=s shou - Pastebin.com 15:29:25 interesting, i didn't know the server could control that. i wonder if that is, or should be a configurable option on freebsd 15:32:01 came from here: https://linux-nfs.vger.kernel.narkive.com/sq5nwqXz/nfs-v4-server-127-0-0-1-does-not-accept-raw-uid-gids-reenabling-the-idmapper 15:32:02 Title: "NFS: v4 server 127.0.0.1 does not accept raw uid/gids. Reenabling the idmapper." 15:34:30 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 15:38:47 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 15:39:10 CrtxReavr, Does this mean all aarch64 cpus are supported? 15:39:54 Farooq, I can't comment with any competance. I just know of the page. 15:40:44 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 15:42:25 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 15:43:00 Farooq, did you click on the links under 'TARGET_ARCH' and look at the specific hardware support? 15:48:33 i'm staring at the disk i/o and network i/o blinkenlights of the nfs server with joy :D 15:53:33 i saw someone was working on Marvell CN913x support at some point, i wonder if that ever happened 15:54:24 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. https://disfinite.org/Notes/FreeBSD/arm64/fbzfs 15:56:29 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 15:58:21 I've been booting RPi4's from gpt since I got one. I tried with an RPi3, but that didn't work. 16:03:55 is there an off topic freebsd irc channel? 16:04:33 yes, #freebsd-social 16:04:36 thanks 16:10:20 Anyway, the procedural notes are almost, but not quite, a shell script. 16:12:30 Hello 16:13:23 listening on IPv4 interface wlan0, 192.168.100.104#53 16:13:24 creating IPv4 interface wlan0 failed; interface ignored 16:13:37 How on earth is this possible? 16:14:12 The DNS server fell 16:14:49 and kept being as started and running 16:16:55 Need more context, I think. (I need to be away in about five minutes, but until then....) 16:17:26 tmp_: i guess wi-fi got disconnected 16:17:42 and in that point it tried to reassign ip 16:17:44 Does it still show up in ifconfig ? 16:17:57 s/it/wlan0/ 16:18:06 inet 192.168.100.104 netmask 0xffffff00 broadcast 192.168.100.255 16:18:18 i haven't done anything to wlan0 16:18:47 though, named was restarted. it didn't work but now does 16:18:58 but as for me this is not welcome 16:19:20 that is silently broken, from my point of view 16:19:24 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. 16:19:53 since the dns wasn't working, and i wasn't aware of that 16:20:16 i did: # service named restart 16:20:32 but until that no-no-no 16:20:45 no working DNS and this error message 16:21:21 presumably the network disappeared for a minute or several 16:23:07 # dmesg | grep rtwn 16:23:07 warning: KLD '/boot/kernel/rtwn.ko' is newer than the linker.hints file 16:23:09 rtwn0 on uhub5 16:23:10 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. 16:23:56 rtwn0: on usbus1 16:23:56 rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R 16:23:57 rtwn0: at uhub5, port 3, addr 3 (disconnected) 16:24:23 how is that possible that rtwn0 disappeared for some time? no idea, literally 16:25:56 Power supply hiccup? I've seen that hit usb devices, especially on unpowered hubs or devices fighting for limited supplies. 16:26:47 the electricity grid could be wonky these days... 16:27:16 though the power supply unit is very strong, in my opinion 16:28:05 could be connected with tragedy of Dniprohydroelectrics or something... 16:30:32 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. 16:31:46 usbconfig will tell you something about each device's current draw. 16:31:55 And I'm out of time. 16:32:51 sorry... okay 16:33:35 ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) 16:35:33 listening on IPv4 interface wlan0, 192.168.100.104#53 16:35:34 creating IPv4 interface wlan0 failed; interface ignored 16:35:46 I reattached to separate port 16:36:01 The DNS is not working, again 16:40:36 that's what i have, too 16:40:37 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. 16:43:36 how do i do that bind9 stopped losing interface completely, if that disappeared for a while? 16:47:10 how on planet could it help some person from the internet? Solved by enabling Code: allow-recursion { trusted;}; allow-recursion-on; in named.conf 17:13:34 can someone explain how do i use that explanation? 17:13:36 "bind drops privileges and loses interface | The FreeBSD Forums" 17:14:21 this one is exactly what i receive -> "One of the binding only lasts couple of hour until we have a message saying :" 17:14:32 "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" 17:14:53 though, i haven't seen permission denied 17:16:28 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." 17:18:07 what does this mean? "Solved by enabling Code: allow-recursion { trusted;}; allow-recursion-on; in named.conf" 17:21:05 https://bugs.launchpad.net/bugs/1796164 17:21:07 Title: Bug #1796164 “After interface/IP changes, bind9 can fail to resp...” : Bugs : MAAS 17:21:12 This also seems to be relevant 17:33:48 is interface-interval 0; 17:33:48 automatic-interface-scan yes; 17:33:55 supported on freebsd? 17:34:41 looks like the situation wasn't changed by these statements listening on IPv4 interface wlan0, 192.168.100.104#53 17:34:44 creating IPv4 interface wlan0 failed; interface ignored 17:41:48 CrtxReavr, yeah but the list there seems incomplete 17:46:36 I want to buy this and I wonder what features are supported: https://libre.computer/products/aml-a311d-cc/ 17:51:53 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 17:52:09 if ARM is not well supported, the other option is buying a cheap second hand x86_64 machine 17:52:50 Farooq: FreeBSD works fine on aarch64, but i don't know about the rest of the HW on there 17:52:56 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 17:53:21 the only reason I want BSD is to learn and experience different things. I'm mainly a Debian user 17:53:40 lw, dstolfa, A311D has mainline Linux support for 98% of hardware features 17:53:42 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 17:53:55 lw, sounds interesting 17:54:04 That's also what I thought too 17:54:49 But I haven't got experience with bare metal programming 17:55:03 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 :( 17:55:05 I've bought a cheap STM32 to get started with Rust no_std programming on it 17:55:40 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) 17:55:59 lw: i think you'll find arm is more standardized sadly 17:56:15 dstolfa: that's a shame, i thought perhaps riscv would have looked at what happened with arm and tried to avoid it 17:56:25 i'm sure riscv will get there, it's just not there yet 17:56:33 RISC-V SoCs are too weak ATM 17:56:54 I've heard if you emulate RISC-V on x86 it'll be MUCH faster 17:58:26 I have many dreams to achieve. One of them becoming a part time no_std developer 17:58:41 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 17:58:59 man Ampere is cool but 3000 17:59:05 I'm looking for sub 100 17:59:12 yeah, that was my reaction too 17:59:32 i might mail arm@ about the SolidRun stuff this week because that seems like a good option for mid-range arm 17:59:44 SolidRun is the name? 18:00:11 It's from Israel 18:00:13 solidrun is the vendor https://www.solid-run.com/ they make boards based on a few different SoCs for both desktop/server and network use 18:00:13 I'm from Iran 18:00:15 Title: Proven Embedded Edge Computing & Network Solutions | SolidRun 18:00:35 They might execute me for buying from Israel 18:01:40 ah i can see that being awkward, i didn't know they're in israel 18:01:58 Farooq: yeah, definitely do *not* take that risk for an soc 18:02:56 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 18:03:08 on second thought it's very promising might be worth the risk :D 18:03:19 I either live and have a cool SBC or die 18:03:51 I'll keep a finger on the Esc button to pause the game anytime I sensed danger 18:28:57 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 18:28:57 requests it gets. 18:34:18 Farooq: If you go the RPi4 route, there's at least one case for it that's built to act as a heat-sink. 18:35:05 i have one of those (the FLIRC case), it works pretty well, idle temp is ~38C compared to ~52C with no heatsink 18:35:15 so ~14C of cooling 18:35:33 V-T60: 'interface-interval' and the like aren't specific to any platform. 18:36:23 lw: Yeah, I'm working with multiple RPi4's in FLIRC cases. Two of my own and a bunch of clients. 18:37:28 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 18:37:57 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 18:38:21 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. 18:38:40 tmp_: for me interface-interval 0; didn't help 18:38:48 but allow-recursion and allow-recursion-on helped 18:38:53 set on trusted 18:39:05 with trusted being localnets; localhost; 192.168.100.0/24; 18:39:18 so wlan0 can't reply to query, but lo0 is active perfectly fine 18:39:47 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. 18:40:25 i guess 127.0.0.1:53 accepts instead of 192.168.100.104:53 18:40:56 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 18:41:35 (talking with words i can explain this) 18:41:40 i totally checked it 18:44:25 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. 18:46:32 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. 18:47:14 tmp_, libre computer alta already has a heatsink 18:52:26 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)? 18:53:14 I can extract it from geom, if nothing else, but that takes some work to incorporate in a script. 18:53:23 tmp_: perhaps something involving sysctl kern.geom.conftxt? 18:54:16 % sysctl kern.geom.conftxt|awk '/PART ada0p1 / {print $15}' 18:54:17 516e7cb5-6ecf-11d6-8ff8-00022d09712b 18:54:23 Nice! 18:55:23 tmp_: yeah, that's correct. i also thought of interface-interval being set to 1, but haven't tried 19:11:55 If you're on -CURRENT, you should probably check this: https://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. 19:11:56 Title: March 2024 stabilization week 19:13:38 debdrup: i've been meaning to try that, although i only updated src yesterday... maybe i'll check it out 19:13:48 i guess it's better to update at the *end* of the week though :-D 19:28:01 lw: that kind of defeats the point.. :P 19:28:42 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 19:29:04 (which = more bugs found in general) 19:30:52 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. 19:31:58 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 19:32:11 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. 19:32:13 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 19:33:03 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. 19:33:16 ..oh, I said that. 19:33:25 Brain tired. 19:33:50 lw: if there are obvious bugs, they'll likely have been fixed before stabweek. 19:34:00 (Term coined by Glen, but it amuses me) 19:35:18 debdrup: if it's not more stable at the end of "stabilisation week" then what's the point? 19:35:28 Judging by https://lists.freebsd.org/archives/freebsd-current/2024-March/005785.html, the week may end early. 19:35:31 isn't the whole point to iron out obvious bugs to produce a 'stable version' of -current 19:36:01 lw: there's a subtle distinction between "more stable" and "as stable as it gets".. 19:36:34 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. 19:36:37 I assume you remember INO64? Stuff like that _will not_ be introduced during stabweek. Does that make it make sense? 19:36:49 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 19:37:03 otherwise it would be equally stable at all times 19:37:18 lw: no, because that implies that it's unstable when stabweek isn't in effect, which isn't really the case. 19:37:40 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 19:38:03 or, at least, that people have *confirmed* it's currently "quite stable", fsvo 'quite' 19:38:08 Your decision. Ultimately, if stabweek gets more people using -CURRENT, that's great. 19:38:22 It's not necessarily something I'd claim everyone should do, though. 19:38:44 The point of stabweek is make it easier to test FreeBSD. 19:39:07 is it? or is it to make it easier to use -current in any situation (desktop, server, ...)? 19:39:12 or, i mean, both 19:39:49 https://lists.freebsd.org/archives/freebsd-current/2024-February/005657.html 19:39:50 Title: FreeBSD CURRENT stabilization cycle 19:40:14 I was just looking for that. :D 19:41:47 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 19:46:31 i'm trying to use daemon(8) to run a shell script as a service... what am i missing here? https://www.le-fay.org/tmp/30d/HblyJP.txt 19:46:45 the service is running, so i don't know why stop is complaining 19:48:27 ah, it's because i set procname= in the rc.d script 19:50:30 It'd be excellent to have https://docs.freebsd.org/en/articles/rc-scripting/ updated with a section on how to use daemon(8)... *hint hint* 19:50:31 Title: Practical rc.d scripting in BSD | FreeBSD Documentation Portal 19:50:57 sure i'll put it at position #372 on my list of things to fix in freebsd :-P 19:51:58 that page could do with a rewrite in general, it has like 3 pages of consequetive 'Notes', kind of hard to read 19:56:26 debdrup, funny you mention that. Refreshing it has been on my to-do list for ages. 21:23:54 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 21:23:58 er, wrong channel!