kevans, I admit not to being very familiar with postgresql. Not for any reason except that other people direct me to I have always run MySQL now MariaDB.

Most of the time those will upgrade in place. But sometimes notable versions will just fail to upgrade. Therefore I always make an SQL backup dump before the upgrade. Then either upgrade or purge and install. Then load the backup. That's a guaranteed way to success.

rwp: minor versions can upgrade in place, e.g. 16.0 to 16.1. major versions cannot upgrade in place, you have to run pg_dumpall

this is well documented in the manual and, i would assume, familiar to any postgres operator

do you ever start a buildworld and by the time it's done you can't remember what you were trying to test?

All of the time! All of the time.

I must keep notes about what I am doing or I lose the juggle. Especially for things which take a while and therefore I try to do multiple things timeslicing.

Title: bhyve - A solid HOWTO with BHYVE on FreeBSD 14 and Windows 11 | The FreeBSD Forums

I messed up. I tried updating a machine while it was updating (I thought I was logged into another machine.). Now I get some version of "ld-elf.so.1: Shared object "libutil.so.9" not found, required by "sudo"" when I try to run anything

I'm a bit beyond what I know to recover from this

trying to login from the console gives the same (but with login instead of sudo in the error, unsuprisingly)

If I can boot the vm from a cd image, can I repair?

gp5st: sometimes this kind of issue can be fixed with 'pkg -f upgrade' to reinstall everything

I can't run pkg or sudo because it complains about missing libraries

ah you can't log in at all? that's unfortunate

what version were you previously running and what did you upgrade to?

I'm going to try to copy /lib /lib64 and most of /usr and see if I can get something working

13.2 to 13.3 but I think I ran freebsd-update install at the same time as another one was running

otherwise I'm not sure what I did :-\

i suggest booting from install media, if you can, and use freebsd-update -r to complete the upgrade

OK

you may need to mount your existing system on /mnt or whatever to do that

gp5st: but wait, if you can get a root shell, try pkg-static

i can't get a root shell since I can't sudo, su, or login :/

e.g. reboot, at the loader prompt type 'boot -s', get single user root shell, run pkg-static upgrade -f

ah, ok, let me see

can I boot on a microvm on Qemu KVM???

something like: qemu.org/docs/master/system/i386/microvm.html

Title: ‘microvm’ virtual platform (microvm) — QEMU documentation

but like on x86 64

so ignore URL

actually noo URL is good

aaaaa

it's a digitalocean vm

I want to run on my Thinkpad locally

oh sorry, I misread

with minimal amount of motherboard emulation

it's okay

typed it like a shitstorm, but we got there

sry

lmao

mmmm virtiofs

can I build FreeBSD from Linux?

I want to hack on the kernel from the Linux side until I can virtio all the things

yay I got a cool thingy to do the happy dance

Got the nographic installer looking hella pretty

love the EFI boot menu on FreeBSD

it's so preeettttyyyyy

O.o

qemu goes brrr

installing git on FreeBSD :)

can I plan9 share myself or something???

that'd be really really nice

frfr

I'd love y'all forever if that was like a thing

What -exactly- is the difference between the -memstick and the -disc images?

The one is flashable to USB, and the other is burnable to DVD or usable on VMs.

remiliascarlet: Yes, that's what I'm thinking, too. But - e.g. the proxmox image does not diffeentiate between those two.

OK, seems that it does not make a difference for amd64, but for any other architecture. From /14.0R/announce/ "Additionally, this can be written to a USB memory stick (flash drive) for the amd64 architecture"

hi all

hi there adilix

wy isn't there a way of saying: don't build the modules

my laptop consistently gpu crashes every 2 days

only the mouse cursor still works

and audio

oh, the VM has 4 vCPU / 4 GB RAM… that's why this is taking forever

sfox: you getting any dumps?

no

it doesn't dump. i have to hold the power button

does anything appears in /var/log/messages BEFORE you do the power button check?

lots of complaints about the atheros wireless driver

some gpu stuff

www.nuegia.net/dist/messages

So the wifi guide for FreeBSD involves editing /etc/rc.conf to provide ifconfig flags, and also editing wpa_supplicant for adding entries, this is all well and good apart from when you are on the move and switching between networks... I don't want to be broadcasting saved networks (no autoconnect) as that will leave me vulnerable to evil twin attacks, secondly, switching between WPA at home, and

public unencrypted networks at university is troublesome as I keep needing to change /etc/rc.conf, I am aware this is a role of a network manager... but I don't want to use something really heavy... is there any simple network managers... or even a simple way to handle this with less mental overhead?

If you're looking for a GUI network manager, there's wpa_supplicant_gui. Otherwise, there's wpa_cli.

(wpa_supplicant_gui is a package. wpa_cli is installed with the base system.)

just got a 2nd person reporting weirdness with rc.d scripts in jails in 14.0-RELEASE that only start if run manually

I can reproduce this, but .. maybe I am doing this completely wrong?

dch: works fine here. maybe you are doing it wrong, or maybe I'm just lucky :)

SKull: yea I am making a minimal rc.d script in the hope of finding some insight

this example docs.freebsd.org/en/articles/rc-scripting doesn't run at startup for me

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

dch, can you be more specific? Which example are you trying? (Also, I suspect that article needs a refresh. Going by the copyright years, it hasn't been substantially updated for 12 years.

)

V_PauAmma_V: take the very first example script, #3 a dummy script, it doesn't work.

it's not supposed to do anything...

babz: it is supposed to execute, which it doesn't.

what do you count as workng ?

running rc_startmsgs=YES rc_debug=YES dummy_enable=YES dummy_flags=flagging

I would expect to see something in syslog from it

a slightly fancier one also isn't executed

Title: Snippet | IRCCloud

when the jail is restarted, this script is never run

and yet, `jexec wtf service dummy start` shows it executing happily

I think it has to have the `# PROVIDE: dummy` to run at boot

OK, that article definitely needs a refresh. The examples don't include the magic lines specified in rcorder(8), including the one you just mentioned.

it does ?

are we reading the same page ?

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

Oh, I was looking at the same early examples dch mentioned.

babz: if we're going to have tutorials then they should work OOTB

how do you stop a process supervised with daemon(8) from restarting? a simple example: daemon -r -R 3 ls /

outside of sigkill to the daemon process

llua got to kill the daemon itself, signals aren't propagated to the child

ok, thank you

bugs.freebsd.org/bugzilla/show_bug.cgi?id=212829 has more details

I logged it only 8 years ago

llua, dch: i've put togehter reviews.freebsd.org/D44944

Title: ⚙ D44944 daemon: Add -C (--restart-count) option

meena: ^^ otis has a thing, I think you looked at this a while back

favorite stack for freebsd observability? already heard grafana, prometheus, netdata, and collectd. what else are ppl using and liking?

alepzi: munin

added to list ty ridcully

polarian: broadcasted out of the house? what?

rtprio: I am not a wifi expert, but what I know of it is when you attempt to join a wifi network you are broadcasting a request for a specific SSID

this can then be intercepted by a malicious user, and then a fake network can be broadcasted, your device then automatically connects to this

Evil twin attack...

I don't want to keep wpa_supplicant from looking for saved networks

I think WiFi networks can only ever be treated as untrusted networks. Don't let it fool you that it includes some weak encryption into thinking it is secure.

do you do that for all your devices? that sounds incredibly inconvenient

but, sure, ok

maybe you can set up wifi with public key auth?

so evil twin won't have the key you set it up with?

alepzi, WiFi is a product of the Wi-Fi Alliance a consortium of equipment vendors who make money licensing devices.

They operate behind closed doors. They are notorious for creating brand new standards with design flaws.

Every time they release a new generation and standard then security researches look at it and go, "Oh man... If you had only let us comment on this awful thing before you make it a hard requirement. Here's the list of problems with it."

WiFi is the available radio network but I would never treat it as a trusted network. WiFi is always going to be an untrusted network. Which is okay if you treat it that way.

so no pub key auth? lmao wifi

rwp: thats not what I mean

rtprio: I disable autoconnect... and turn off the antenna when I am not using it

The Wi-Fi Alliance is really meant as a way to make money licensing the logo that vendors put on retail packaging.

Its how I run a Linux laptop, I manually connect when I want to... other than that it shouldn't connect.

alepzi: that would require compatible APs

and off the shelf consumer APs aren't going to cut it

polarian, If my machine connects to an Evil Twin that's going to be annoying but I won't be worried about security.

also theres one additional issue leaving an antenna broadcasting...

its constantly draining power trying to find a AP

Basically if I ma connected to an Evil Twin then I will start to see network failures as certificates fail to validate and connectivity is rejected.

rwp: I heard from someone that without TLSv1.3 channel bindings this can be bypassed too

how? they never gave me a reference to how you can

but TLSv1.3 channel bindings are not widespread supported currently (at least I know it isn't for the XMPP community)

There are also various attacks against the various TLS versions too. But again those are at the layer below. Those attacks do not void things like https or ssh connections.

I am not a fan of the centralized Certificate Authority model of https but regardless that is the security model that has been adopted to keep connections secure. And of course ssh has Trust On First Use which protects the 2nd connection.

rwp: you are free to make your own trust store :)

And of course for OpenVPN connections we do make our own trust store.

I am just saying that when I take my mobile device to a coffee shop or airport I always assume that I am operating in a hostile environment. Trust No One!

maybe we could set something up so you can allow anyone open wifi connection, but they can't pass any data unless they use pub key auth to a sidecar?

can I use dma to fetch imap mail?

Title: FOSDEM 2024 - Soft Reboot: keep your containers running while your image-based Linux host gets updated

wonder if freebsd could do that with jails?

concussious: I dont think so, since it's a MTA

Title: dma(8)

I have a text file that somehow became corrupted or it contains some unprintable chars or something

not sure how that might have happened

is there a way to clean it ?

for some reason file patch.diff thinks it's a binary file

souji: I didn't either, and didn't see anything that seemed appropriate in dma(8), but I just wanted to check here. thanks!

concussious: no worries :)

what do I have to put into loader.conf for a verbose boot?

boot_verbose=YES

i'm running into problems with my locally compiled pkgbase repo

the kernel (+ its -dgb) package have FreeBSD_version: 0 as annotation instead of the true kernel ABI version number

which causes pkg(8) to refuse the repo

crest: wow, how'd you do that?

meena: no idea

about why it broke

kevans: now I just need to figure out howto scroll in the qemu(?) window… or maybe switch to serial console to do that??

let me check the older versions maybe it's only that the latest pkg 1.21.x notices this?

nope my 14.0p5 repo has a valid ABI version

kevans: freebsd/freebsd-src #1199 in case you know any better

Title: sys/amd64/conf/MINIMAL: remove virtio by llfw · Pull Request #1199 · freebsd/freebsd-src · GitHub

meena: probably need virtio_blk as well

maybe

ideally we wouldn't be removing virtio at all until loader can actually autoload beyond fdt

why not remove the ahci driver while you're at it

and nvme

how much code size do the virtio_* drivers add to the resulting kernel (assuming you don't rip out all of pci)?

removing virtio is well within the scope of the ultimate design of MINIMAL

it's just that we're not there yet

isn't it more imporant to boot in common hypervisors without having to load moduls on the loader prompt to even add the device drivers back in via loader.conf?

because i suspect small virtual machines are the most common usecase for MINIMAL other using it as a starting point for custom kernel configs

meena: even more curious the FreeBSD-kernel-generic-14.0p6 package already installed from the repo has a valid FreeBSD_version annotation

there is no most common usecase for MINIMAL right now

wtf?!? how did i get into this state

lets try make cleankernel buildkernel followed by building the (kernel) packages again

did i do something stupid? maybe upgrade the pkg package from 1.20.* to 1.21.* while building the kernel packages?

strange

kevans: is there a usecase/goal for the MINIMAL config other than the smallest build artefact that still gets to the missing rootfs prompt?

the goal is GENERIC - all the crap that can autoload

e.g. what about removing IPv4/IPv6? what about SMP or ACPI support?

i'm not going to continue to entertain this conversation if you're not going to read what I've already written

i did read it and i don't understand why it's considered an acceptable trade-off

16:33 < kevans> it's just that we're not there yet

I said it's not a trade-off, we're not ready but it's within the scope of what it was meant to do

acceptable trade-off

okay so until the automatic loading of kernel modules by vendor + device id works removing those drivers isn't a valid option?

imo yes

sorry. in that case i misunderstood you the first time around

if it's needed to get to multi-user because loader can't do it on its own yet, then it needs to stay imo

once it can be autoloaded it's fair game

at least those other than virtio_blk and virtio_scsi can be loaded later already by devmatch

crest: ahci and nvme have already been removed from minimal

virtio_blk is the only block device driver included

actually that's not quite true, the xen block driver is still there but that's because you can't remove that, i don't think it even comes as a module

i wish we could remove uart, that means fixing the console init stuff to allow the console to be a module

(which might also help with console on usb serial)

meena: sorry, only just saw your comments, in the middle of setting up a new system...

which had a really weird bug: it worked fine except reboot and shutdown would hang. turns out that was caused by killing the getty on ttyu2, but i'm confused about why... maybe it generates a serial break that drops into kdb?

meena: are you deliberately using virtio_scsi rather than virtio_blk? i'm not that familiar with virtio so not sure what the difference is (i guess scsi is to pass through a raw scsi device?)

lw: no change when I add blk

lw: i haven't looked at the code but i imagine virtio-scsi is still just virtio, but talking the scsi protocol

i don't think it does any kind of passthrough, it just emulates a scsi device

oh. weird

meena: also if you want to scroll up, just start qemu with -nographic and use the serial console

oh wait is this bhyve

lw: oh nevermind, i've just looked at the code and it seems to bridge directly to scsi devices

yeah, i guess it's so you can attach an iscsi lun to the vm directly

yep

looks that way from the code, anyway

(or any kind of lun, but iscsi seems like the most obvious application)

virtio-scsi hooks into the CAM target layer

CTL (CAM Target Layer) allows the kernel to act as both target and initiator

bhyve's virtio-scsi paravirtualised driver uses a CTL port (think of it as a virtual HBA) on the host to access the hosts CAM internal "virtual" scsi bus

and allows the guest to act as initiator through the virtio-scsi device

the big advantage over other block storage backends is that you need just one pci device in the guest for multiple block devices

it's also the only bhyve block storage implementation that supports hot plugging/unplugging (and resizing) of storage devices

the downside is that its complex to configure (correctly)

each bhyve guest needs its own CTL port and LUN mapping table (from per port LUNs -> global LUNs) for secure isolation

but afaik there exists no tooling to make it approachable for mere mortals^^

but as of FreeBSD 14.0 it correctly passes through the scsi command tags (they're no longer truncated to 32bits)

the UEFI BootROM can boot of virtio-scsi devices

and in theory you could "passthrough" other scsi device types than block devices

if you have a streamer give it a try ;-)

but i doubt anyone is able to find working hardware and drivers to hook up the crazier types of devices that used to exist for the scsi bus e.g. NICs, eGPUs, flatbed scanners, etc.

kevans: is removing virtio part of pkg base?

afaik its unrelated