pkgbasify was _very_ easy on my end

i really want to get freebsd running on this rpi3, but i have no idea if there's any remotely feasible workaround for the wifi chip support without being insane and writing my own driver. i mean, it IS a project in and of itself, but man.. i really don't wanna buy an ethernet cable just for this. my router's like 500 meters away :(

half a km away? O.o

im exaggerating but it'd be a pain to lay cable

can you move the pi?

is there such a thing as ethernet to USB where i can use another computer as a hotspot or whatever it's called?

or are you trying to use it as a desktop

i can't move the pi, im limited to this room for my workstation. i really just wanted a BSD system to play with and use as a server for a couple things, and do some coding for. rpi 3 is no longer supported by the debian version of it

i mean i know broadcom chips never had a lot of support but damn it's been decades

rdr - do me a favor, make a quick guess before i head out

yeah it's hit or miss, my intel in my main works on freebsd but the wifi in my secondary doesn't

building a functioning driver for this wifi chip for freebsd - how many months, assuming i have ... i dunno, 2-3 free days a week, about 4-5 hours a day to work on it?

just a rough guestimate

or we talkin years

depends if a driver exists just isn't included i guess

assume none exists

yeah prolly a year or two

Matt|home: Any drivers are pretty decent sized undertaking. Have you emailed freebsd-wireless⊙fo to see if anyone else is already working on this?

I wouldn't surprised.

nope, this would be my first actual OS contribution. but as usual i get to do it because nobody else bothered to, so i'll clean up yer messes for ya -_-

oh... broadcom

Matt|home: building this out is going to be a bit rough as a first contribution for more than just 'wifi is hard'

s/more/more reasons/

SDIO on FreeBSD is basically non-existent; the MMCCAM bits were designed to support exactly this, but we don't have anything today hanging off of SDIO to try and model after

Yeah. Might wanna just grab a USB wifi adapter with a chipset that's supported.

Of course, FBSD would definitely welcome any Broadcom wifi drivers that you can provide.

with pkgbasify, should be I creating a boot environment before conversion?

doesn't hurt

I'm running the script based on the earlier conversations

ok so I noticed that pkgbasify is downloading 32-bit packages, even though I don't use them. I hope it doesn't install them.

i imagine it will

presumably you have /usr/lib32 populated, even if dn't use it?

ahh yes. I did. Its in my jails that I don't have 32-bit. My base does.

alright moment of truth, time to reboot the system. Lets see what happens. Although now with pkgbase I should be able to remove 32-bit stuff from base as I want to run a pure 64-bit system. All of that after the reboot. fingers crossed.

hmm

it'ss been four miutes should they be presumed dead?

phew, not dead after all

lol

i'm a bit paranoid about moving over to pkg too

i'm too used to the freebsd-update life

there's a notion that we'll have something like the freebsd-update frontend to provide a familiar interface

some of the upgrade incantations are kind of awkward and people do have a lot of freebsd-update muscle memorry

yes not dead!

:-)

for context: > 21:16 < kevans> it'ss been four miutes should they be presumed dead?

you made it at the six minute mark

Steps I took: fetch pkgbasify.lua ; ./pkgbasify.lua ; say yes to create a boot environment before conversion; verify three files that pkbasify tells you to; reboot. Done.

oooh six minutes from when I quiet to back? nice

377 packages downloaded, quit out of all tmux windows, rebooted, waited, ssh'd back in ... I did this remotely.

remotely = I'm downstairs, the mini-pc is upstairs lol

bold- oh, hah

still bold depending on what kind of creatures might be between you and the machine, though

I was getting worried and was about to go up, but decided to do one last ssh invocation, third time it worked.

i've made the mistake of crashing a machine on the wrong side of a sleeping baby

very true kevans, you never know when the OS gremlins show up

now let me check pkg.conf in /usr/local

ok so I have this in FreeBSD-base.conf: url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_release_4" and I am presuming that I would need to make that a "_5" when I want to upgrade to 14.5 ?

yesl

and if I want to upgrade to 15.0-STABLE ?

those are maintained outside of re@, you can choose either `base_latest` or `base_weekly`

you also have to swap the fingerprints, stable packages are signedd with the same key as ports

(that's where the 'maintained outside of re@' part comes in- it doesn't really matter outside of different keys)

Is this information on the wiki?

never mind I see it there

(wiki.freebsd.org/pkgbase for anyone else following along; there's a table that also describes the build frequency)

That table is outdated now isn't it, since there is a 15.0-RELEASE and a 15.1-RELEASE. What would the pathway be for 14.4 -> 15.1 ?

it's still more or less what the "Major version upgrades" describes, except the advice is terrible

ideally you end up invoking `upgrade` twice with a reboot in between them, the first time being something like `upgrade -x 'FreeBSD-kernel-*'`

s/-x/-g/

you don't really want to upgrade the running system in one-shot, you want to be on the new kernel to avoid breaking things mid-upgrade as things want to run post-install scripts and the system is a weird 15/14 hybrid on a 14 kernel

Or just state it with the -o ABI options.

Whoops. I didn't scroll down all the way.

well let me clean up base first, get rid of lib32 and see where things are after that

hmmm interesting, valgrind, llvm13, llvm15, gcc13, gcc14, julia, etc. all seem to depend on lib32 being available.

ah, yeah, shlib depends might be problematic

i think there was some work planned in this direction, but i don't recall at the moment

You can always wipe out lib32, then just reinstall whatever you need after again. It'll pull in needed dependencies.

It's just packages so it goes pretty fast. I remember having to do some dancing around as well. But, it was pretty painless.

yeah I think that might because I had initally, years ago, setup things as multi-lib and so had lib32 insatlled. This was with FBSD-9 or FBSD-10. Never changed anything through all the intermittent upgrades

It happens.

There's nothing wrong with keeping lib32 support. Especially now, It's all just packages. Updates are quick. If you're looking to save space and don't need them anymore, feel free to delete them.

It's just a thing.

yeah cleans up about 7GB, including the dependent packages. Lets see how much gets used up when I re-install the removed pacakges. Apparently Julia is not longer available

ok so technically its 1GB of space cleaned up. After re-installing everything back, I loose 6GiB of space. It does install 3 lib32 base packages.

FreeBSD-clibs-lib32, sqlite3-lib32, and runtime-lib32

did lang/julia get removed from pkg? 'pkg search julia' doesn't return the package anymore.

mns: It's still there in ports as far as I can see, but yeah, I don't see the binary package either.

And in particular cgit.freebsd.org/ports/commit/?id=e…93788126855cf21e34f2219ef8d87b3dfd9

yeah I see it in usr/ports/lang/julia just not the binary package. Not that I've been using it much lol

mason: that ports commit basically says that lang/julia was unexpired back in 2025 June, so should be available. I had 1.10.5_1 installed, which is the same version in /usr/ports

mns: you can spelunk through the bomb icons in pkg-status.freebsd.org to try and understand why

not sure what I'm looking at on that page.

Yes, it's a little bit mucb to sort through

you want the "package builds" section

pick a build of interest and click the bomb icon next to it to get build results

then filter through skipped/ignored for julia

thanks

I've got unbound (the ports install) supposedly starting up at boot time on a VPS, but it never starts. I have to manually start it. I tried interface: 0.0.0.0 .. I got unbound_enable="YES" in /etc/rc.conf.. I can see it trying to start at boot up but it never seems to finish. Does it have to start later in the boot process?

how do you manually start it? did you try /usr/local/etc/rc.d/unbound start - did you check if the rc.d script writes a log anywhere, did you try edit the rc.d script so it at least tries to start in the foreground?

service unbound restart

it logs to daemon.log but the logs aren't enough I think

I think it's trying to start unbound before the network interfaces are ready

so it never starts up properly

that's usually solved by the rc.d script and a magic comment, # REQUIRE: network or sth like that, fuzzy memory.

Maybe I should just restart it in /etc/rc.local :D

rc.local runs last doesn't it?

Yep I think so, late in the boot process anyway

rc.d scripts have a mechnaism to wait for network though, via magic comments.

yeah the unbound script starts before 'network' it seems

wait a sec and ill ask my robot

it's # REQUIRE: NETWORKING

you could try that

hmm neither putting '/usr/local/etc/rc.d/unbound restart' in /etc/rc.local nor putting NETWORK on the require line fixes it

thats very strange

ill check the port

it has: # BEFORE: NETWORKING

did you remove that?

yes.. removed that line and tacked NETWORKING onto the end of the REQUIRE: line

hmm doing one more reboot to check.. see, I wanted unbound to just bind to the wireguard interface so I stuck: "NETWORKING wireguard" to the end of the REQUIRE

so hopefully that will do the trick

not sure

yep that worked

cool, but weird, you might want to open a bug for that

I have to wonder.. why does the script set to start BEFORE: NETWORKING if unbound needs to bind to an interface/address in the first place?

exactly, im sure there's reasoning behind it, but i dunno what it is.

alright so I just ran a pkg update -r FreeBSD-base to get 15.1p1, and when I ran the same for the -ports repo, my kmods seem to be downgraded? for example, gpu-firmware-radeon-kmod-r700: 20220511.1501000 -> 20260519.1500068 [FreeBSD-ports]

I know the part after the YYYYMMDD is related to a freebsd release

.1501000 is 15.1-RELEASE I think

I'm trying to understand why it asks me to "downgrade" my kernel modules when I do pkg upgrade -r FreeBSD-ports, but these modules are not candidates for upgrades when I simply run pkg upgrade without specifying a repo

Hi! I want to know more about FreeBSD or (original BSD) philisophy / concept / manifesto

deeppandya: cscie2x.dce.harvard.edu/hw/ch01s06.html

pertho: Thanks for the link. I found that it's mostly technicality of the program development. I was just cehcking it BSDs have any philisiohical aspect like GNU has ethical one

Typo: ...checking *if* BSDs have...

Nope not really.

pertho's link best describes it. when you read between the lines even technical documents are built on ideas and concepts you can apply back to the real world, but whether or not that's intended is another thing.

in fact i would say that link is excellent. bookmarked and reflecting.

bsdrobert: yes, I haven't found such excellent description before. Let me save link given by pertho

deeppandya: in a nutshell, OpenBSD focusses on security, NetBSD on portability, and FreeBSD for servers (though, increasingly desktops and laptops now that a lot of wifi work has been done)

got it.

deeppandya: one of the key differences between Linux and the BSDs is that the Linux is just "the kernel". The packaging and system around Linux is all on the distributions. The BSDs come the with a complete kernel AND base user space. On top of that you can of course install packages (or compile ports from source), but a BSD will always have a complete base system on installation.

So you can always be sure the kernel and userspace are properly in sync and maintained together on a BSD.

pertho: Yes, I know that's what caught my interst for BSD which maintains kernel + userland.

In linux, it is GNU and Linux. It can be GNU+Bsd kernel or GNU+Hurd also

pertho: another project gained my interst was Hyperbola which is GNU/FSF endorsed distro who planned to migrated to Hyperbola BSD from GNU/Linux because their developers dissatisfied with Linux kernel developemnt

There's been Linux/BSD crossover projects. I seem to remember Debian had something where it ran the FreeBSD kernel but had GNU userland or something

Oh wow.. it's still around? "Debian GNU/kFReeBSD".. I thought it was discontinued years ago. Anyway..

pertho: I am leaving IRC at the moment for another work, you may know more about me from deep-pandya.codeberg.page

deeppandya: ok good luck

will meet later. Good-buy!

*good-bye!

I guess a good hint that I'm using pkgbase is that my cron job for 'freebsd-update fetch' says that freebsd-update can't run on a pkgbase system. I'm offically on pkgbase at 14.4p7

hmmm I have lmdb-1.0.0 installed, but pkg wants to replace that with lmdb0-0.9.35

how do I find out which package is causing the downgrade?

I suspect it is neomutt as thats the only other package in the list when I do 'pkg upgrade'

pkg info -r -x lmdb

You should be safe to downgrade most likely though.

switching from newer to legacy?

Yes, and it's very possible that things silently break with 1.x

This is the reason why they dialed back to 0.8

yeah

0.9 even

you want the downgrade

an upgrade broke a bunch of things so it was walked back to lmdb0 to better execute the upgrade

got it

mason: wrt container docs feedback is welcomed let me know what to change or ofc send a patch

dch: I'm going to try to get some time to implement the stuff, which should highlight any rough edges. There were some wording issues, but not with the patch - with the already-extant surrounding text. I'll come up with suggestions once I've run through it in practise.

really appreciated thanks!

As soon as a couple more pieces come in I'm spinning up a new workstation and I can devote it to testing there. Primary goal for the thing will be evaluating FreeBSD as a desktop once more. I try periodically.

Videoconferencing usually nukes it, but I'm feeling inspired.

has anyone ever had to blocklist one of the wifi drivers so a different one successfully attaches?

I'm working on getting my office together after working off a laptop for a few years, and will likely add a PC desktop to the mix...

I've been seeing that you can get some older video cards that still perform OK if you're not asking for a whole lot, but in general for FreeBSD (or even Linux since I guess we kind of depend on Linux stuff?) is the easy direction AMD or Nvidia?

nvidia drops support for older cards with their main driver (which is available on FreeBSD) so often AMD can be a lot less painful

AMD drivers are fully FLOSS so most of the time an old Radeon is mature and reliable.

NVIDIA is still a reverse engineered driver. In my use I was (past tense) running two NVIDIA gpus and it became unstable with kernel panics after an upgrade. I removed them and replaced with an AMD. It's been rock solid since. Meanwhile, I switched desktops to an HP t740 with a built-in Radeon and it has been solid.

yeah i replaced an older NVIDIA with an AMD and have had much less issues on both Linux and FreeBSD :)

spork_css: FWIW, I'm getting an older Radeon for this next workstation I'm spinning up, which will run FreeBSD 15.1.

I've successfully used nVidia in the past, but I'd like to be away from them.

On the Linux side the free software reverse engineered nouveau driver was, past tense, quite good but then a couple of years ago they started rewriting it (or something) and I found it became completely unstable. Panics and crashes. That pushed a lot of people to the proprietary driver. But then you need to find a good version and stick with it.

rwp: Counterpoint, Nouveau fell over every time I'd try it in the past, so I only run nVidia proprietary drivers. Which is part of why I want to move to AMD.

Counterpoint to THAT, though, is that I've had awful luck with AMD cards.

You probably used the nouveau during the later years when it was also falling over for me too. it's just not worth the frustration so I avoid NVIDIA now.

I am a craphound so I am only using old lower power non-gaming AMD GPU cards. I try to stay away from anything that requires a fan. Because fans fail and are noisy and if it needs a fan then it is just going to be wasting power for me. My most stressful use of video is playing videos and these days that's a tame operation for most graphics adaptors.

yeah rwp the proprietary one is pretty decent, but only if your card supports it. amdgpu driver is pretty good (getting better) and like that other person said the radeon driver is still serviceable for old old cards

My current AMD is a Raven Ridge built-in on the t740. I am driving 4x 1920x1200 displays. It handles it with no problem. My previous was a HD 5500 Cedar driving two displays.

I've got a Radeon Pro WX 3100 on the way. It has a fan, but is pretty low-power.

Does anyone know if something changed with the nginx-full package? pkg upgrade wants to remove it (on 14.4)

joemie: i'm not sure, did it install something to replace it?

nope. If I do a pkg search nginx the full-version isn't there (anymore)

That sounds like a build failure.

Meanwhile... I mostly switched to the "freenginx" branch a short while ago.

joemie, Are you on quarterly or latest?

rwp: latest

Looks like it is either still building or failed a build. It's just temporary in the grand scheme. But you could switch back to quarterly and have that version available for install now and then switch back after it is installed.

Thanks for the suggestions

If you have installed nginx-full on a similar system then you could look in /var/cache/pkg/ and see if you still have the .pkg files cached there and install the same version on your new system that you have installed on the other system that has this cached.

I'll wait a bit, I didn't let it deinstall, so still up and running atm

joemie: could be extra safe and stick a `pkg lock` on it

if i wanted to renice a service, but that service spawns its own subprocesses (like execve() or whatever), do those child processes inherit the (in this case) lower priority?

does the service have it's own uid?

apt nickname :) it does

you can renice a uid

although it's already in a jail, so perhaps i can just nice the whole jail since it's a dedicated service (it-notes.dragas.net/2024/07/11/limi…ng-process-priority-in-freebsd-jail)

i wonder if i should nice my jellyfin jail

yeah, this is a sabnzbd jail, and when it's repairing/extracting it just seems to block everything else on the system

huh, can't say i've seen tht happen before

alright anyone here know how to get the geli decryption prompt to be sent via serial?

everything after geli decryption works (the freebsd boot screen)

but I still cant get the geli part to go via serial

i think you've kind of exhausted your options, beyond a custom setup to get options to the earlier stages

/boot.config isn't usable when it's gated behind the passphrase that you need to enter, and the BIOS boot chain doesn't really leave us any other options that I see

(custom setup or converting to UEFI)

kevans: oh so if you uefi boot it works?

right??? :p

if you use uefi boot you can place options on the ESP

hmmm

so probably, yes, it can be made to work without much hassle

well server has uefi support, someone else said it was easier with bios boot iirc

with any luck it might even work out of the box

lemme try switching to uefi boot shortly, see if that works.

not really sure what to stick into the ESP though

firmware might describe the serial connection in ConIn/ConOut so that it all Just Works(TM), but if it doesn't you can use /efi/freebsd/loader.env on the ESP

do you hve an ESP already, or starting from scratch?

ahoy! my nvidia quadro m2000 doesn't work with the proprietary nvidia driver: running X or Wayland makes the kernel suffer a page fault in kernel mode

this is the first time i've tried nvidia proprietary drivers in freebsd. the m2000 requires 580 legacy drivers (boo). i have tried each of the 511, 6something, and 6something else versions of the kmod package

i've decrypted my swap and obtained a crash dump i can inspect

this card was just working in debian so it's not ba... er, well, it's not faulty :)

am i barking up the right trees?

#9 0xffffffff8375bf65 in drm_stub_open () from /boot/modules/drm.ko

to the /usr/src !

oh that is in a port lol

oh i have not looked in the bugzilla

hum i am using 15.1-RELEASE; i could try CURRENT

read bugs.freebsd.org/bugzilla/show_bug.cgi?id=290471