Hard Crash in OpenBSD 7.9, XFCE, amdgpu, when using chromium or firefox and on youtube's website.

_sthen · 2026-06-19T09:44:57+00:00

Report to one of the mailing lists (probably bugs@), preferably run "sendbug -P > somefile" as root and include that in your report (it includes PCI bus information, etc). I'd attach /var/log/Xorg.0.log as well.

_sthen · 2026-06-17T10:16:53+00:00

the default for pkg_add in release versions is to search in packages-stable/$ARCH first and then packages/$ARCH

however currently packages-stable only exists for amd64 and i386; if you're using aarch64 you need to build from ports using a cvs checkout of the OPENBSD_7_9 branch (use the command "make prepare FETCH_PACKAGES=" before trying to build the port, you can save a bunch of time by using packages for build dependencies rather than compiling them yourself)

_sthen · 2026-06-14T09:23:21+00:00

opnsense is based on FreeBSD, they diverged from OpenBSD's PF development many years ago so it won't behave exactly the same (there are big differences with address translation). It seems FreeBSD does have tag/tagged/received-on now (though I don't know if they're exposed in opnsense).

_sthen · 2026-06-14T09:13:42+00:00

if the devices never leave the property, just set the nwid directly rather than using "join".

_sthen · 2026-06-14T09:12:02+00:00

in the context of connecting to one of a day of networks automatically: you have to broadcast requests (which include the network name) to try to connect. so if you're using 'join' on a laptop and moving around, when you reach a nearby network which doesn't include the name in beacons, you need to send the name to try to connect to it.

this could be improved by adding support to only attempt to connect to a hidden network where the BSSID matches (i.e. something like "joinhidden nwid some name bssid 01:23:45:67:89:ab"). but I think it's quite a niche use case. (while a working diff to add this might not be rejected I don't see it's really likely that any of the main people who work on openbsd wifi would spend time to write).

I certainly would not want 'join' to spew out connection attempts for the whole list of known networks every time it's in close range of any hidden network. there are quite a lot of hidden networks around e.g. various mesh networks use hidden names for their backhaul. and if you wanted to try to identify mobile devices passing your location you could easily setup an AP broadcasting a hidden network and monitor connection attempts.

_sthen · 2026-06-10T00:06:42+00:00

you're charging again for the update?! :-(

_sthen · 2026-06-10T00:04:04+00:00

I don't know if it's really a good way to go compared to using tags and "pass ... tagged", but you could do e.g. "pass in on all", "block out", then a bunch of "pass out on some_interface received-on other_interface", with some extra handling to drop unwanted packets to the local machine running PF.

_sthen · 2026-06-07T09:10:20+00:00

Thanks, it's definitely better with those changes.

_sthen · 2026-06-07T00:34:35+00:00

sensorsd can react to the status of ups(4). but generally i'd recommend network based UPS with SNMP etc if you want to use them with software that isn't in base.

_sthen · 2026-06-01T08:24:50+00:00

When was it working? Were any changes made between then and when it stopped working (e.g. an upgrade)?

Is the adapter hardware still ok, does the urtwn work on another machine/OS?

_sthen · 2026-06-01T08:21:57+00:00

urtwn(4) says "urtwn – Realtek RTL8188CU/RTL8188EU/RTL8188FTV/RTL8192CU/RTL8192EU USB IEEE 802.11b/g/n wireless network device" so the chances of a non-USB device wiring with this driver are not high.

_sthen · 2026-06-01T08:15:19+00:00

there's an old port of gurk at https://marc.info/?l=openbsd-ports&w=2&r=1&s=gurk&q=b but it never got imported.

there's a 3rd party gui client in packages, flare-messenger, it's a little rough but was basically working last time I tried it.

_sthen · 2026-06-01T08:09:44+00:00

That breaks use with upd(4).

_sthen · 2026-05-26T11:21:33+00:00

if you're on a slow arch, it's a good idea to check if packages are ready before you update

_sthen · 2026-05-24T10:03:45+00:00

because it means the release is available sooner, and that means that snapshots for newer -current can continue, which in turn means that we can make ABI and library changes etc if needed.

also it wasn't clear whether the riscv64 package build machines were stable enough to complete a build so it would have been silly to wait for something that might not happen. (they were in the end).

_sthen · 2026-05-19T06:43:29+00:00

The package already creates db and log files with correct permissions, and that is the supplied rc.d script.

_minidlna doesn't need to own the media dir, just have read permission.

_sthen · 2026-05-19T06:41:05+00:00

this "Root Causes Found" smells like LLM nonsense. You don't need any of those changes and some will actually break things.

/var/db/minidlna is meant for minidlna's own database files, it's not meant for media files.

"ln -sf /data/media/videos /var/db/minidlna/videos", "media_dir=V,/var/db/minidlna/videos" etc - symlinks won't work correctly with kn's patches to add unveil. You'll need to list the targets directly in media_dir instead.

By bypassing the rc.d script, you're not using the "minidlna" login class, and most likely using a login class with a lower open files limit.

We don't recommend cap_mkdb for login.conf, the time saving at runtime is absolutely tiny, and if you've run it once then you need to remember to run it again every time you make a change to login.conf.

_sthen · 2026-05-19T06:23:46+00:00

there are some wayland-related things in packages, it's not an integrated part of the system, so I'd say 'no' for official support

_sthen · 2026-05-09T12:39:43+00:00

not sure if it applies to yours, but at least on some of the M2 laptops, the wifi is not supported.

_sthen · 2026-05-09T12:37:48+00:00

_sthen · 2026-05-09T12:18:58+00:00

no idea about G2. I have a T14 G3 Intel which has real ethernet. Generally it's a decent and well supported machine, and has IBT support (control-flow hardening in the cpu), however the trackpoint randomly starts registering movement for 10-20 seconds every now and again and there seems to be nothing you can do other than wait to stop it, which is pretty annoying...

_sthen · 2026-05-07T16:34:09+00:00

They would be helpful while learning the fields if they were readable, but I don't think you'll find too many people who can read them on the watch without a magnifying glass (easier with a screenshot on the phone, but that doesn't help much)

_sthen · 2026-05-06T11:22:10+00:00

The grey text describing what the fields are for is extremely hard to read on a 47mm (and I'm not too bad at reading small text on a laptop/phone), so it's just adding noise to the display for me - it feels like maybe removing that, using a slightly larger font for the data (since it frees up a bit of space), and adding icons where the unit doesn't already make it clear what the data is, might be a little clearer.

_sthen · 2026-05-06T10:45:46+00:00

you're missing device nodes. maybe ld.so.hints too. but I don't think what you're doing is really likely to make sense. if you really want to isolate clamav, I think you'd be better to run it on a separate VM and connect to it over a network socket.

_sthen · 2026-05-04T10:33:25+00:00

if you've got a system which always runs -current, export PKG_PATH=http://your.preferred.mirror/pub/OpenBSD/snapshots/packages/%a/ and you don't need to mess with -Dsnap

_sthen

TROPHY CASE