Yay! I'm typing this on a t0430 running 14-Beta-1!

t-430

G'day. Where do I join a mailing list for testing FreeBSD 14.0-BETA1?

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?

DanGer: do you see the traffic on the outbound interface? tcpdump

and then do the same on the internal network machine, does the traffic even get there

if the default route is indeed the problem, you can add a more specific one to fix that

`route show $IP` will tell you whats being used

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.

anyone in here running postgis with postgre 15?

drobban, I was running postgis a few years ago so probably won't have anything useful in my memory anymore

well, im new to freebsd, so I just wanted to make sure the packages I found is in fact only for postgresql 15.

sorry, postgresql 13....

any given postgis package is built for exactly one postgres version, and it should be obvious from the package name

what OS?

freebsd...

oh

the packagename is postgis33. =D

the prebuilt package of postgis only exists for the default postgres version

so not sure how obvious that is, but okey.

yeah well, it's obvious on most OSes but not so much on freebsd

well. I just spun up a jail with 13 instead, so no worries

current ports tree has the default version as 15, are you using quarterly?

RhodiumToad, postgis33 seems to have postgresql13-server as dependency. not 15 (but I might be missing something)

jbo: from which repo?

RhodiumToad, head

ah, it was updated in ports only 3 days ago

which isn't enough time for the packages to have been rebuilt yet

it should be updated in the latest repo probably no sooner than about Friday

(and possibly a few days later)

package build times are quite ridiculous these days

quantity wise it's also exploding given that these days everything needs to be rewritten in rust

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

ahh thanks for the heads up! im using quarterly

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

that ^

RhodiumToad: it's not like it's bumping it's so version every other week tho

so even if rust itself were reasonably stable, you'd still be rebuilding it frequently

cargo and rust really should be unbundled if just for that reason alone

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

you need cargo for rustc afaik

it's really cargocult :D

at least you can build rust stuff without needing it to be already built before downloading distfiles, unlike go

that reminds me, i need to put aside a month or so to do for npm / yarn what we do for cargo

> what we do for cargo: wait? :D

meena: IMO allocate at least 3 months, maybe 6

jbo: i use vm-bhyve, it should be fine. I usually use uefi

jbo: there was a very recent EDK2 firmware bug, let me see if I can find the ref

dch, thanks. so when using bhyveload, which option should I choose during the guest installation? GPT (uefi) or something else?

jbo: generating codeberg.org/FreeBSD/freebsd-ports/…/main/textproc/ripgrep/Makefile#L22 and codeberg.org/FreeBSD/freebsd-ports/…anch/main/textproc/ripgrep/distinfo

Title: freebsd-ports/Makefile at main - freebsd-ports - Codeberg.org

dch I saw that you gave up on databases/jetbrains-datagrip :<<<

c

yes. last 2 patches are by somebody who actually uses it, I'm hoping they will pick it up.

jbo: the latest patch adds intel-isms, and breaks arm64, and I don't want to unpick the mess of java-linux-isms

I try to maintain ports I use, it encourages me to keep them .... usable

reasonable

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.

what happened when you ran bhyveload?

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"

have you looked at what options it's being run with and tried it yourself?

I'm not sure whether I understand your question

jbo, aah this was what I was mis-remembering bugs.freebsd.org/bugzilla/show_bug.cgi?id=273560

Title: 273560 – sysutils/edk2: bhyve flavor causes UEFI VMs to fail to boot after update to 202308

jbo, whats your vm-bhyve config?

have you looked at what options bhyveload is being invoked with, and tried running it the same way yourself?

Title: Snippet | IRCCloud

hmm

RhodiumToad, I have not :)

ah bifrost.conf above was alpine linux. anyway I made a fresh 13.2-RELEASE without issue

Title: Snippet | IRCCloud

jbo what is your host OS, how did you create the vm, and whats in the vm config? see my snippet above

I'm using the g202308 version without issue, on a rather fresh 15.0-CURRENT

dch, host ist 13.2-RELEASE and guest is 14-BETA1

my config is the example config: github.com/churchers/vm-bhyve/blob/…/sample-templates/freebsd-zvol.conf

Title: vm-bhyve/sample-templates/freebsd-zvol.conf at master · churchers/vm-bhyve · GitHub

ok almost same as mine apart from I have nvme disk there

jbo can you paste the precise line it hangs at?

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')

testy default bhyveload 4 16G - No Running (54631)

is what you should be seeing

and what I was seeing is that STATE is premanently stuck in 'bootloader' :)

anything in dmesg, /var/log/messages, or vm-bhyve.log (in the same dir as your config file)

jbo if you add `debug="yes"` to your `.config/system.conf` and try restarting the vm, we should see a nice debug log

Sep 11 12:30:12: generated static mac 58:9c:fc:0a:c0:39 (based on 'testy:0:1694435412:0')

Sep 11 12:31:29: initialising

Sep 11 12:31:29: [loader: bhyveload]

Sep 11 12:31:29: [cpu: 4]

Sep 11 12:31:29: [memory: 16G]

dch, thanks for the tip. I'll give that a try. Unfortunately, I nuked the VM in earlier so I'll reinstall it quickly.

whoops sorry, I clearly mis-pasted above, mea culpa

I'd still like to understand what the proper option for the bootloader is during bsdinstall of the guest when using bhyveload

I think you're overcomplicating it, the defaults seem to work just fine atm

that's good to hear. the default would be GPT (BIOS) tho :D

(I meant 'partition scheme' earlier, not 'bootloader')

aah

apologies for having been unclear

the partition scheme shouldn't matter all that much when using bhyveload

np, well I just <ENTER>ed my way through the installer, so i guess thats fine

machdep.bootmethod: BIOS is what the VM says

alright, time for another try then. thank you guys so far!

config: termbin.com/rtgv

debug log: termbin.com/ygtg

Sep 11 12:57:30: fatal; loader returned error 143

try it with cpu=16 first

did that already. also with cpu=8, mem=32G

also with cpu=4 and mem=8G :D

poudriere1 default bhyveload 16 32G - No Bootloader (7041)

could be dependent on the nmdm device settings. for example if it's blocked writing output, waiting

can you re-try it with a boring 13.2-RELEASE iso ? just to avoid the weird stuff

so my next guess is the `-c ...` can you try it without that

I have `console="tmux"` in my `.config/system.conf` btw if thats your thing. very nice.

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

both valid points tho.

set console to tmux and got:

ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2

ERROR: cannot open /boot/lua/loader.lua: no such file or directory.

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.

jbo: so it got through the installer? on 13.2, or 14.0-B1 ? and on reboot, this message?

dch, did not test -RELEASE yet (I will, tho)

dch, that message is what I see in tmux when I start the 14.0-BETA1 vm I just finished installing

jbo: ok, so (on 15) both 14.0-B1 and 13.2-R install fine, using whatever defaults I get in the installer

dch, installation was not my problem :)

it's booting after the install

and on reboot they both come up to network

hmpf...

Title: 273099 – 14.0-ALPHA1 unbootable after install

I'll probably just go uefi

cool cool cool

jbo: aha this explains why my 15.0 works just fine

indeed

thank you for your efforts :)

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.

I might be misremembering.

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

still 13.2-R host and 14.0-BETA1 guest tho

ok, stable/14 appears fine to me. just rebuilt system

Hrm, BETA1 running normally on my ThinkPad T420. Nothing unusual so far.

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?

gm, has anyone out here managed to get Intel Wi-Fi 6 AX200 to work with iwlwifi?

without the thing spitting errors every second or crashing the whole system at least

iwlwifi0: Detected Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340

never had bigger issues with it

doesn't like unloading and I don't know about performance

i'm running into this all the time: bugs.freebsd.org/bugzilla/show_bug.cgi?id=271979

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

someone there reports that panics turn into plain spam in dmesg with the generic kernel

Ronis_BR: no great ways of doing this

public-static: sorry, GENERIC-NODEBUG to be exact

strange

Free shell scripting tip: Don't use PATH as a variable name in your script.

eofl

dch, upgraded the host from 13.2-RELEASE to stable/14 and now the VM guest works as expected :x

id suggest just staying with stable/* as it seems to provide enough security mitigation along with "stability" unrelated to "stable/*"

jbo: the basic issue is that the vm's zpool had a flag set that the host's userboot.so didn't recognize

balance is good

just a perspective

RhodiumToad, thank you for the explanation

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)

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

mmm is there a way to set the root password by passing a pre-hashed string?

I want to avoid the plaintext password in a cloudinit script

hah pw(8) has -H

i had to ^H the same answer i wrote :D

Beat me to it. *sulks*

you were a bit too fast answering your own question

openssl passwd -6 -salt $(openssl rand -base64 6) eurobsd | doas pw usermod root -H 0

PS if you're at eurobsdcon for my tutorial, now you know

I think cloudinit could do this for me, cloudinit.readthedocs.io/en/latest/…rence/modules.html#users-and-groups is a bit unclear but it looks like it accepts hashed passwords

Title: Module reference - cloud-init 23.2.2 documentationMenuExpandLight modeDark modeAuto light/dark mode

dch: i'm pretty, and surr, it does. and if it doesn't, that's a bug

(a bug I need to fix)

I really hope they don't have thorns

will marigolds do?

another 15m of my life lost to subtleties in shell quoting rules

huh

pw: empty password read on file descriptor 0

thats what happens when run inside the install script

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

I guess it doesn't really need to know anything about tcp if I can just pipe nc into it

that's extremely specific

2

I mean effectively what it is is a network graph of eg eth0 you can find in any ops dashboard or similar. like techhub.hpe.com/eginfolib/networkin…200-2888/content/images/image72.png

I've seen plenty of those

but instead of recording how many bytes got in/out of an interface I want to know that about a single connection, right

hm, maybe there's a download client that could export a report