ant-x: there's "drm-kmod" which you could look into, not sure if that solves your issue, but to me it sounds like it could

ant-x: im curious about the current state of wireless on those rpi sbc's could you get the wireless chip identificator?

i did an custom solution with rpi4+freebsd once ago, i never intended to even use the wifi anyways, anyworks great in the GPIO but interrupts handlers were not implemented yet

s/anyworks/everything works/

i'm uh, cursed

MelMalik: What!?

i just wrote a program to feign ld-elf.so.1 into working in a setuid context (because I needed to make an -o PRELOAD library work alongside the X server, which is started using a setuid wrapper). the program chmods itself to all zeroes does setuid(0), and then forks and execs &argv[1]. it is extremely dangerous. i am honor bound not to give out the source code.

The program itself is not stored with the SUID bit set.

I'm not gonna lie... That does sound just a bit dangerous!

Only a bit?

Gee whirlickers.

Haha. Now you're quoting something from the 60's or so. Must be rough!

This is the kind of programme nobody should ever write, ever.

If it works for you, great! But, I wouldn't share it as it obviously cannot be trusted.

I'm also unsure of the reasoning behind it (but i'm sure there is.)

I write a lot of things that I don't share because it's insanely insecure. I trust myself to use it, but I'd hate for it to get into the wrong hands.

I needed to attach a leak-finder library to the Xorg executable. This was, amazingly, the easiest way to do that.

Make sense to me.

I've got something installed via ports and I want to prevent it from getting updated via pkg, how would I do that?

mns: pkg lock

bpa.st/WRZA hmm how the fuck does freebsd fuck up so badly, I thought I didn't update to -p3 but I did, freebsd-version shows -p3 and openssl version is 3.0.16 (freebsd.org/security/advisories/FreeBSD-EN-25:07.openssl.asc)

im scrubbing my zroot right now to see if there has been corruption

but I assume this was caused by freebsd-update messing something up last update

bmake question, I want do so something like `export FOO=important` at the top of this makefile so it is accessible to all the commands used later on

in this case, its a https:// url so make reads it as a target

armin, re: drm-kmod> thanks. The docs say drm-kmod supports Intel and AMD graphics hardware, whereas I RPi is likey using something else. By the way, in the past I /have/ solved a similar problem in Linux by passing drm.edid_firmware=DP-2:edid/1280x1024.bin to the kernel!

That is, a told it which EDID info to use instead trying to auto-detect it.

BarnabasDK, while I am taking a break from the RPi setup before I get me an Ethernet cable for network, can you explain in more detail what you mean by saying that "the res really makes no sense with relation to the console"? Here is are the resolutions of some standard text modes: <en.wikipedia.org/wiki/VGA_text_mode#PC_common_text_modes>. Do they make any sense to you?

deepend, I send that e-mail from my personal PC using the Sylpheed mail client.

ant-x: there's "hdmi_mode" in config.txt on the raspberry pi, but it's too long ago and I can't recall what exactly this does anymore; you're right about drm-kmod however, it seems to only cover AMD/Intel.

I totally confused about that config.txt. Which component reads that file? It it Raspbian, then why FreeBSD is reading it too? Or is the reading of that file hardwired into RPi?

ant-x: wiki.freebsd.org/arm/Raspberry%20Pi#Console_output_on_HDMI

The Pi OS uses cmdline.txt instead: <raspberrypi.com/documentation/compu…tml#kernel-command-line-cmdline-txt> .

armin, in my case, I see the rainbow color screen only at boot time, but then it starts showing normal console output.

(in 640x480)

I think it is normal behavior: RPi /always/ shows the rainbow screen after it is turned on, and then proceeds to booting.

armin, the advice to turn off hdmi_safe has helped! <wiki.freebsd.org/arm/Raspberry%20Pi#RPI4_and_RPi400_Notes>. The note is bit wrong it menitoning only X.org resolution, because it affects the console, too. I'll fix entry.

Now I have a normal 1600x1200 console.

ant-x: cool, I haven't used a Pi in a veeeery long time, I admit it. :)

Now at least I can diagnose the other errors in relative comfort.

ant-x: regarding sync: operating systems buffer some stuff that gets written to block storage in ram, to not block the program until the write fully happend (as storage devices are slow compared to ram), sync waits until all those buffered writes happened, after the dd it could be that stuff is just in the ram buffer and if you remove the sd card then, the write would be incomplete on the sd card

polarian: tried rm -rf /var/db/freebsd-update/* and then freebsd-update fetch - again?

tercal: doesnt matter im up to date

nimaje, re: sync> I understood that much after you recommended to call sync. Thanks.

?

the same sync again ?

ant-x: sync && sync && poweroff ;-)

mzar, just a belated confirmation.

Yes, the one!

so it finally helped ?

I didn't find poweroff, and used shutdown now...

mzar, what helped me, was to specify hdmi_safe = 0 in /boot/msdos/config.txt .

thanks for the report

It's the least I could have done.

Hi. Just tried loading 14.2 on a Thinkpad Z60m (i386), which promptly panic-d

right after apic0: <TP-77>

this also happens on 13.5-RELEASE

however, the ancient 12.1 that I had on there works fine

anyone else run into this?

__sbrk: Have you tried disabling apic to see if that allows it to boot?

Anyone else having problems with Discord?