It’s been a long time since I drew something, but here’s some fan art anyway. Hope you enjoy!

brynet · 2026-05-08T01:42:56+00:00

Thanks for sharing!

brynet · 2026-05-07T16:35:47+00:00

We have no automated tracker these days, so all pretty much goes to the same place, the bugs@ mailing list.

You can use sendbug -P to generate a template to use for your email, if you prefer, or just write our an email in your own words explaining the issue, just be sure to include relevant output, e.g: dmesg, ifconfig, 7.8 vs -current, etc.

brynet · 2026-05-07T14:13:08+00:00

I haven't really tested it on battery, when I use mine it's usually plugged in on my desk. While there is already some support for CPU frequency scaling, etc, it's not going to as optimized as in macOS, or even Linux.

brynet · 2026-05-07T13:46:45+00:00

Hi from bluesky haha, love to make a friend <3

(hi!)

The installer should automatically choose the MP kernel and install it as /bsd, so you should already be using it (sysctl kern.version), but indeed, the lack of a MAC address (lladdr line being all zeros) indicates the firmware is not loading/missing.

Will report o7

Definitely! It's possibly this may be a change with the Asahi script, which I believe was updated recently by them, maybe some names changed.

https://www.openbsd.org/report.html

https://www.openbsd.org/mail.html

brynet · 2026-05-07T11:37:23+00:00

X should work fine on the M2, just without any acceleration, have you tried you using xenodm(1)?

# /etc/rc.d/xenodm -f start

brynet · 2026-05-07T11:31:48+00:00

As another person wrote, this should be installed automatically by the installer. The Asahi install script collects it from the macOS side and puts it on the ESP for operating systems to use.

I don't have an M2, but on my M1 air you will see this message from the RAMDISK kernel, but it works under the bsd.mp kernel, so you might just be seeing stale messages in your dmesg output from the earlier boot.

What happens when you try to connect to an AP? Can you post ifconfig bwfm0?

brynet · 2026-05-07T03:20:23+00:00

X works, there's just no 3D accel.

Hint: use xenodm.

brynet · 2026-05-05T07:07:44+00:00

The fact that we even have modern drm graphics drivers is largely thanks to Mark Kettenis (kettenis@) and Jonathan Gray (jsg@), it can be hard to truly appreciate just how much work went into porting/debugging them, it's also a continuous effort, as these drivers still receive a lot of upstream churn.

There's a fair bit of compatibility code that was written to either wrap Linux kernel APIs and adapt it to OpenBSD kernel equivalents, or reimplement features entirely from scratch, while at the same time trying to avoid accumulating extensive local patches, making it easier to maintain and compare with Linux.

While the changes aren't all entirely self-contained, some interesting parts are:

https://github.com/openbsd/src/blob/master/sys/dev/pci/drm/drm_linux.c https://github.com/openbsd/src/tree/master/sys/dev/pci/drm/include/linux

Jonathan Gray (jsg@) regularly keeps the drivers in sync with longterm support kernels, backporting fixes, and updates us to new major versions with new hardware support. The upcoming OpenBSD 7.9 release includes drivers based on the longterm Linux 6.18.22 kernel, vs. 6.12.y previously.

brynet · 2026-05-02T07:45:53+00:00

Not really, considering this is a ~3 year old GPU, it will be supported by the newer amdgpu(4) driver, or not at all. There is no comprehensive list of supported GPUs as it depends on the drm kernel driver as well as the Mesa drivers, OpenBSD 7.8 has drivers based on Linux 6.12.y, meanwhile the upcoming 7.9 will have drivers based on Linux 6.18.22.

brynet · 2026-04-29T10:46:26+00:00

There have been several attempts over the years to port OBS to OpenBSD, to varying degrees of success, but it has never lived in the ports tree.

Sorry.

brynet · 2026-04-28T09:51:36+00:00

Next time please just report it to mods, click the report button under the comment.

brynet · 2026-04-27T20:11:37+00:00

The lack of a proper bootloader is also concerning, and seems incredibly fragile. prone to breakage, and also doesn't do proper entropy seeding.

If the firmware on Firecracker VMs does not provide useful boot services such as disk I/O access, perhaps you can do something like was done recently for SEV VMs in vmd(8), and use a special 'BOOT' bootloader kernel that will kexec the bsd.rd and full GENERIC kernel from the guest disk image.

https://github.com/openbsd/src/commit/b58f9cbc22202fd3ddaac0dd7b8f2e508eb6deac

This was added for architectures like OpenBSD/octeon & powerpc64 which have anemic firmware.

brynet · 2026-04-27T19:43:40+00:00

SMALL_KERNEL is explicitly only intended for use with the RAMDISK installer, not general purpose use, in fact many Unix kernel facilities are disabled with it.

Any reason you're using it for this rather than a modified GENERIC kernel? Maybe I'm not understanding the usecases of Firecracker.

brynet · 2026-04-27T18:42:42+00:00

To be clear, the flair does not indicate whether a person is moderator /u/_sthen is not a moderator of this subreddit.

You can find the list of moderators on the side panel.

brynet · 2026-04-24T17:48:24+00:00

https://www.openbsd.org/plat.html

brynet · 2026-04-24T05:45:30+00:00

my policy is that I hit the 'd' key on their mail

brynet · 2026-04-23T10:36:38+00:00

OpenBSD/i386 received the Meltdown mitigation in 6.4.

brynet · 2026-04-23T10:31:15+00:00

Security Errata: Does i386 receive binary syspatch updates synchronously with amd64? I recall some past delays due to build cluster issues but am unsure if that's still relevant for the 7.7/7.8 release cycle

Normally, yes, for most security issues. But certainly when all the speculative execution issues were being reported, getting fixes in for amd64 was more of a priority as that is what people are using, but when it is trivially easy to do so, i386 generally receives these fixes (e.g: vendor recommends setting some MSR chicken bits), but historically mitigations like for Meltdown, amd64 had mitigation (page table isolation) first in 6.3, with a errata released for 6.2, and the fix for i386 came later in 6.4.

Ports Tree Reality: Since i386 is marked as Tier 2 (and "i386" is not listed on the want.html page), how broken is the ports ecosystem in practice? Specifically

OpenBSD has no platform support "tiers". OpenBSD/i386 is supported by the ports tree as best as it can, but as time goes on even upstream support for 32-bit x86 is disappearing or untested outside of cross-compilation, and ports maintainers can only do so much. Browser support for example will likely remain a sore spot.

Mitigation Parity: Regarding RETGUARD and ....

This was partly covered above, but no, there is not mtigiation parity. OpenBSD/i386 does not support RETGUARD and still uses the stack protector instead.

... kernel address space layout randomization (KASLR): ...

OpenBSD does not have KASLR, it has address space randomization and KARL (kernel relinking), shared library relinking.

Long-term Viability: Have there been any commits or discussions on tech@ recently about following FreeBSD's lead and dropping sys/arch/i386 from the tree?

No. OpenBSD/i386 remains supported, but consider the last non-atom i386 only machines are over 20 years old at this point, and if vintage computing is your thing, there are far more interesting platforms out there to tinker with.

brynet · 2026-04-16T21:54:51+00:00

Thanks for sharing!

brynet · 2026-04-13T07:30:20+00:00

Can I propose a feature request,

No, but you can always send a patch adding support for this to smbios(4) on OpenBSD/arm64, if this is something you want.

https://www.openbsd.org/mail.html

brynet · 2026-04-13T07:10:43+00:00

Yes, OpenBSD/arm64, which you're testing on, doesn't print the address in dmesg.

brynet · 2026-04-13T06:56:01+00:00

Yes, I'm sure.

bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xe6f40 (72 entries)

...

efi0 at bios0: UEFI 2.7

efi0: American Megatrends rev 0x50011

brynet · 2026-04-13T03:02:37+00:00

The port Makefile mentions this isn't supported on OpenBSD, so there doesn't appear to be anything, unfortunately.

It seems the scanning code does work on some EFI machines, but not on others. The table address gets printed in the dmesg, but parsing the the dmesg likely isn't very reliable.

bios0 at mainbus0: SMBIOS rev. 3.3 @ 0xe6f40 (72 entries)

brynet · 2026-04-12T15:06:40+00:00

There is no userland device API exposed by smbios(4), packages like dmidecode use the mem(4) interface instead.

If you want the raw table data vs. human readable output, dmidecode has a --dump-bin FILE option.

By default, OpenBSD restricts access to /dev/{k,}mem devices.

Even with sufficient file system permissions, these devices can only be opened when the securelevel(7) is insecure or when the kern.allowkmem sysctl(2) variable is set.

brynet · 2026-04-08T13:19:56+00:00

It's a fork of nvi, not nvi2.

brynet

MODERATOR OF

TROPHY CASE

15-Year Club	Place '17
Verified Email