11:50:21 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? 11:54:24 (Hope people are having fun at BSDCan! Wish I could have gone!) 11:55:11 pertho: It's terrible. Getting up early, coffee at cafes, working on bugs, getting stuff done. Terrible I tell you, terrible. 11:57:05 but on the plus side you get to run into dvl and he's great to chat with 12:00:37 kevans: Thank you, your bribe will be arriving soon. 12:39:53 =D 13:07:10 as of 14.3, i can't seem to have pkg_env: { HTTP_PROXY: "http://ip" } set in pkg.conf without causing pkg to error with pkg: An error occured while fetching package: No error six times 13:16:00 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 13:16:16 can i get pkg to try to reach pkgmir.geo over port 80? 13:45:22 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 13:49:13 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? 13:49:33 https://www.freshports.org/games/starlanes 13:50:42 antranigv: where is it set? i already hardcode my FreeBSD.url value to "pkg+http://pkg.FreeBSD.org/${ABI}/latest" 13:51:42 dansimon it seems to be at SUNSITE/games/strategy 13:52:06 dansimon which is MASTER_SITE_SUNSITE+= \ https://www.ibiblio.org/pub/Linux/%SUBDIR%/ \ http://www.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%/ 13:54:06 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. 13:54:57 antranigv: Aha! Thanks :D 13:57:17 antranigv: ok, thank you 14:03:51 so what's the situation with these .pkgsave files? delete them? merge them? use something else to manage them? 14:04:06 to be clear, I upgraded from 14.X-release to 15.0-current 14:11:32 FYI - BSDCan is in progress now - https://www.bsdcan.org/2025/index.html - livestream and IRC chat available. 14:59:16 cyric, I got accused of that by helping someone in here a couple days ago. 15:11:22 hi, after upgrading to 14.3, dmesg complains that "amdgpu.ko depends on drmn - not available or version mismatch" 15:11:46 many other modules are reported as being newer than linker.hints as well 15:12:45 Maybe one ore more of those came from ports/packages that need upgraded? 15:15:13 39 15:20:14 I did pkg upgrade. let me find out if I have any ports installed 15:29:27 doesn't look like it, but there was a segfault during freebsd-update, which did not abort it 15:38:42 I'll reboot real quick 15:55:31 now I get "unsupported file type" when loading kernel modules 15:56:07 joes: Trey compiling drm-kmod from HEAD ports. 15:56:09 With the kldload command? 15:56:26 s/Trey/Try/ 15:57:16 CrtxReavr: yes, but it is in kld_list in /boot/rc.conf 15:58:28 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. 15:59:36 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. 16:00:05 In the meantime the best answer is to locally compile your kernel module against your currently installed 14.3-RELEASE system. 16:00:38 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. 16:02:16 ugh. Does pkg keep a history of operations somewhere outside of /var/log/messages? 16:03:29 Second step shouldn't be necessary. Locally compiled port should work fine. I was compiling drm-kmod pulled from https://github.com/freebsd/drm-kmod, sometimes from some WIP branches, but it always worked alongside amdgpu module on my Ryzen systems. 16:04:03 rwp: yes thanks, any idea how long until it's resolved? 16:04:14 As in, before drm-kmod was available in ports. 16:04:27 joes: "quarterly". 16:08:42 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 :) 16:17:09 wavefunction welcome to the club 16:26:50 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 16:28:37 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 16:30:12 I'm confused 16:30:20 is .pkgsave files the new files 16:30:22 or the old files 16:30:46 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 16:30:53 ok now it makes sense 16:31:04 but when upgrading, everything will be pkgsave 16:31:08 or rather, when migrating 16:31:15 so I should take care of my global changes 16:31:20 like passwd, group, etc 16:31:25 and then delete the rest, aye? 16:31:33 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 16:31:45 got it 16:31:55 okay so now... I've done something stupid 16:32:05 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}" \; 16:32:15 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 16:32:15 luckily I only did it on /etc 16:32:43 the pkgsave files in /lib, /usr/sbin, etc. you can just delete 16:33:09 so in /etc I do cp a.pkgsave a 16:33:14 but everywhere else I delete 16:33:27 but what if there's a change in pkgbase that I'm not aware of? 16:33:40 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 16:33:54 because I'm moving from 14.2-RELEASE to 15-CURRENT 16:33:59 ok in that case, I will do a reinstall 16:34:05 of FreeBSD-* 16:34:09 i'm not sure what you mean by a change you're not aware of 16:34:50 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 16:35:01 but maybe the new version has new code? which it does :P 16:35:49 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. 16:35:50 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 16:36:16 /etc/passwd is automatically generated by pwd_mkdb (or vipw) so no need to restore that 16:36:24 I see 16:36:37 (you do need to run pwd_mkdb, as this is required every time you change /etc/master.passwd) 16:37:28 can I do pkg install -g 'FreeBSD-*' in chroot? 16:37:59 let's find out after our break! 16:38:06 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 16:38:48 yeah doing it that way 16:39:39 fwiw, this is (at least partly) documented at https://wiki.freebsd.org/PkgBase 16:39:50 yeah I'm documenting for myself 16:39:57 there were issues in that page 16:40:00 new changes etc 16:46:00 Epic: https://0x0.st/8E05.jpeg 16:48:10 Is UltraSparc still supported? 16:49:59 Guess not. 16:50:12 * CrtxReavr goes off to get banned from #netbsd. 17:01:02 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 17:01:04 a guy in charge who chose NetBSD. He later became NetBSD dev. Nonetheless, I have no shit to talk about NetBSD. 17:07:11 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. 17:07:17 and illumos of course! 17:07:36 ivy the migration worked, finishing my write up now. 17:07:42 ivy thank you for all the help 17:14:31 joes, Regarding kernel modules in ports: This is now old, but the description is good background: https://lists.freebsd.org/archives/freebsd-stable/2024-December/002589.html 17:17:23 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. 17:18:08 speaking of jails .. have anyone tried kubernetes inside a freebsd-jail with linux compat? 17:32:50 BarnabasDK yes 17:32:56 BarnabasDK but I mean... the controller 17:54:50 controller == master node? 17:55:42 the need for docker / kubernetes is really the only thing keeping a lot of my hw on linux 17:56:44 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 18:01:36 > Not sure what's the cool point of DragonflyBSD is tho 18:06:28 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. 18:06:51 regis, don't forget all the filesystem squabbles too. 18:07:55 CrtxReavr: No impact on FreeBSD in this case. 18:08:28 Illumos had the greatest impact on FreeBSD with ZFS. 18:09:25 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. 18:09:29 him 18:10:35 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. 18:10:42 it's old story; anyway, DragonFlyBSD is still alive ! 18:11:30 * mzar jumped over 5.x from 4.11 to 6.x 18:12:28 Everything I ran FreeBSD on was SMP. . . 18:13:09 I think I kept everything on 4.11 'cept my workstation. 18:13:37 'Course. . . versioning 4.x up to 4.11 was it's own drama. 18:14:10 Remember the bikeshedding T-shirts? 18:15:25 <|cos|> 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) 18:18:27 |cos|: "pkg upgrade -r FreeBSD-kmods" will fix the issue 18:40:49 <|cos|> mzar: thanks! that worked like a charm- 18:41:06 yw 18:52:53 if anyone needs this: https://antranigv.am/posts/2025/06/migrating-to-freebsd-current-with-pkgbase-using-boot-environments/ 18:57:11 antranigv: thanks, BTW is pkgbase based CURRENT using GENERIC or GENERIC-NODEBUG kernel config ? 18:57:36 mzar no clue. I just did pkg install -g 'FreeBSD-*'; I'll check now 18:58:08 it says main-n277903-a14573de29de GENERIC in uname 18:58:18 thanks 18:58:55 CrtxReavr: 5.x was stable "enough" to be considered prod worthy. 19:00:04 regis: no, it wasn't 19:00:39 CrtxReavr: also UFS2 was a huge improvement. 19:01:54 mzar: Have you ran jails on 4.x? 19:05:43 mzar: I've ran 5.x on prod and am happy to learn your opposite point. 19:06:06 regis: I can'r racall, probably not, was it even possible ? 19:06:48 regis: thanks for preserving good memories from 5.x times ;-) 19:09:03 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. 19:13:50 regis: OK, I have had a bad experience, so I jumped over 5.x, please don't mind it 19:23:01 antranigv: thanks for that guide 19:51:17 In case someone needs to hear this: don't 'devctl detach' a nic via ssh 19:57:47 `ipfw flush` was fun in a similar manner, with default net.inet.ip.fw.dyn_keep_states=0. 19:58:01 14:58 < regis> CrtxReavr: 5.x was stable "enough" to be considered prod worthy. 19:58:16 That's a laughable comment to anyone who actually used 5.x. 19:58:26 Or even `ipfw /etc/ipfw.conf` with flush and rules. 19:58:49 CrtxReavr: Feel free to laugh then. 19:59:13 I mean. . . not non-SMP boxen, maybe it was okay. 20:00:12 s/not/on 20:00:39 But on SMP, it was random lock-up city. 20:00:55 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. 20:01:41 SMP support was fine on 3.x, 4.x, 6.x, etc. . . but never on 5. 20:02:39 The performance gains of SMP really turned a corner with the scheduling improvements that were developed in the 6.x era. 20:02:41 I've seen multi-processor vs. HyperThreading... 20:04:03 yep, I was running 4.x on SMP machine, it was 2x Pentium III 20:05:30 Actually, I'm reminded that sched_ule(4) did exist in 5.x, but it sucked until a ways into 6.x 20:07:03 it wasn't default at that time IIRC 20:08:26 I don't think it was. 20:09:03 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. 20:10:10 And actually. . . it's been a while since I've tested, but FreeBSD & Linux both used to perform better with HTT disabled. 20:10:25 Windows made good use of it though. 20:10:38 In certain setups, like firewall - yup. 20:14:23 I ran 5.x in prod. They ran better than the Linux boxes they replaced. 20:15:50 That's not saying much. 20:16:07 :)