03:10:06 Hm, I'd never before noticed that /var/db/freebsd-update can get unexpectedly large. 03:11:10 Ah, mostly in files/ 03:12:30 And, the man page nails it: "All files under /var/db/freebsd-update/ may be deleted if an upgrade is not in progress and rollback will not be required." 04:07:43 I'm trying to jump over to 15, to see if the 6.6 DRM drivers work better, following the directions from https://wiki.freebsd.org/action/show/pkgbase 04:08:32 pkg-static spits out a bunch of stuff about "cannot solve problem using SAT solver" and a bunch of lines with "require rule", asking me if I want to remove kf6-kiconthemes from the request 04:10:02 josephholsten: so it was just a resolv.conf issue? Glad you sorted it out. And about that big container library, when you say porting, are you working on some kind of FreeBSD compatible podman registry? 04:10:19 do I want to remove it? isn't that going to result in me rebooting into a half-upgraded system? 04:14:11 I haven't used KDE for many years, but it looks like it provides just a couple of theming libs. Worst thing is KDE could be somehow borked if you have heavily customized it 04:15:15 * divlamir off to work 04:15:17 I'm not even using KDE. something else pulled KDE Frameworks in as a dependency 04:15:41 saying yes it's also having a problem with kf5-kcmutils 04:17:19 and kf6-kservice, kf6-knotifications, kf5-kdeclarative, kf6-kxmlgui, kf6-karchive, and a *bunch* of other KDE Frameworks packages 04:17:59 pkg info -r ... 04:18:56 I'm wondering if this is because I don't have an already fully updated set of packages here on 14 04:19:34 seems Falkon brought in these dependencies 04:28:10 I'm going to try to upgrade base first, and then upgrade non-base packages after, see if that works 04:35:58 also, base_latest for 15 is now being built from stable/15 right, and I'd need to ask for 16 if I wanted to track main? 04:44:01 following the wiki's instructions, I'm not sure which of these pkgbase packages in 15, but not in 14, are actually things I want to install 04:59:38 it seems like 15's base_latest kernel packages actually predate stable/15 being forked: FreeBSD-kernel-generic-15.snap20250904204618 05:00:10 got suspicious when I noticed the generic-nodebug package showing up in my uninstalled packages 05:00:43 how do I upgrade to stable/15 or the ALPHA1 snapshot from a 14-STABLE pkgbase system? 05:02:51 anyone have /usr/obj on tmpfs, i,e building world/kernel on tmpfs? if yes, does META_MODE work? for me having /usr/obj on tmpfs not working with META_MODE, each build is from scratch 05:05:42 I thought base_latest was supposed to be built twice daily, so if it were tracking stable/15 at this point surely it'd have some packages that were built later than sept 4th 05:32:01 it's weird, 14's base_latest is up to date, 16's base_latest is up to date, but 15's is not 05:33:20 I'd prefer to avoid needing to bother with the nodebug kernel stuff 05:43:21 whatever, I guess I'll just settle for the outdated packages for now, and just manually select the nodebug kernel. hopefully this is sorted out before ALPHA2. it would just be nice to be able to find any information as to what's going on 05:44:04 all I can find is https://mail-archive.freebsd.org/cgi/getmsg.cgi?fetch=55791+0+current/freebsd-pkgbase 06:58:30 so my guess that the SAT solver errors could be avoided by upgrading base separately was incorrect. upgrading still wants to remove a bunch of packages: https://termbin.com/0oni 06:58:38 how can I avoid having these all uninstalled? 06:59:24 am I really going to have to allow this, and just install them all manually afterwards? 07:47:29 so for whatever reason, running this upgrade to 15 has apparently caused the font size in the bootloader and VT to become huge 07:47:40 so big that the bootloader menu doesn't even display fully anymore 07:51:10 really odd, since the loader still has a warning about needing to be updated, making me think it hasn't actually been modified, yet it evidently has been 08:08:01 fixed the font wonkiness with screen.font in loader.conf, and I got those packages reinstalled that the initial pkg-static upgrade couldn't figure out for whatever reason 08:08:45 but drm-66-kmod does not build on the 15.0-PRERELEASE build available through pkgbase 08:09:07 so this was more or less pointless 08:10:32 https://termbin.com/b2qw 08:12:04 has anyone else run into this? 08:16:34 either your build host or source is old. you can have easy (temporary) fix by adding the prototype. 08:17:40 this is the latest 15.0 snapshot available from pkgsrc, and I just did a git pull on ports 08:17:56 check with cc -E option which headers are used (where from) and if origin is updated to include the needed prototypes. 08:19:13 tm512: have you tried with an older drm-kmod (drm-61-kmod)? 08:19:18 modern compilers default to require prototypes for functions. 08:19:41 jkm: I'm trying a 61 build right now 08:20:03 but the only reason I decided to try 15 so early is to get away from 61 08:20:09 On GH (https://github.com/freebsd/drm-kmod-firmware): "For 6.1-lts (Supported on FreeBSD 15.0 and above)" 08:20:36 so I guess 6.1 should be supported on 15.0 08:20:48 the 6.1 DRM drivers work on 14 as well 08:21:21 but the amdgpu driver suffers from GPU hangs on my hardware 08:21:44 I'm trying to see if 6.6 fixes the problem 08:22:18 Yes, I know your pain - have the similar issue with my i915 08:22:47 I really wish 5.10 just remained supported on the 14 branch, because those were the only ones that worked for me, but I guess those are "too old" 08:23:01 drm-61-kmod builds just fine 08:23:38 Try to run it let me know if your GPU hangs on 6.1 08:23:41 tsoome: and yes, but obviously the drm-66-kmod package is intended to be built on a modern compiler without modification 08:24:25 if not - I will try to upgrade to 6.1 on my side too 08:25:28 jkm: 6.1 is the version with the GPU hangs, at least on FreeBSD 14. I doubt 15 will make a difference here 08:26:40 5.15 causes kernel panics for me after a while, and 5.10 works but I can't downgrade to FreeBSD 13 to continue running those on a supported release 08:26:48 s/works/worked/ 08:26:54 tm512: hmm... so I will not bother upgrading from my ancient 5.10 for now - anyway thanks for info 08:27:11 you're still on FBSD 13? 08:27:30 No, 14.3 08:28:18 support for 5.10 got dropped as of the 14.2 release though...? 08:28:58 Oh really? 08:29:06 Ok, I will build 6.1 anyway 08:29:48 the Makefile for the port blocks building 5.10 on 14.2 and newer, so unless it does just continue working if you stick with a binary made on 14.1 or earlier? 08:30:21 tm512 the issue about too big font has 2 causes -- the root cause is that large font was added (32x64 - you can comment it out from /boot/fonts/INDEX), and there was a bug in automatic font selection code which caused too large font to be picked -- we should not get terminal screen smaller than 80x24. 08:31:02 so the bug was revealed when this large font was made available;) 08:31:09 is anyone else here on FreeBSD 15? can you confirm whether drm-66-kmod fails to build with the current ports tree? 08:37:11 I guess I could just install the binary package. I think the only reason I started building the package from source is because there was a window of time where the package was for 14.2, and not compatible with the current 14-STABLE 08:44:14 dev_is_removable is supposed to be located in sys/compat/linuxkpi/common/include/linux/device.h in the source tree, but I don't know where that header is supposed to end up on an installed system for me to check 08:45:50 find /usr/include -name device.h :) 08:46:06 the file is present under /sys, but its modification date is from aug 2024... 08:46:37 there's no device.h under /usr/include 08:47:07 have I screwed up my install somehow? 08:47:51 not sure. if #include file is missing, compiler will be very angry on you, so it has to find it. 08:48:32 the compiler isn't complaining about a missing include, it's complaining about an implicit declaration (see the termbin link I posted) 08:49:04 yes and your compiler command line does have -I/usr/src/sys/compat/linuxkpi/common/include 08:49:28 so thats the place it is looking for 08:53:22 so my install is screwed up somehow. I've got FreeBSD-src and FreeBSD-src-sys packages installed from the base_latest repo for FreeBSD 15 08:53:36 yet this header hasn't been touched in over a year? 08:54:00 what is git branch telling there? 08:54:42 .oO probably nothing if its just plain source tree 08:55:22 "not a git repository" 08:55:41 mhm, no .git there, as I figured. 08:56:00 are you sure the src package is the latest for 15? 08:56:50 it's FreeBSD-src-sys-15.snap20250904204618 08:57:48 tm512: ok, I tried to build drm-61-kmod from ports, but it failed on amd step, so I have built drm_kmod_drm_v6.1.128_4 manually from git with amd and radeon kmods removed from DEFAULT_KMODS in Makefile 08:57:49 https://cgit.freebsd.org/src/tree/sys/compat/linuxkpi/common/include/linux/device.h?h=stable/15 08:58:13 tm512: it works on my side (i915kms) on 14.3-RELEASE 08:58:27 but I don't have 15.0 setup to test :( 08:58:47 currently stuck in a VT without an easy way to copy-paste links into a browser. does that revision of device.h have dev_is_removable()? 08:59:22 I'm not quite sure what is happening about this src package, but yes, the file there has the dev_is_removable (its static inline actually) 09:00:10 so, your option would be to install git and checkout stable/15 branch into /usr/src and then your build could be happy(er) 09:01:05 probably worth to report an bug about this package. 09:03:12 jkm: you do need to remove them from DEFAULT_KMODS in Makefile, you just do: export KMODS="..." and it will be the ones set compiled, 09:03:12 am, could it be the source package is about 15.0 actually? 09:03:20 I went and untarred the FreeBSD-src-sys package in /var/cache/pkg, and its device.h has this function as well. but for whatever reason, /usr/src/sys at least is not being touched by the package 09:03:22 is how i build only i915kms 09:04:09 export KMODS="i915kms drm ttm dmabuf" is what only needed 09:04:20 looking at /usr/src overall, it seems like the latest modification here was june 9th 2025 09:04:23 same goes for gpu firmware 09:04:24 so, if you uninstall FreeBSD-src-sys, verify its really gone from /usr/src/sys and install it again? 09:05:22 I can try that, but it leaves me wondering what other components on my system are not being updated, if any 09:05:44 if it's happened to /usr/src, presumably it could happen with other packages 09:08:31 removing FreeBSD-src{,-sys} complains about a bunch of missing files and leaves an incomplete removal. plenty is still left under /usr/src 09:09:24 pkg check maybe. 09:10:05 fortunately /usr/src can be wiped clean and re-populated. it does not affect the running system 09:14:40 right, I figured that was the path forward at this point, but I'm worried my running system is some kind of FrankenBSD now between 14 and 15 (and maybe even with various versions of 14 at this point) 09:16:42 it would have been nice to check whether pkg check would have caught the issue with the src tree though, to see if it would catch any other issues. I should've cloned this BE first 09:19:57 so /etc/ssl/cert.pem has a checksum mismatch with the ca_root_nss package, but that's it so far 09:29:59 is it expected that ca_root_nss will have a checksum mismatch? in the package tarball, /etc/ssl/cert.pem is a symlink 09:32:14 if they store ca roots into one file (which is checksummed) and something else will add cert there, then its expected. 09:34:46 apparently this is an issue with the ETCSYMLINK port option on 15, which is fixed in the port, but there isn't a package for it yet 09:35:39 I know it's supposedly bad practice to mix ports and packages, but building this one from ports seems pretty low risk? 09:50:43 angry_vincent: good point, thanks 09:50:55 drm-66-kmod still fails to build, with different errors this time: https://termbin.com/2188 09:56:48 at this point /usr/src/sys/sys/vnode.h should be the very latest from the FreeBSD-src-sys package 09:59:04 I'm so confused by this 09:59:33 nobody else appears to be dealing with build errors 10:05:52 I'd contact with maintainer about it. 10:10:05 I guess I will give up on having this solved before I have to go to sleep, and just stick with 6.1 for now here on 15, assuming I don't run into even more with 15 that forces me to just rollback to 14 10:10:15 brb, rebooting 10:15:05 nevermind, drm-61 kernel panics on 15. back on 14 10:15:11 what a pain in the ass 10:16:37 this is the kind of stuff that was making me hesitant to try 15 this early, but the prospect of less broken GPU drivers tempted me 10:17:54 the kernel panics were dropping into a debugger, too, they weren't core dumping and rebooting like they do on the default config for 14 10:18:24 not sure how to get a shareable dump/backtrace from there 10:18:39 <[tj]> that might just be default flags for the debugger 10:19:39 <[tj]> you should look at `sysctl -a | grep panic` and see if anything is set in a way that will actually stop on a panic 10:19:50 <[tj]> but if you dump core you can just load the core 10:19:58 I suspect it has to do with the extra debugging options that were enabled when 15 was -CURRENT. the snapshots available through pkgbase predate the forking of stable/15 10:20:09 <[tj]> yeah we change the defaults for releases 10:22:33 the kernel panics were happening on driver initialization, so before I have an opportunity to tweak sysctls 10:22:52 I guess I could block the driver from loading automatically, and kldload it 10:23:17 but if I could just manually dump from the debugger, that works 10:27:26 oh, huh, so the firefox package for 15 is pretty outdated. I wonder if that's part of why that initial upgrade attempt from 14, specifying the 15 ABI, couldn't figure out how to deal with firefox (and other packages) 10:29:56 that might've caused issues with firefox complaining about a profile downgrade, if I had managed to reach a desktop on 15 10:31:40 kinda surprised by how much the 15 packages are lagging, firefox hasn't gotten any updates in almost 3 weeks? 10:52:13 is there the possibility of just using the firefox package built for 14 on 15, or is backwards compatibility not that consistent? 10:52:25 maybe it'll be moot by the time I actually manage to get 15 to work properly 11:31:06 so around thanksgiving is RELEASE for 15? 11:38:56 HI 11:41:39 Macer: https://www.freebsd.org/releases/15.0R/schedule/ 11:42:29 yeah that's what i was looking at. good stuff. couple more months :) i thought bout going with CURRENT but it's ok for me to wait 11:42:43 i'm all about it for zfs 2.3 for raidz expansion 11:44:31 i'm going to make a 3 disk raidz2 vdev and keep expanding it so i can get rid of older, smaller drives gradually 11:53:14 Macer: 15.0 # zfs -V -> zfs-2.4.0-rc1-FreeBSD_g00dfa094a zfs-kmod-2.4.0-zfs-2.4.0-rc1-FreeBSD_g00dfa094a 15:08:42 Well, this isn't good. Updated a host from 13.2 to 14.3... and I'm updating bootcode... now this is something I usually do for zpools, but this one is ufs 15:08:46 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0 15:08:46 gpart: /dev/da0p1: not enough space 15:09:02 it's only: 34 128 1 freebsd-boot (64K) 15:14:16 ha... too small 15:14:27 you need 512k 15:19:47 mzar: so, no update here. However, there was a failed update of this host last week, but it was rolled back for some other reasons, not for bootcode. 15:20:01 mzar: worst case, I can reboot, see if it works. If not, rollback. 15:21:36 Do anyone know if this is arcconf is still available somewhere else on the web? https://paste.ubuntu.com/p/BbVfMGNdcV/ 15:23:24 here goes... weeeeee! 15:24:02 mzar: it boots. 15:25:23 Mzar: oh. My mistake. I remember AllanJude said it was going to be released in sync with zfs 2.4. 15:26:04 Which is more awesome. lol. I think I’ll bite the bullet and go CURRENT on my nas then go to RELEASE afterwards (if that’s a thing). 15:27:34 dvl: perhaps you can reduce swap and create another freebsd-boot part, make it bootable and install loader there 15:27:59 Macer: yep, follow his guidance 15:28:15 mzar: Perhaps one day. 15:28:28 mzar: or we could just redeploy the host. 15:28:46 is it a VM ? 15:30:32 mzar: Yes, it is. 15:30:55 mzar: It is so old it still uses UFS for the boot/main drive 15:33:09 zfs is convenient 15:37:53 * CrtxReavr is a UFS luddite. 15:43:17 come to the dark side, we have cookie. 15:45:06 I thought the darkside was hammerfs :) 16:04:34 it boot was small on vm, it would be easier to reimage it? 16:05:19 Hi 16:05:44 avoid zfs hassle by *not* having root-on-zfs. just use zfs for data 16:05:46 Thank's for the fix yesterday.. 16:06:16 I succeeded in making pipelight to use native wine 16:06:34 have a different disk for booting/running the os and swap 16:06:44 Is zfs on root a hassle on fbsd? 16:07:08 it's easy to set up, but what happens when there's a zfs problem? 16:07:26 same what happens when you have ufs problem. 16:07:30 I’ve never seen an issue with it in my experience. 16:07:37 what happens if there's ufs problem? 16:07:41 :p 16:07:43 yeah 16:07:44 in worst case you restore from backup. 16:08:00 zfs is more complex for sure 16:08:01 less likely with ufs because it's just been around a lot longer 16:08:08 I usually mirror zroot. 16:08:16 in this case bootloader doesn't fit 16:08:37 zfs has been around sine 2005 (in public), thats 20 years. how long must be "long"? 16:08:38 zfs is on 20 years isn’t it? 16:08:56 i have had a vm (zfs internally) bon-bootable because of changes on the host wrt zfs 16:09:15 I’d expect more an issue with zol but not really on fbsd just because it is so baked in. 16:09:17 also, ufs on freebsd does receive updates even now, so its not as old as you may want to believe. 16:10:08 zfs problems from host? 16:10:10 how 16:10:17 relatively easy to replace the os disk with a standard install then zfs import the data 16:11:10 my single qemu vm runs ufs 16:11:21 i wonder what it would do on zfs 16:11:41 it'd run 16:11:44 it already builds pkg in 4h eh 16:12:38 sure it runs 16:13:05 bonus would be no fsck 16:17:03 i could actually fully nfs it maybe 16:17:21 large parts of it is on nfs 16:17:51 v3, without locks, so it fails for some things :p 16:18:10 Ketas: but what is the underlying fa qemu is using? 16:18:14 it's my armv7 current vm where i build stuff for embedded 16:18:16 *fs 16:18:21 zfs 16:18:28 file 16:18:40 re zfs issues, context was arm64 and EFI baremetal, the loader needs to be upgraded between major versions as it doesn't happen automatically. the loader would not have been an issue wrt booting is all zfs was just data and not zfs-on-root 16:18:51 So it’s ufs running on top of zfs. :) 16:19:34 f451: using fbsd? 16:19:41 s/if/was/g 16:19:45 yes 16:19:51 yes, the loader has to kept up to date 16:20:07 s/to/to be 16:20:09 That’s not done automatically? 16:20:09 thread is here 16:20:13 -drive file=/root/files/qemus/yellowgreen/.img,format=raw,discard=unmap,detect-zeroes=unmap 16:20:24 that's what it's disk is 16:20:25 not, that's your duty 16:20:37 no, fbsd does not update loader automatically. 16:20:56 FreeBSD user is sysadmin, responsible for the maintentace of the OS 16:21:39 Ah. You’d think that would be a thing. I mean admin has to do all updates anyways right? 16:21:39 use sysutils/loaders-update 16:22:00 this attracts many hobbyists to FreeBSD 16:23:01 Those are the sorts of issues I’d expect from zol. I’ve actually ran into that before where zfs was updated but module wasn’t since it has to do the whole GPL/cddl double dutch. 16:23:21 i already asked if it could updated automatically 16:23:28 the loader 16:23:42 it's difficult too 16:23:52 there are always + and - sides on automation. altho, I haven't heard much down sides from automated illumos bootloader updates;) 16:23:56 like, where is the loader? 16:24:02 is it on efi part? 16:24:07 on which disk it is? 16:24:29 on how many disks is in on, etc 16:25:00 root disk(s) and efi + freebsd-boot (if present). its that simple. 16:25:26 but where are the root disks? 16:25:28 however, it needs versioning, so you wont downgrade it accidentally. 16:25:48 would that be foolproof to autoassume? 16:25:50 zpool status or see /etc/fstab 16:26:09 zpool layout is easy to parse. 16:26:48 yeah one could look if it had loader before 16:27:11 but i see so many failure point 16:27:13 s 16:27:46 (am looking for the thread that was posted about it - machine not booting after source upgrade. thing is, it wasn't upgrade btwn major versions, it was upgrase stable/14 to a later stable/14) 16:28:49 but basically i could have wholly avoided the issue to not have root-ob-zfs 16:29:17 it's only zfs issue? 16:29:19 upgrading from sources is fastest method 16:29:23 loader is old? 16:29:31 tsoome: a piece of me wants to try illuminos just because I miss opensolaris but then I try to boot it and it doesn’t for install lol 16:29:35 and was it fixed0 16:29:36 ? 16:29:46 considering stable is for devs 16:29:50 it's the only zfs issue i had - well it's the only one i mention here 16:30:18 sure it's a ooh crap moment 16:31:03 that loader isn't able to read a disk and now you have to boot external 16:31:05 ok found thread - it's here: https://lists.freebsd.org/archives/freebsd-arm/2023-October/003137.html 16:31:59 yee, its telling loud and clear, one important bit was not updated. 16:33:15 it nearly bite my ass too i think 16:33:16 many years ago, there was issue you had to update system firmware to be able to run next version of os. 16:33:43 on solaris? 16:34:10 how would you update firmware now if os won't run :) 16:34:27 yep, on some sparc, can not remember which... 16:35:05 you do not necessarily need os to update system firmware. 16:35:24 *your* os, that is. 16:35:38 anyway this auto loader update could fail too 16:35:44 who knows 16:36:02 if I remember correctly, this supermicro of mine was needing dos for it;) 16:36:35 sparc dos? 16:36:46 they made it? 16:36:47 i assume it was an x86 16:37:00 supermicro X10SAE (x86) 16:37:12 I think, i used freedos or something like- 16:39:22 I'm not really sure what was the thing about the sparc fw update, because the early kernel start is using forth hooks on sparc, it may have been some new words were needed with new kernel. 16:46:24 Cool, didn't know that sysutils/loaders-update was included in the ports tree. Saves some time, especially if you have EFI/BIOS boot partitions, mirrored... that makes four loaders to update :) 16:48:06 wasn't aware of sysutils/loaders-update that must be a relatively new port 16:48:59 Oct last year 16:50:27 Do use `show-me` before you shoot yourself in the foot :D 16:50:34 back 16:50:41 :D 16:54:10 Actually with UEFI esp you can actually keep your old loader around for a case the new one may be bad. 16:56:41 Hm, this sounds like a good strategy with a mirrored setup, to update only half the mirror, and if all is good update the other hlaf then 16:56:54 *half 16:58:20 yes, except with some systems its really annoying to attempt to boot from other half;) 16:59:24 which is why many x86 admins insist on having those raid adapters;) 17:02:14 Mmm, hardware raid, sounded so fancy reading about those in computer magazines in the 1990s .. 17:02:42 small computer running its own os;) 17:04:03 wouldn't touch it with a stick 17:04:13 as long as we have zfs 17:11:27 raid cards make booting easier? 17:11:50 i thought they just corrupt your data 17:12:07 more easily 17:12:14 ;) 17:12:23 the have to sell them somehow 17:13:00 recently someone was losing one of 8 hdd and in the end it was either disk issue or lsi issue but not fbsd 17:13:17 but card nicely did hide it up 17:13:20 or whatever it was 17:14:10 owner of a card was confused as card ran "direct" firmware 17:15:16 btw how would one move disks to different machine? 17:15:28 i mean virtually 17:15:56 i recall people sometimes use zfs via iscsi or perhaps ggate 17:18:10 tho at that scale, maybe it's good idea to run something on top instead 17:20:27 Never tried iSCSI, every time I think of it I end up usin plain old NFS 17:21:13 Haven't stumbled upon a usecase for it I guess 17:26:51 There's nvmf(4) too: https://www.freebsd.org/status/report-2023-04-2023-06/nvmf/ 17:34:29 Anyone knows if bluetooth is working on a raspberry pi? I doubt it very much as it's on the same broadcom crap with the wifi, and yet..? 18:12:28 Does anyone know if it's still possible to build a port that's all statically linked? 18:17:52 I don't know but speaking of ports, poudriere started giving me `unhandled error` and doesn't even try to build in a fresh jail. Should I nuke it all, and reisnatll poudriere? Try poudriere-devel? 18:20:23 Using -vv does show more info in the preparation stage, but nothing more about the error 18:41:35 Hi 18:42:00 There is problem here.. 18:42:45 Pipelight needs xattr to run.. is it supported on freebsd? 18:47:49 oh, after more search found user_xattr is supported 18:48:20 but It scares me mounting my / using it, will break the system? 18:49:39 Retrofan: Take a look at rmextattr(8) maybe? 18:50:33 it supported but it just mounting the root partition scares me 18:50:47 using it 18:51:06 could I separate home away from it? 18:52:13 For now, I will try it on my testing partition 18:58:39 You can separate them, sure. 18:58:52 Might already be separated if you're using ZFS. 18:59:37 I will try 18:59:37 no zfs 18:59:38 I want to use zfs now 18:59:39 I really liked 19:00:09 it but the ram usage of it is high :( 19:00:55 You can limit it, if you'd like. 19:01:23 could it only use few MBs? 19:01:43 I suppose so. Likely wouldn't be prudent, though. 19:05:22 What is it using ram for? Usually it’s just arc isn’t it? 19:06:00 Afaik arc will dial down if the system calls for more app memory. 19:06:40 Somewhere read that a 8gb system will die using it.. 19:07:26 Retrofan54: Maybe a very long time ago. These days, it's nothing like that. I have VM's with 1GB RAM using ZFS without any problems at all. 19:08:43 I am using my pc for many heavy stuff.. so it will continue work 19:09:49 8GB systems barely existed outside of enterprise hardware when ZFS was released, the original requirement was like 2-4GB, 4GB being better... nowadays i've used it with no problems on 1GB VMs, although setting an arc limit helps 19:10:47 the problem originally was that ARC doesn't release memory fast enough when an application needs it, that's been improved a lot (particularly in 13.x) but on very small systems it's still not perfect, which is why the limit helps 19:10:59 s/13.x/14.x 19:12:05 Yep. I haven't had any problems in the last couple years, for sure. 19:12:29 yeah the UNIX philosophy.. 19:12:51 the other problem with ZFS originally was that it likes a lot of VM and 32-bit systems don't have much, obviously nowadays that's not an issue 19:16:55 Anyone know if any of the other *bsd's have leading spaces on wc output? 19:17:09 ZFS was vicious on i386 19:18:50 mzar: you said to me that your a freebsd desktop user 19:19:14 sure 19:19:27 So just curios what is your setup.. 19:19:35 like X stuff 19:19:36 I am using FreeBSD for everything 19:19:48 :O 19:19:52 XFCE4 works OK 19:20:24 Then you are not a customize fan? 19:20:42 not at all 19:21:02 plain setup... 19:21:22 that's proven to work 19:21:23 I am running zfs on 1GB RAM virtual machine systems and everything has enough memory there but I would consider that the floor RAM size for a zfs system. 19:22:05 Everything just consumes so much RAM. The more RAM you can have (up to a point) the better everything operates. 19:22:18 * Retrofan54 After realize that I worked on my custom Xorg setup for 8 months.. 19:23:10 sure, in the past we were running ZFS on i386 with 512MB of RAM, but this machine retired before FreeBSD 10.0-RELEASE IIRC 19:31:17 rwp: 1GB is barely enough for pkg nowadays, although i think that might be a bug 19:31:28 i had to bump a few 1GB VMs to 2GB just to run pkg upgrade without running out of memory 19:45:38 lol 19:45:59 Makes you wonder what pkg is REALLY doing. 19:52:38 ivy, Any swap configured? Looking at one VM I have 512MB of swap and pkg is okay memory wise there. But the floor size disk space for zfs on 14.3R is around 4GB of storage. I can't keep any Boot Environments. If I do then those quickly consume too much space and I hit that frequently during upgrades and have to bectl destroy BEs to free space first. 19:54:15 The solution to all of these is mostly just money. Rent more RAM+storage. This is only a problem on rented VPS where I am trying to scrape by with the least cost. Any bare metal hardware bought these days will have plenty of both. 19:54:45 yeah, i do that on my own hardware but this was a project that needed a bunch of small VMs in different locations 19:54:51 so trying to save money :-) 19:55:01 Trying to save money here too! 19:55:26 Storage is the biggest driver of expense. Storage is expensive to rent. RAM is cheaper. 20:04:20 I guess I'll try again to see if I can find some resolution to this. can anyone else reproduce this drm-66-kmod build failure on 15.0? https://termbin.com/2188 20:05:07 starting to suspect that upgrading to 15 from 14 via pkgbase just ruined the system 20:07:13 my /usr/src/sys/sys/vnode.h file matches the one here: https://cgit.freebsd.org/src/plain/sys/sys/vnode.h?h=stable/15 20:10:37 tm512: this looks like a bug in the header (if it's meant to be self contained) which you could raise on current@ 20:11:26 1500063 is outdated 20:11:42 ALPHA1 is 1500064 20:12:24 mzar: I'm aware, but the pkgbase packages are out of date 20:12:31 OK 20:13:35 I would like to find some explanation as to why the supposedly twice-daily builds haven't been uploaded in a week, but there's basically nothing last I checked 20:14:42 the drm-66-kmod binary package seems to have been built against 63 just fine though (see the Packages section) https://www.freshports.org/graphics/drm-66-kmod/ 20:14:58 is pkgbase built in poudriere ? 20:15:16 tm512: bapt is actively working on pkgbase builds for both 15.0 and 16, you should ask this on pkgbase@ so he's aware there is a problem 20:16:29 it is literally one guy maintaining this, so the answer to "i don't understand why these packages aren't what i expect" is to ask him why that is 20:19:20 I've never actually used mailing lists for any project, and I don't want to end up subscribed to one 20:19:47 does seem like there is already a mention of the problem on the list, but there hasn't been any response https://mail-archive.freebsd.org/cgi/getmsg.cgi?fetch=55791+0+current/freebsd-pkgbase 20:19:51 well, if you want to run prerelease builds you are sort of expected to report problems on the lists, if you choose not to do that they won't be fixed and you'll never know why 20:21:51 would the current mailing list really be the most appropriate for build failures on 15.0? 20:22:52 also I guess to clarify I don't really *want* to run prerelease, but I want working GPU drivers, which 14 no longer provides after dropping support for the 5.10 drivers 20:23:28 I guess all of this is what I get for not just installing Linux on this laptop though 20:23:44 i think either stable@ or current@ would be fine, but since there hasn't been a 15.0 release yet i'm not sure anyone is discussing it on stable 20:24:16 14.3 has drm-61-kmod 20:25:20 5.15 and 6.1 both have issues that seriously hinder system usability. 6.6 is only available on 15 and 16 20:25:36 I'm wanting to try out the 6.6 drivers 20:25:36 upgrade then 20:26:05 I did, but 6.6 won't build 20:26:33 hence the build failures I pasted https://termbin.com/2188 20:30:19 so yeah, going up through the nested includes (vnode.h, list.h, wait.h), SHA256 matches between my 15.0 install and the headers from the stable/15 branch on the upstream repo 20:30:20 bummer... 20:33:35 last night I had to sort out this issue where the entire /usr/src tree was not actually being managed by pkg (causing a different set of failures). after sorting that out, pkg check reports no further issues with the base system, but I'm wondering if there's still further corruption or something 20:33:45 like if something about the compiler got messed up 20:36:09 from my experience drm-66-kmod builds fine in recent stable/15 20:37:11 * ketas curses a lot 20:37:27 tr a-z A-Z failed due locale 20:37:48 you need something more sophisticated 20:38:09 there's 0 cases where a-z needs locale 20:38:12 :/ 20:39:00 locale causes your acme.sh to fail!!! 20:39:51 well, locale does not fail, programmers do;) 20:40:39 well tr could be free form text processing tool that supports all langs but 20:40:41 eh 20:43:17 tr '[:lower:]' '[:upper:]' 20:43:36 mzar: seems not unlikely that going from 14-STABLE to 15.0-PRERELEASE via pkgbase has left this install FUBAR 20:43:54 but I would expect pkg check to complain about checksum mismatches or missing files or the like 20:44:17 "echo abc | tr '[a-z]'" -> "Ac" 20:44:32 tsoome: yeah, that's what i patched into acme.sh 20:44:36 tm512: could be, perhaps some header files are missing or outdated 20:45:10 other patch uses check and then switches to lower <-> upper 20:45:34 tm512: can you see commit hash in uname ? 20:47:20 mzar: but as I mentioned, all of the system headers match upstream, I verified the hashes (at least for the headers involved in the first build error: list.h, wait.h, and vnode.h 20:48:03 tsoome: what about tr -cd '[:print:]' < /dev/urandom | head -c 32 ? :) 20:48:06 what about sources ? do they match ? 20:48:26 also doesn't do what one honestly expects 20:49:24 the drm-66-kmod sources? I'll have to check that out a bit later, gotta go on some errands 20:49:25 you are expecing valid utf-8 sequences from /dev/urandom?:) 20:50:11 no i expected it to contain, well, printables 20:50:26 i have no idea what actually does 20:50:33 it 20:51:14 to get those, you need to grab byte stream, convert it to your charset (iconv) and then you you have something. 20:52:28 because multibyte chars have specific structure, you can not get that from random number generator. 20:53:14 yeah they are all "printables" i guess 20:56:53 printable is defined via locale charset, modern locales are based on UTF-8, so the classification is based on UTF-8. unless you are using 8-bit charset... 21:00:52 i think world is filled with horrors 21:02:16 i think tr was once also helpful to included superscript 2 in numbers too 21:02:27 because it's a number!!! 21:03:07 can't replicate it now 21:03:17 yeah this is wrong tool 21:06:43 once you go utf-8 you enter true hell 21:06:58 can't even trust eyes now :p 21:08:39 oоοօ 22:03:31 mzar: so you were referring to the drm-66-kmod source archive, right? make install on the port does not complain about any checksum mismatch after fetching the sources, so... 22:31:05 is there a command we can run to purge all swap currently in use? 22:31:15 i wanna reset swap usage back to 0% without reboot 22:32:06 i see 'swapoff -a && swapon -a' in web search is that still the way? 22:35:09 kerneldove: There's generally little reason to do this. But yes. Be prepared for it to take a long time if you have a lot swapped out. You're forcing the system to do more work than it'd like. 22:38:45 how long is a lot of time? what if a lot was swapped out, prog using tons of mem is closed so tons of mem is now free, then i toggle swap? 22:53:35 ah it's fast 22:53:43 basically instant 23:31:52 made my own "me too" post to the github issue about GPU hangs on drm-61. seems like another person also was able to reproduce it 23:32:18 im sorry you experienced that 23:35:28 hopefully the GPU hanging issue gets a quick resolution, but dunno how likely that is 23:37:44 it seems the initial poster of issue has the exact same iGPU that I do, so even though it seems to manifest somewhat differently for them, hopefully it's the same root cause 23:48:21 I think while I was browsing around I did find a patch that supposedly allows drm-510 to be built on recent 14-STABLE so maybe I should just find that again 23:50:53 I wish compatibility was just retained to begin with. with just how finicky GPU drivers are on FreeBSD, really sucks to lose access to the one version that worked okay for me 23:55:45 kerneldove: That really depends on load and workload generally. Glad it was fast. 23:58:04 gtk ty 23:58:29 If the system needs any pages that are swapped out then it will swap those pages back in as they are needed. There is no need to pre-load the memory with those pages again.