00:49:28 kevans: does bootstrap flua have modules now? re: https://reviews.freebsd.org/D56266 02:49:17 ivy: yes, we can force bootstrap flua to get consistent behavior as needed 02:50:09 okay, i'll see if i can get that in for 15.1, but unfortunately that still means you can't build 15.0 on 16, unless perhaps we EN the change... 02:50:53 moderately annoying because des flagged the libucl default change as potentially problematic and i forgot to follow-up 02:51:02 weeks before it landed 02:55:00 let me see if i can get bootstrap flua working for packages, that would mean we can avoid the problem in 15.1 and if it's only 15.0 that's affected, it's not so bad. although not ideal 02:56:14 looking at Makefile.inc1, it looks like I got it all into place except for adjusting the BOOTSTRAPPING checks 02:56:41 though with something like pkgbase using it, it's light enough that it might be better to force bootstrap flua all the time 03:22:36 kevans: we also don't know if the user will be building packages during the bootstrap phase, so i think it's much simpler to always bootstrap it 03:25:47 right 03:26:51 i'd at least say that we should bootstrap any of the modules that work with vendored libs, since their behavior is more flexible in ways that we might not like, though the whole set beyond that isn't huge 04:38:28 kevans: how do i actually use the bootstrap flua? if i just do 'flua generate-ucl.lua', it can't find flua, since it's in usr/libexec 07:43:07 doesn't have generate-ucl.lua a proper shebang? 08:30:28 Cheerio! I've some audio trouble. When playing audio the sound is tinny and low. It is a Realtek ALC285. Dmesg shows two pcm on that card both labeled (Internal Analog). I believe I read a post that the reason is some propriery amp not being used. Trying to bypass the speakers and connecting headphones does not work. sysctl shows a nid for Headphones that is disabled. Adding that nid to devices.hint as 08:30:34 headphones and seq=15 doesn't enable it. Not sure how to continue at this point. 08:32:55 oh, just to make sure. The pin is "dev.hdaa.2.nid33" and I added 'hint.hdac.2.nid33.config="as=1 seq=15 device=Headphones"' to /boot/device.hints. Is it correct with hdaa in sysctl and hdac in device.hints? 08:54:24 Oh, it was supposed to be hdaa in device.hints. The Headphones work now and have good sound. The laptop speakers however don't... yet at least. 10:55:16 nimaje: it has #! /usr/libexec/flua, but that will use the host flua, not the bootstrap flua 11:12:07 ah, then probably use the full path to the bootsrap flua libexec is for executables that just shouldn't be in PATH as they have special purposes 11:14:52 bootstrap usr/libexec is in ${TMPPATH} in Makefile.inc1, but i'm not sure setting PATH="${TMPPATH}" is the right way to do this - oddly i can't find anything else that actually uses bootstrap flua 11:24:58 the problem with hardcoding the path is you then can't run the target without bootstrapping, which we do usually support 11:25:00 I meant like ${TMPPATH}/usr/libexec/flua generate-ucl.lua then 11:27:00 hm, so the hosts flua should be used if you aren't bootstrapping currently? 11:29:39 fwiw, i'm not trying to solve this myself, i'm asking kyle what the actual correct/standard solution is :-) 11:30:15 for testing, PATH="${TMPPATH}" seems to work 11:35:16 kevans: does this look more or less right? https://people.freebsd.org/~ivy/tmp/bsflua.diff - obviously i'll remove the commented out bits, and also just merge ${_flua} into where it's used instead of having a variable, unless you think there's a good reason not to 11:49:42 ivy: yeah, that LGTM- for `make sysent` I setup this _sysent_PATH so it can use flua from the host if we didn't bootstrap it for some reason, but I think it's fine for this in particular to not do that 11:50:58 in particular, you need to have built world beforehand anyways, so we shouldn't have to worry about the bootstrap version not having been built 11:51:17 thanks. i'll need a different solution for D56087, which i was hoping to land this week, but that can wait :-/ 12:39:30 is anybody here familiar with overlay filesystems? 12:39:46 like overlayfs, unionfs and aufs? 12:40:24 is it possible that I create a blank .iso/.img file and make it grow on demand as I populate it? 12:40:39 KNOPPIX is doing that as it seems but I don't know how 13:23:59 /s 13:24:01 oops 13:46:06 ivy: FWIW- I think for bsd.pkg.mk, I'd do something like: FLUA_PATH?= /usr/libexec/flua, invoke generate-ucl.lua with that, then override it in Makefile.inc1 to the TMPPATH version 13:46:31 Is this a user support channel, or if not, is there such a thing on irc? 13:47:12 ivy: IMO we don't have to guarantee that one-off package builds at that granularity has to be completely bug-free, as long as the sanctioned path to a full repository is- we can document caveats for the former along the way 13:49:48 kevans: i was thinking to add /usr/libexec to the end of .PATH, but using an explicit variable is probably neater. and yes, i think it's fine to use the host tools if you do a single-directory make, i think that's how most of src works anyway 13:50:02 you shouldn't really be doing that if the host doesn't match src anyway 13:50:33 *nod* 13:50:57 I don't think either approach is strictly wrong here 13:52:42 (mostly just wanted to throw out an idea in case you didn't have any at the moment and didn't want to shoulder the entire burden, since I can't really commit to a patch at the moment) 14:25:06 My current problem #1 is "error installing partcode on partition nda1p1" which I understand means the system will be unable to boot. 14:25:42 What can I do about it? Is there a way within the installer shell to install a bootloader, if this is what I need? 14:25:45 joepublic: "partcode" sounds like a BIOS thing - if your system supports UEFI, try selecting UEFI instead of BIOS+UEFI in the installer 14:26:07 I don't recall it asking anything about UEFI or BIOS... 14:26:20 it's an option during the disk setup dialogue, iirc 14:26:28 will try. thank you. 14:26:38 it doesn't actually ask explicitly, but there's a bunch of options, one of which is boot code type and the default is BIOS+UEFI 14:26:51 (at least, iirc... it's been a while since i ran the installer) 14:29:59 yeah, the installer defaults to BIOS+UEFI (at least that was the case for 14.3) 14:32:26 I am partitioning manually as an almost completely new-to-freebsd user and undoubtedly I am doing something wrong. Running through it again to see if I can get a working config. Don't see a q. about BIOS or UEFI though. 14:32:53 what partitions did you create? 14:35:54 freebsd-boot x2 (one on each ssd), freebsd-ufs (/), freebsd-ufs (/home), freebsd-swap, freebsd-ufs (/data) 14:37:41 this time through, no error about partcode, but the result still doesn't boot. 14:38:30 does your system support UEFI? in that case, you don't need a freebsd-boot partition, you want an 'efi' type partition (around 256MB) which is formatted as FAT 14:38:37 so you are installing on a BIOS system? for UEFI you need a FAT partition 14:38:59 i would strongly suggest using guided partitioning, which will set this up for you and still lets you change/resize the data partitions 14:39:31 The system supports UEFI, but the partitioner tells me I need a boot partition. Maybe the way I am booting the freebsd iso is the problem, I am booting it with ventoy 14:40:50 I'll make a dedicated usb stick for FreeBSD and try again, with guided partitioning. 14:44:32 My secondary problem is that it is not recognizing my Realtek RTL8125 2.5GbE network adapter 14:49:51 that one lands in 16 i think. you can try net/realtek-rge-kmod 14:50:34 noted; thanks, will do once I get the system installed. 14:51:37 yeah, that 14:57:41 I appreciate the help, and have successfully installed FreeBSD with the partitions looking like I want them to. Thanks. 15:00:29 joepublic, Here is a reference you might find useful: https://klarasystems.com/articles/the-freebsd-boot-process 15:00:58 I like how all of the different boot configurations are described. 15:02:30 joepublic: if you want to try the new rge(4) driver for your realtek card, you can download this and copy it over on a usb stick: https://people.freebsd.org/~ivy/tmp/realtek-rge-kmod-20260222.1500068~f232ddac47.pkg 15:02:47 install it with 'pkg install ' and follow the instructions it prints to edit loader.conf 15:05:39 i have repeated failure for www/node24 ( that is in poudriere ) - https://termbin.com/6do4 15:05:45 joepublic, I now see Ventoy in the above. It's probably confusing the installer. The channels for all systems are always full of people having problems using Ventoy installing. 15:06:19 well, it looks like hdr_histogram being broken , not node24 itslef. but node24 made depend on it to replace bundled one. 15:06:35 i only found: https://linux.die.net/man/3/be32toh 15:06:45 I made a FreeBSD usb stick from an .img file and used that instead of the ventoy, successfully. Thank you all. 15:07:19 And for me I have so many older used hardware with buggy UEFI that if it can boot Legacy BIOS then I always select it as it will reliably boot when UEFI will need a helper such as reEFIng or another workaround for buggy UEFI boot firmware. 15:07:41 so, does it looke hdr_histogram library only looks for OpenBSD betoh32 defines? and not FreeBSD? 15:07:59 The link provided points out that you can't boot in BIOS mode from nvme drives, which appears to have been my ultimate problem 15:08:43 Me wonders what .img image because I always use a .iso image written to a USB flash storage and booted that way... But it is no longer important since you report that you have it working. 15:09:16 For the record it was FreeBSD-15.0-RELEASE-amd64-mini-memstick.img 15:10:10 rwp: hybrid .iso is simultaneously amazing and cursed, it doesn't always work 15:10:41 I am curious as to why not use that instead of FreeBSD-15.0-RELEASE-amd64-disc1.iso ?? 15:11:07 I didn't know the ISOs were hybrid, so I used an img file 15:11:19 kevans, It does not always work. It only works 99.44% of the time. But the mini-memstick has similar success failure rates too. Actually seems less reliable. 15:11:32 definitely not 99.4% of the time 15:11:42 depends on your firmware 15:11:57 it works reliably if your firmware doesn't get pissy about the image layout 15:11:58 (I always use 99.44 as a made up number. It's the advertised purity of Ivory soap.) 15:12:08 not all firmware agree with it 15:12:39 ventoy itself was booting in BIOS mode, and in turn booting FreeBSD installer in bios mode, so uefi options were not available to me. The FreeBSD stick itself booted in uefi mode and everything was/is happy. 15:13:36 Being a craphound I run a lot of repurposed used salvaged hardware and out of a dozen UEFI systems I have two that boot UEFI out of the box. The rest all need some type of bug workaround. But ALL of the Legacy BIOS booting systems boot without problem. 15:14:43 The HP workstations such as the Z200 series and Z400 series are the worst at UEFI. They all have problems. The only working UEFI systems are other random ones running Coreboot firmware which seems to work perfectly. 15:16:14 now my RTL8125 is working, but at boot it doesn't get an ip address, I have to run dhclient manually. What do I need to edit? 15:16:26 joepublic: put ifconfig_rge0="DHCP" in /etc/rc.conf 15:16:35 (assuming the interface is rge0) 15:16:37 So if you can manage to use hardware running Coreboot firmware then UEFI will probably work perfectly. If not then my experience has all been bad. rEFInd is a good workaround sometimes. 15:16:39 thanks much 15:20:11 rwp: i think that's probably specific to old systems. new systems pretty much always work fine with UEFI (mostly because they all use EDK-II, which is basically the reference implementation of UEFI) 15:21:05 and by new, i mean like... anything in the last 10 years, at least. your Z400 is pretty old, it shipped with Windows Vista 15:21:35 So joepublic what system hardware are you installing upon? A new system that is known to be UEFI working without problems? 15:21:56 It's a fairly new Aorus motherboard with a Ryzen 5 chip on it. 15:22:37 I never know what version of MS-Windows a system shipped with since I always install over the top of it. 15:23:49 specifically, an "X570 AORUS ELITE WIFI" 15:24:04 i do still use BIOS boot on one of my VMs, because the provider uses SeaBIOS which doesn't do UEFI... i complain to them about this every few months 15:25:22 no problems booting grub/debian via UEFI, wouldn't know about any other problems it has UEFI-ing. 17:31:19 Hello, all. Has anybody managed to bridge the main internet interface with an OpenVPN "tun" network? On my side, adding tun0 to the bride fails with: "BRDGADD tun0: Invalid argument (extended error Unsupported interface type)" 17:34:21 According to OpenVPN docs, I need to "NAT or bridge the TUN/TAP interface to the internet", I can't seem to bridge it... 17:39:46 ant-x: You create a bridge, and then you create tun/tap interfaces that attach to the bridge. 17:40:29 What command are you using to create the bridge? 17:40:50 OpenVPN has already created a tun0 interface that I am trying to bridge. Shall somehow interfer in the creation of tun0 by OpenVPN? 17:40:52 bridge is for bridging data link layer networks, tun is a network layer tunnel 17:42:24 OK. Then I have to learn how people manage to access anything (including the wide internet) via the tun interface. 17:42:56 ant-x: The bridge should be created first (on whatever WAN/LAN/whatever interface). Then tunN would be created within the bridge. 17:43:46 what is your goal? just using the tun interface for some routes? add them via route(8) 17:44:41 My goal is to connect from several devices over OpenVPN to my home PC, and route that traffica via a local SOCKS5 proxy form that server to another server, to bypass internet restrictions. 17:45:19 ek, so I must tell OpenVPN to create its tunN interface within an existing bridge? 17:46:45 so you want to use the openvpn server as your default gateway? you don't need a bridge for that 17:48:00 I can use the OpenVPN server as the default gateway on the client-side. But the problem is, nothing is reachable from inside that VPN. I am reading the docs for the "redirect-gateway def1 bypass-dhcp" setting. 17:48:03 ant-x: OpenVPN should be creating the bridge on the WAN/LAN/whatever interface you choose and then assigning tun devices/interfaces to each successful connection it receives. 17:49:23 So I need tap isntead of tun? 17:52:02 ok, so you have created the default route, but it doesn't work? what have you done to debug where the problem is? does the openvpn server see the packages but just not route them? 17:53:03 I have not understood the logs yet. Will analyse them and report (probably with relevant fragments). 17:53:26 ant-x: Are you following any sort of guide of just going off of OVPN's documentation? 17:54:19 and why did you think you need a bridge in addition to the default route? 17:54:34 ek, both. This guide: . 17:55:22 nimaje, because of the comment in the sample config file, saying that I need to "NAT or bridge the TUN/TAP interface to the internet". 17:59:16 ek, as distinct from the guide, I have no Firewall install so far where NAT could be configured. 18:01:10 ant-x: Well, knowing nothing about your topology or what kind of access you're trying to acquire over OVPN gives us our limitation on how we can assist. 18:01:31 Is this not a gateway/firewall/router you're installing this on? 18:02:14 Can you give us an idea of the topology layout so we know what you're trying to accomplish? Maybe a diagram or something posted to a pastebin? 18:03:12 It is a normal computer (a mini-PC actually) connected to the internet via my router. 18:03:14 bridge only works with tap, if you use tun you have to configure routing and probably NATing 18:03:51 nimaje, then that's my snag: I must NAT my tun interface to the internet, and I need a firewall (!) to do that... 18:06:18 ant-x: Yes. In the guide you linked to, they're using PF for the firewall/NAT. Follow that. 18:06:51 And, obviously, make sure the IP scheme you're using matches your networking needs. 18:07:35 you can also allocate some IP from your network to your openvpn client and configure the routing correctly then you can work without NATing, but that needs careful management of your network 18:08:47 Yeah. I've always tried to avoid that. 18:09:08 nimaje, via iptables? 18:09:08 Yes, I can use a different subnet mask 10.*, because my local network is 192.168.* 18:09:37 I must leave work. Will be back from home. 18:09:47 ant-x: You could also maybe try WireGuard instead of OVPN? A lot of people find that easier. Especially if they're not inviting strangers into their network. 18:41:34 I'm one who switched from OpenVPN to WireGuard 18:42:19 ek: its not only easier, its faster too 18:43:22 I use both. WG is faster. But, I don't like that the client decides what routes they can use/add. I much prefer that to be a server-side option. 18:44:08 I hope everyone is watching the Artemis II live stream (if they can)!? 18:49:57 ek: tbf it's still in the server's control, no? it doesn't have to route arbitrary traffic to/from the peer 18:54:19 kevans: From what I understand, it does. It's the responsibility on the server side to route/block traffic as you see fit. 18:54:32 ... which is fine. It's just more work on the server-side. 18:55:03 Just kind of opposite of OVPN's routing. That's all limited by the configuration itself. 20:21:11 ek, at this point my OpenVPN nearly works, so I'd prefer to get to some sensible stage with it, especially because WireGuard is said to be blocked here, and OpenVPN not. 20:21:55 ek, looking forward to watch the actual Moon landing. 20:45:28 ant-x: That's fair. It sounds like things should be working if the client is able to connect to the server. Is it just not routing? 20:45:48 Yes. 20:45:52 Have you set up the routing between 192.168/16 (or whatever) and 10/8 (or whatever)? 20:45:57 The client connects. 20:46:10 No, and I have no idea where and how to do it. 20:48:34 ant-x: It sounds like you're just missing the routing/NAT config. Using the guide you had mentioned, check "Step 4: Enable IP Forwarding and NAT". That should get you to where you need to be. 20:49:24 You may not need some of it, depending on what the requirements/scope may be. But, it should work. A quick look at the guide appears correct to me. 20:49:52 Obviously, adjust the IP's/subnets and network interfaces names to match your setup. 20:51:29 Yes, I will, if I fail to avoid NAT and/or the firewall. Is there no other way to link tun0 with re0 (my main internet interface)? 20:56:55 ek, thanks for reviewding that guide! 21:22:46 https://freebsdfoundation.org/blog/call-for-testing-introducing-the-laptop-integration-testing-project/ 21:28:42 OK. With pf and NAT, my OpenVPN connection can reach the internet. Now -- to forward its sever-end over a SOCKS5 proxy. 22:26:30 ant-x: Congrats! Glad you got it working. Sorry about the belated replies. I've been kinda hooked on this Artemis II mission stream. 22:26:56 One of my buddies worked on this project (code-wise) so I'm just enamored that things are going so well. 22:27:46 Good! 22:28:31 I am still on step two, though: no idea how to forward the server-side SOCKS5 proxy to the client side via pf rules. 22:32:35 ant-x: What proxy are you using? 22:33:10 A local (to the server) SOCKS proxy created by ssh -D . 22:33:23 It is on 127.0.0.1:6000 22:34:07 Now, when I connect to that server via OpenVPN, I need that proxy to be available to the client. 22:34:22 I think it should be doable via pf redirections. 22:35:20 My server-side OpenVPN subnet is on interface tun0, 10.8.0.0/24 . 22:35:43 And the SOCKS5 proxy, as I understand, is on interface lo0. 22:36:46 So, I think, I need a bidirectional redierction between 10.8.0.1:6000 and 127.0.0.1:6000 (where 10.8.0.1 is the addess of the server in the OpenVPN subnet). 22:38:08 Better still, I'd like to forward all VPN traffic via that proxy, but I failed to do so with proxychains, and am now trying to the proxy available to the client. 22:39:08 In other words, I am now trying to tunnel the server's SOCKS5 proxy over the OpenVPN connection. 22:55:22 Here what I have done: 22:55:26 pass in on tun0 proto tcp from any to 10.8.0.1 port 6000 rdr-to 127.0.0.1 por t 6000 22:55:26 pass out on tun0 proto tcp from any to 127.0.0.1 port 6000 rdr-to 10.8.0.1 por t 6000 22:55:51 s/por t/port