How do I go about debugging: "wineserver: file_set_error() can't map error: Cannot allocate memory" when running WINE in FreeBSD 14.3? Same app runs fine in WINE on Linux, but I want to try and get it working on FreeBSD if possible. Is there some sysctl setting interfering with WINE that I can check?

(Hope people are having fun at BSDCan! Wish I could have gone!)

pertho: It's terrible. Getting up early, coffee at cafes, working on bugs, getting stuff done. Terrible I tell you, terrible.

but on the plus side you get to run into dvl and he's great to chat with

kevans: Thank you, your bribe will be arriving soon.

=D

as of 14.3, i can't seem to have pkg_env: { HTTP_PROXY: "ip" } set in pkg.conf without causing pkg to error with pkg: An error occured while fetching package: No error six times

pkg seems to try to connect to pkgmir.geo.freebsd.org:443, which fails since my squid setup doesn't handle port 443, which worked fine for pkg for 5 or so years

can i get pkg to try to reach pkgmir.geo over port 80?

llua both should work fine, since the pkgmir is based on DNS. I tend to hardcode my repo addr, because the geomir is not setup properly for my country (working on sending a PR for that) but otherwise it should work fine via HTTP

I'm trying to port games/starlanes in ports to Linux, but I can't figgure out where the actual source code URL is... any help guys?

antranigv: where is it set? i already hardcode my FreeBSD.url value to "pkg+http://pkg.FreeBSD.org/${ABI}/latest"

dansimon it seems to be at SUNSITE/games/strategy

dansimon which is MASTER_SITE_SUNSITE+= \ ibiblio.org/pub/Linux/%SUBDIR% \ gtlib.gatech.edu/pub/Linux/%SUBDIR% \ ftp://ftp.icm.edu.pl/pub/Linux/sunsite/%SUBDIR% \ ftp://ftp.sun.ac.za/pub/mirrors/sunsite.unc.edu/pub/Linux/%SUBDIR%

llua pkg.FreeBSD.org is already the GeoDNS one: drill SRV _https._tcp.pkg.freebsd.org -> _https._tcp.pkg.freebsd.org. 300 IN SRV 10 10 443 pkgmir.geo.freebsd.org. ; and then pkgmir.geo.freebsd.org. 103 IN A 173.228.147.98 for me, might be different for you based on your location.

antranigv: Aha! Thanks :D

antranigv: ok, thank you

so what's the situation with these .pkgsave files? delete them? merge them? use something else to manage them?

to be clear, I upgraded from 14.X-release to 15.0-current

FYI - BSDCan is in progress now - bsdcan.org/2025/index.html - livestream and IRC chat available.

cyric, I got accused of that by helping someone in here a couple days ago.

hi, after upgrading to 14.3, dmesg complains that "amdgpu.ko depends on drmn - not available or version mismatch"

many other modules are reported as being newer than linker.hints as well

Maybe one ore more of those came from ports/packages that need upgraded?

39

I did pkg upgrade. let me find out if I have any ports installed

doesn't look like it, but there was a segfault during freebsd-update, which did not abort it

I'll reboot real quick

now I get "unsupported file type" when loading kernel modules

joes: Trey compiling drm-kmod from HEAD ports.

With the kldload command?

s/Trey/Try/

CrtxReavr: yes, but it is in kld_list in /boot/rc.conf

joes, It sounds like you are using the quarterly binary pkg packages. Those are compiled against the oldest supported kernel, which is now older than 14.3R and the ABI has changed and they are no longer compatible. This is a typical problem at this stage in the release lifecycle.

There is a project to produce precompiled binary pkgs for kernel modules for the current released kernel. I have people telling me (here at BSDCan!) that this is working. But when I tried it myself I could not make it work for me. But perhaps someone else has a solution for it.

In the meantime the best answer is to locally compile your kernel module against your currently installed 14.3-RELEASE system.

And next is to use Boot Environments to boot the previous working and consistent system reverting back to 14.2-RELEASE until this issue with the binary pkgs is resolved.

ugh. Does pkg keep a history of operations somewhere outside of /var/log/messages?

Second step shouldn't be necessary. Locally compiled port should work fine. I was compiling drm-kmod pulled from github.com/freebsd/drm-kmod, sometimes from some WIP branches, but it always worked alongside amdgpu module on my Ryzen systems.

rwp: yes thanks, any idea how long until it's resolved?

As in, before drm-kmod was available in ports.

joes: "quarterly".

as an unprompted aside, running freebsd has been *awesome*. Came over from Archliunx/Fedora to NetBSD to FreeBSD. NetBSD was nice, but FreeBSD is solid, performant, and has a lot more packages :)

wavefunction welcome to the club

perhaps i need to run a build server whose whole goal is just building ports-tree kmods against the newest supported kernel. but that's just idle bluster at this point

that's what the kmods repository is, and as far as i know it is working correctly, or at least several people reported success with it

I'm confused

is .pkgsave files the new files

or the old files

antranigv: .pkgsave is your old files that pkg replaced, usually because the file was newly added and you had an existing file of the same name

ok now it makes sense

but when upgrading, everything will be pkgsave

or rather, when migrating

so I should take care of my global changes

like passwd, group, etc

and then delete the rest, aye?

not when upgrading, because it only happens when the file is newly added. when upgrading you will get .pkgnew files instead, if pkg couldn't perform a three-way merge automatically

got it

okay so now... I've done something stupid

I ran this: find / -name "*.pkgsave" -type f -exec sh -c "f='{}'; echo '==== OLD ===='; ls -l \${f}; md5sum \${f}; echo '==== NEW ===='; ls -l \${f%.pkgsave}; md5sum \${f%.pkgsave}; cp -vi \${f} \${f%.pkgsave}" \;

are you switching from non-pkgbase to pkgbase? in that case yes, you should probably move *.pkgsave in /etc back to the original files. don't forget to run pwd_mkdb, etc

luckily I only did it on /etc

the pkgsave files in /lib, /usr/sbin, etc. you can just delete

so in /etc I do cp a.pkgsave a

but everywhere else I delete

but what if there's a change in pkgbase that I'm not aware of?

well, not everywhere in /etc, e.g. you probably want to delete pkgsave files in /etc/rc.d unless you manually modified them for some reason

because I'm moving from 14.2-RELEASE to 15-CURRENT

ok in that case, I will do a reinstall

of FreeBSD-*

i'm not sure what you mean by a change you're not aware of

for example, now that I did cp /etc/rc.d/jail.pkgsave /etc/rc.d/jail; I'm using the old version (14.2) of /etc/rc.d/jail

but maybe the new version has new code? which it does :P

so I guess I have to reinstall, and this time only cp foo.pkgsave foo only what I KNOW that I need, aka passwd, master, etc.

well, you shouldn't edit /etc/rc.d/jail, so after the initial migration to pkgbase this wouldn't be an issue. if you did edit it for some reason, and pkg can't merge the changes automatically, then you would have to check for new pkgsave/pkgnew files each time you upgrade

/etc/passwd is automatically generated by pwd_mkdb (or vipw) so no need to restore that

I see

(you do need to run pwd_mkdb, as this is required every time you change /etc/master.passwd)

can I do pkg install -g 'FreeBSD-*' in chroot?

let's find out after our break!

yes, although you might find "pkg -r /path/to/chroot install -g 'FreeBSD-*'" a bit more useful since otherwise you'd have to install pkg in the chroot first

yeah doing it that way

fwiw, this is (at least partly) documented at wiki.freebsd.org/PkgBase

yeah I'm documenting for myself

there were issues in that page

new changes etc

Epic: 0x0.st/8E05.jpeg

Is UltraSparc still supported?

Guess not.

NetBSD is cool. I appreciate the goal of supporting minor architectures because this is the attention causing them not to die. And in the 90s I've set up a few then-booming internet cafés in Lublin, Poland. From running CAT5 and clamping RJ45 to setting up FreeBSD on some PC to serve as NAT, gateway and samba. Cool gig for a 15yo. Most of these were FreeBSD but at one larger café I was assisting

a guy in charge who chose NetBSD. He later became NetBSD dev. Nonetheless, I have no shit to talk about NetBSD.

yeah, NetBSD is very Unix-y, and very useful for the whole open source community. I think overall the BSDs have been the best thing for open source, we focus on performance, NetBSD on portability, OpenBSD on security, HBSD on hardening and checking what breaks after hardening. Not sure what's the cool point of DragonflyBSD is tho, I have to use it one day. do they have jails? that would be cool.

and illumos of course!

ivy the migration worked, finishing my write up now.

ivy thank you for all the help

joes, Regarding kernel modules in ports: This is now old, but the description is good background: lists.freebsd.org/archives/freebsd-stable/2024-December/002589.html

In theory "man pkg.conf" in 14.3-RELEASE and later has an example "FreeBSD quarterly kernel modules repository configuration" so look at that section. But when I tried that solution yesterday it did not work for me. The problem was almost certainly me though.

speaking of jails .. have anyone tried kubernetes inside a freebsd-jail with linux compat?

BarnabasDK yes

BarnabasDK but I mean... the controller

controller == master node?

the need for docker / kubernetes is really the only thing keeping a lot of my hw on linux

I know I could run a virt env and a linux kernel on top, but I think that sort of defeats the purpose - then why not just run linux directly

> Not sure what's the cool point of DragonflyBSD is tho

antranigv: DragonflyBSD was spawned during 32-bit era disagreement about SMP/threading and scheduling-related stuff. I'm happy that dfBSD is thriving and I have mad respect for Matthew Dillon. No hostility between projects, licensing allowing mutually beneficial code sharing and I see it as something benefiting BSD open-source as a whole.

regis, don't forget all the filesystem squabbles too.

CrtxReavr: No impact on FreeBSD in this case.

Illumos had the greatest impact on FreeBSD with ZFS.

Dillon thought a lot of the direction that FreeBSD v5 was doing was a bad idea, so he forked 4.x into DragonFly and a few devs defected with im.

him

He wasn't entirely wrong. . . 5.x was NEVER stable on SMP systems, though they did get things ironed out and stable again in 6.x, plus got some new schedulers working well, etc.

it's old story; anyway, DragonFlyBSD is still alive !

Everything I ran FreeBSD on was SMP. . .

I think I kept everything on 4.11 'cept my workstation.

'Course. . . versioning 4.x up to 4.11 was it's own drama.

Remember the bikeshedding T-shirts?

Two out of three monitors disappeared on my desktop system as XRandr went missing after upgrading to 14.3-RELEASE. I guess that's another instance of quarterly ports being ABI incompatible one see in this channel history? Thus I likely do best in just waiting for a month? (Old bootenv works)

|cos|: "pkg upgrade -r FreeBSD-kmods" will fix the issue

mzar: thanks! that worked like a charm-

yw

if anyone needs this: antranigv.am/posts/2025/06/migratin…ith-pkgbase-using-boot-environments

antranigv: thanks, BTW is pkgbase based CURRENT using GENERIC or GENERIC-NODEBUG kernel config ?

mzar no clue. I just did pkg install -g 'FreeBSD-*'; I'll check now

it says main-n277903-a14573de29de GENERIC in uname

thanks

CrtxReavr: 5.x was stable "enough" to be considered prod worthy.

regis: no, it wasn't

CrtxReavr: also UFS2 was a huge improvement.

mzar: Have you ran jails on 4.x?

mzar: I've ran 5.x on prod and am happy to learn your opposite point.

regis: I can'r racall, probably not, was it even possible ?

regis: thanks for preserving good memories from 5.x times ;-)

mzar: Perfectly usable. From racked machines to small Compaq servers used for residential ISP NAT and hidden in some wall-mounted boxes in residential buildings basements.

regis: OK, I have had a bad experience, so I jumped over 5.x, please don't mind it

antranigv: thanks for that guide

In case someone needs to hear this: don't 'devctl detach' a nic via ssh

`ipfw flush` was fun in a similar manner, with default net.inet.ip.fw.dyn_keep_states=0.

14:58 < regis> CrtxReavr: 5.x was stable "enough" to be considered prod worthy.

That's a laughable comment to anyone who actually used 5.x.

Or even `ipfw /etc/ipfw.conf` with flush and rules.

CrtxReavr: Feel free to laugh then.

I mean. . . not non-SMP boxen, maybe it was okay.

s/not/on

But on SMP, it was random lock-up city.

CrtxReavr: SMP support was immature but you were not forced to use it. Apart from this, 5.x release was ok. I was using it partially on i386 and x86_64.

SMP support was fine on 3.x, 4.x, 6.x, etc. . . but never on 5.

The performance gains of SMP really turned a corner with the scheduling improvements that were developed in the 6.x era.

I've seen multi-processor vs. HyperThreading...

yep, I was running 4.x on SMP machine, it was 2x Pentium III

Actually, I'm reminded that sched_ule(4) did exist in 5.x, but it sucked until a ways into 6.x

it wasn't default at that time IIRC

I don't think it was.

CrtxReavr: My point: FreeBSD 5 was released around the same time as Pentium 4 with Hyper Threading. SMP for multi-processor systems and for HT are almost two different things.

And actually. . . it's been a while since I've tested, but FreeBSD & Linux both used to perform better with HTT disabled.

Windows made good use of it though.

In certain setups, like firewall - yup.

I ran 5.x in prod. They ran better than the Linux boxes they replaced.

That's not saying much.

:)