01:34:57 Yay! I'm typing this on a t0430 running 14-Beta-1! 01:35:05 t-430 02:33:58 G'day. Where do I join a mailing list for testing FreeBSD 14.0-BETA1? 08:01:39 I want to rdr tcp traffic on port 80 to a machine on the internal network, so I set rdr pass on $ext_if proto tcp from any to ($ext_if) port 80 -> $internal_ip, however there is probably some networking "issue" because it wouldn't work and I suspect the problem is the machine where the traffic is rdr'd has a different default route, how could I overcome this? 08:08:33 DanGer: do you see the traffic on the outbound interface? tcpdump 08:08:55 and then do the same on the internal network machine, does the traffic even get there 08:09:34 if the default route is indeed the problem, you can add a more specific one to fix that 08:10:38 `route show $IP` will tell you whats being used 11:11:51 anybody using vm-bhyve here? I'm trying to switch to it. I successfully created a FreeBSD guest and installed it via the serial console. However, upon boot, the VM is stuck in state "Bootloader". I'm using the 'bhyveload' loader. 11:37:24 anyone in here running postgis with postgre 15? 11:48:04 drobban, I was running postgis a few years ago so probably won't have anything useful in my memory anymore 11:48:56 well, im new to freebsd, so I just wanted to make sure the packages I found is in fact only for postgresql 15. 11:49:11 sorry, postgresql 13.... 11:49:27 any given postgis package is built for exactly one postgres version, and it should be obvious from the package name 11:49:29 what OS? 11:49:40 freebsd... 11:49:44 oh 11:50:18 the packagename is postgis33. =D 11:50:21 the prebuilt package of postgis only exists for the default postgres version 11:50:33 so not sure how obvious that is, but okey. 11:50:48 yeah well, it's obvious on most OSes but not so much on freebsd 11:51:28 well. I just spun up a jail with 13 instead, so no worries 11:51:42 current ports tree has the default version as 15, are you using quarterly? 11:52:28 RhodiumToad, postgis33 seems to have postgresql13-server as dependency. not 15 (but I might be missing something) 11:53:00 jbo: from which repo? 11:53:21 RhodiumToad, head 11:55:44 ah, it was updated in ports only 3 days ago 11:55:58 which isn't enough time for the packages to have been rebuilt yet 11:58:59 it should be updated in the latest repo probably no sooner than about Friday 11:59:50 (and possibly a few days later) 12:00:07 package build times are quite ridiculous these days 12:00:54 quantity wise it's also exploding given that these days everything needs to be rewritten in rust 12:06:30 maybe if we didn't need to build rust every time we build a package that uses 3000 lines of rust it wouldn't be half as bad 12:07:13 ahh thanks for the heads up! im using quarterly 12:07:33 part of the problem there is that rust and its package manager build together, and the packager depends on curl, and curl gets a security update every other week or so 12:07:44 that ^ 12:08:16 RhodiumToad: it's not like it's bumping it's so version every other week tho 12:08:36 so even if rust itself were reasonably stable, you'd still be rebuilding it frequently 12:09:50 cargo and rust really should be unbundled if just for that reason alone 12:10:27 but afaik it's not possible to build rust without cargo? so cargo would be a build dep, and you'd be just as screwed 12:10:36 you need cargo for rustc afaik 12:10:44 it's really cargocult :D 12:11:57 at least you can build rust stuff without needing it to be already built before downloading distfiles, unlike go 12:16:33 that reminds me, i need to put aside a month or so to do for npm / yarn what we do for cargo 12:17:30 > what we do for cargo: wait? :D 12:18:43 meena: IMO allocate at least 3 months, maybe 6 12:19:03 jbo: i use vm-bhyve, it should be fine. I usually use uefi 12:19:19 jbo: there was a very recent EDK2 firmware bug, let me see if I can find the ref 12:19:50 dch, thanks. so when using bhyveload, which option should I choose during the guest installation? GPT (uefi) or something else? 12:20:39 jbo: generating https://codeberg.org/FreeBSD/freebsd-ports/src/branch/main/textproc/ripgrep/Makefile#L22 and https://codeberg.org/FreeBSD/freebsd-ports/src/branch/main/textproc/ripgrep/distinfo 12:20:43 Title: freebsd-ports/Makefile at main - freebsd-ports - Codeberg.org 12:21:20 dch I saw that you gave up on databases/jetbrains-datagrip :<<< 12:22:23 c 12:22:31 yes. last 2 patches are by somebody who actually uses it, I'm hoping they will pick it up. 12:23:09 jbo: the latest patch adds intel-isms, and breaks arm64, and I don't want to unpick the mess of java-linux-isms 12:23:26 I try to maintain ports I use, it encourages me to keep them .... usable 12:24:07 reasonable 12:24:35 dch, so any idea what the correct option for bsdinstall would be on a bhyve guest using bhyveload as the loader? I suspect that this is why my guest cannot boot. 12:25:11 what happened when you ran bhyveload? 12:25:48 RhodiumToad, I don't know (which is part of my problem). The guest installed fine from the ISO but booting after installation shows that the VM is stuck in the stage "bootloader" 12:26:54 have you looked at what options it's being run with and tried it yourself? 12:27:13 I'm not sure whether I understand your question 12:27:16 jbo, aah this was what I was mis-remembering https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273560 12:27:18 Title: 273560 – sysutils/edk2: bhyve flavor causes UEFI VMs to fail to boot after update to 202308 12:27:37 jbo, whats your vm-bhyve config? 12:27:46 have you looked at what options bhyveload is being invoked with, and tried running it the same way yourself? 12:28:35 https://www.irccloud.com/pastebin/2DoWTfJ5/vm-bhyve%2Fbifrost.conf 12:28:36 Title: Snippet | IRCCloud 12:31:56 hmm 12:31:58 RhodiumToad, I have not :) 12:34:40 ah bifrost.conf above was alpine linux. anyway I made a fresh 13.2-RELEASE without issue 12:37:10 https://www.irccloud.com/pastebin/0Qk7I8qU/vm-notes.txt 12:37:11 Title: Snippet | IRCCloud 12:38:19 jbo what is your host OS, how did you create the vm, and whats in the vm config? see my snippet above 12:39:13 I'm using the g202308 version without issue, on a rather fresh 15.0-CURRENT 12:42:00 dch, host ist 13.2-RELEASE and guest is 14-BETA1 12:42:23 my config is the example config: https://github.com/churchers/vm-bhyve/blob/master/sample-templates/freebsd-zvol.conf 12:42:24 Title: vm-bhyve/sample-templates/freebsd-zvol.conf at master · churchers/vm-bhyve · GitHub 12:43:22 ok almost same as mine apart from I have nvme disk there 12:43:43 jbo can you paste the precise line it hangs at? 12:47:17 dch, I might be misunderstanding something here. what I'm observing is that after successfull installation, on a subsequent (re)boot the VM never reaches the 'running' state. instead, it is permanently stuck in the 'bootloader' state when I observe 'vm list') 12:49:00 testy default bhyveload 4 16G - No Running (54631) 12:49:06 is what you should be seeing 12:49:48 and what I was seeing is that STATE is premanently stuck in 'bootloader' :) 12:49:54 anything in dmesg, /var/log/messages, or vm-bhyve.log (in the same dir as your config file) 12:50:58 jbo if you add `debug="yes"` to your `.config/system.conf` and try restarting the vm, we should see a nice debug log 12:51:14 Sep 11 12:30:12: generated static mac 58:9c:fc:0a:c0:39 (based on 'testy:0:1694435412:0') 12:51:15 Sep 11 12:31:29: initialising 12:51:15 Sep 11 12:31:29: [loader: bhyveload] 12:51:15 Sep 11 12:31:29: [cpu: 4] 12:51:15 Sep 11 12:31:29: [memory: 16G] 12:51:30 dch, thanks for the tip. I'll give that a try. Unfortunately, I nuked the VM in earlier so I'll reinstall it quickly. 12:51:42 whoops sorry, I clearly mis-pasted above, mea culpa 12:51:52 I'd still like to understand what the proper option for the bootloader is during bsdinstall of the guest when using bhyveload 12:52:25 I think you're overcomplicating it, the defaults seem to work just fine atm 12:53:00 that's good to hear. the default would be GPT (BIOS) tho :D 12:53:16 (I meant 'partition scheme' earlier, not 'bootloader') 12:53:22 aah 12:53:40 apologies for having been unclear 12:54:10 the partition scheme shouldn't matter all that much when using bhyveload 12:54:21 np, well I just ed my way through the installer, so i guess thats fine 12:54:25 machdep.bootmethod: BIOS is what the VM says 12:54:48 alright, time for another try then. thank you guys so far! 12:58:19 config: https://termbin.com/rtgv 12:58:26 debug log: https://termbin.com/ygtg 12:58:57 Sep 11 12:57:30: fatal; loader returned error 143 12:59:29 try it with cpu=16 first 13:00:25 did that already. also with cpu=8, mem=32G 13:00:30 also with cpu=4 and mem=8G :D 13:01:01 poudriere1 default bhyveload 16 32G - No Bootloader (7041) 13:01:06 could be dependent on the nmdm device settings. for example if it's blocked writing output, waiting 13:01:10 can you re-try it with a boring 13.2-RELEASE iso ? just to avoid the weird stuff 13:01:37 so my next guess is the `-c ...` can you try it without that 13:02:21 I have `console="tmux"` in my `.config/system.conf` btw if thats your thing. very nice. 13:02:46 I am using tmux elsewhere so probably want to do that, yes. just first time testing vm-bhyve so I wanted to keep things vanilla 13:02:54 both valid points tho. 13:07:28 set console to tmux and got: 13:07:30 ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2 13:07:30 ERROR: cannot open /boot/lua/loader.lua: no such file or directory. 13:08:10 I remember having read a post by klara when If irst wanted to try vm-bhyve so I wonder whether I have some left-over pieces from there. 13:08:14 jbo: so it got through the installer? on 13.2, or 14.0-B1 ? and on reboot, this message? 13:08:32 dch, did not test -RELEASE yet (I will, tho) 13:08:45 dch, that message is what I see in tmux when I start the 14.0-BETA1 vm I just finished installing 13:10:00 jbo: ok, so (on 15) both 14.0-B1 and 13.2-R install fine, using whatever defaults I get in the installer 13:10:14 dch, installation was not my problem :) 13:10:20 it's booting after the install 13:10:29 and on reboot they both come up to network 13:11:01 hmpf... 13:12:38 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273099 13:12:40 Title: 273099 – 14.0-ALPHA1 unbootable after install 13:32:18 I'll probably just go uefi 13:32:29 cool cool cool 14:12:46 jbo: aha this explains why my 15.0 works just fine 14:21:27 indeed 14:21:30 thank you for your efforts :) 15:02:26 Did wireless stuff change in 14? I'm installing BETA1 on my laptop and I don't remember my wifi showing up as an option before during install. 15:02:42 I might be misremembering. 15:11:55 dch, I dunno man, I must be doing something really wrong here. Nuked the vm, changed the config to use uefi, created VM and upon booting the installer image I get: ACPI Error: A valid RSDP was not found 15:12:27 still 13.2-R host and 14.0-BETA1 guest tho 15:13:32 ok, stable/14 appears fine to me. just rebuilt system 15:24:22 Hrm, BETA1 running normally on my ThinkPad T420. Nothing unusual so far. 15:52:07 hi! I need to install ruby 2.7 to upgrade a Redmine old backup. However, we do not have ruby27 in the repositories anymore. How can I do this? 15:55:53 gm, has anyone out here managed to get Intel Wi-Fi 6 AX200 to work with iwlwifi? 15:56:42 without the thing spitting errors every second or crashing the whole system at least 15:59:25 iwlwifi0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340 15:59:38 never had bigger issues with it 16:00:10 doesn't like unloading and I don't know about performance 16:01:23 i'm running into this all the time: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271979 16:01:25 Title: 271979 – bsdinstall(8): iwlwifi(4): system crash when authenticating for Wi-Fi: panic: lkpi_sta_auth_to_scan: lsta 0x... state not NONE: 0, nstate 1 arg 1 16:04:07 someone there reports that panics turn into plain spam in dmesg with the generic kernel 16:08:15 Ronis_BR: no great ways of doing this 16:09:02 public-static: sorry, GENERIC-NODEBUG to be exact 16:10:21 strange 16:23:19 Free shell scripting tip: Don't use PATH as a variable name in your script. 16:29:45 eofl 16:33:34 dch, upgraded the host from 13.2-RELEASE to stable/14 and now the VM guest works as expected :x 16:36:36 id suggest just staying with stable/* as it seems to provide enough security mitigation along with "stability" unrelated to "stable/*" 16:37:05 jbo: the basic issue is that the vm's zpool had a flag set that the host's userboot.so didn't recognize 16:37:13 balance is good 16:37:50 just a perspective 16:38:49 RhodiumToad, thank you for the explanation 16:39:05 yeah I run stable on all my desktops. just my servers run RELEASE (except for this one, but that will just be a build server anyway) 17:18:59 Ronis_BR: either rewind the ports tree to a point in time when we did, or install it yourself, by hand, like a cave woman 19:18:13 mmm is there a way to set the root password by passing a pre-hashed string? 19:18:36 I want to avoid the plaintext password in a cloudinit script 19:22:16 hah pw(8) has -H 19:22:46 i had to ^H the same answer i wrote :D 19:22:47 Beat me to it. *sulks* 19:22:57 you were a bit too fast answering your own question 19:30:25 openssl passwd -6 -salt $(openssl rand -base64 6) eurobsd | doas pw usermod root -H 0 19:30:45 PS if you're at eurobsdcon for my tutorial, now you know 19:35:20 I think cloudinit could do this for me, https://cloudinit.readthedocs.io/en/latest/reference/modules.html#users-and-groups is a bit unclear but it looks like it accepts hashed passwords 19:35:21 Title: Module reference - cloud-init 23.2.2 documentationMenuExpandLight modeDark modeAuto light/dark mode 19:38:27 dch: i'm pretty, and surr, it does. and if it doesn't, that's a bug 19:38:37 (a bug I need to fix) 19:39:01 * dch throws flowers at meena 19:39:40 I really hope they don't have thorns 19:43:14 will marigolds do? 19:52:00 another 15m of my life lost to subtleties in shell quoting rules 19:53:12 huh 19:53:13 pw: empty password read on file descriptor 0 19:53:28 thats what happens when run inside the install script 21:17:55 anyone know of a tool that could give me the throughput rate of a tcp connection each n periods (eg 100ms, 1s)? ie how many bytes arrived for periods 0-100ms, 101-200ms, etc., until sigint 21:19:53 I guess it doesn't really need to know anything about tcp if I can just pipe nc into it 21:20:20 that's extremely specific 21:25:05 2 21:25:49 I mean effectively what it is is a network graph of eg eth0 you can find in any ops dashboard or similar. like https://techhub.hpe.com/eginfolib/networking/docs/IMC/v7_3/5200-2888/content/images/image72.png 21:25:58 I've seen plenty of those 21:26:54 but instead of recording how many bytes got in/out of an interface I want to know that about a single connection, right 21:28:25 hm, maybe there's a download client that could export a report