Hm, I'd never before noticed that /var/db/freebsd-update can get unexpectedly large.

Ah, mostly in files/

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."

I'm trying to jump over to 15, to see if the 6.6 DRM drivers work better, following the directions from wiki.freebsd.org/action/show/pkgbase

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

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?

do I want to remove it? isn't that going to result in me rebooting into a half-upgraded system?

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

I'm not even using KDE. something else pulled KDE Frameworks in as a dependency

saying yes it's also having a problem with kf5-kcmutils

and kf6-kservice, kf6-knotifications, kf5-kdeclarative, kf6-kxmlgui, kf6-karchive, and a *bunch* of other KDE Frameworks packages

pkg info -r ...

I'm wondering if this is because I don't have an already fully updated set of packages here on 14

seems Falkon brought in these dependencies

I'm going to try to upgrade base first, and then upgrade non-base packages after, see if that works

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?

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

it seems like 15's base_latest kernel packages actually predate stable/15 being forked: FreeBSD-kernel-generic-15.snap20250904204618

got suspicious when I noticed the generic-nodebug package showing up in my uninstalled packages

how do I upgrade to stable/15 or the ALPHA1 snapshot from a 14-STABLE pkgbase system?

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

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

it's weird, 14's base_latest is up to date, 16's base_latest is up to date, but 15's is not

I'd prefer to avoid needing to bother with the nodebug kernel stuff

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

all I can find is mail-archive.freebsd.org/cgi/getmsg…tch=55791+0+current/freebsd-pkgbase

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: termbin.com/0oni

how can I avoid having these all uninstalled?

am I really going to have to allow this, and just install them all manually afterwards?

so for whatever reason, running this upgrade to 15 has apparently caused the font size in the bootloader and VT to become huge

so big that the bootloader menu doesn't even display fully anymore

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

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

but drm-66-kmod does not build on the 15.0-PRERELEASE build available through pkgbase

so this was more or less pointless

has anyone else run into this?

either your build host or source is old. you can have easy (temporary) fix by adding the prototype.

this is the latest 15.0 snapshot available from pkgsrc, and I just did a git pull on ports

check with cc -E option which headers are used (where from) and if origin is updated to include the needed prototypes.

tm512: have you tried with an older drm-kmod (drm-61-kmod)?

modern compilers default to require prototypes for functions.

jkm: I'm trying a 61 build right now

but the only reason I decided to try 15 so early is to get away from 61

On GH (github.com/freebsd/drm-kmod-firmware): "For 6.1-lts (Supported on FreeBSD 15.0 and above)"

so I guess 6.1 should be supported on 15.0

the 6.1 DRM drivers work on 14 as well

but the amdgpu driver suffers from GPU hangs on my hardware

I'm trying to see if 6.6 fixes the problem

Yes, I know your pain - have the similar issue with my i915

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"

drm-61-kmod builds just fine

Try to run it let me know if your GPU hangs on 6.1

tsoome: and yes, but obviously the drm-66-kmod package is intended to be built on a modern compiler without modification

if not - I will try to upgrade to 6.1 on my side too

jkm: 6.1 is the version with the GPU hangs, at least on FreeBSD 14. I doubt 15 will make a difference here

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

s/works/worked/

tm512: hmm... so I will not bother upgrading from my ancient 5.10 for now - anyway thanks for info

you're still on FBSD 13?

No, 14.3

support for 5.10 got dropped as of the 14.2 release though...?

Oh really?

Ok, I will build 6.1 anyway

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?

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.

so the bug was revealed when this large font was made available;)

is anyone else here on FreeBSD 15? can you confirm whether drm-66-kmod fails to build with the current ports tree?

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

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

find /usr/include -name device.h :)

the file is present under /sys, but its modification date is from aug 2024...

there's no device.h under /usr/include

have I screwed up my install somehow?

not sure. if #include file is missing, compiler will be very angry on you, so it has to find it.

the compiler isn't complaining about a missing include, it's complaining about an implicit declaration (see the termbin link I posted)

yes and your compiler command line does have -I/usr/src/sys/compat/linuxkpi/common/include

so thats the place it is looking for

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

yet this header hasn't been touched in over a year?

what is git branch telling there?

.oO probably nothing if its just plain source tree

"not a git repository"

mhm, no .git there, as I figured.

are you sure the src package is the latest for 15?

it's FreeBSD-src-sys-15.snap20250904204618

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

tm512: it works on my side (i915kms) on 14.3-RELEASE

but I don't have 15.0 setup to test :(

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()?

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)

so, your option would be to install git and checkout stable/15 branch into /usr/src and then your build could be happy(er)

probably worth to report an bug about this package.

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,

am, could it be the source package is about 15.0 actually?

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

is how i build only i915kms

export KMODS="i915kms drm ttm dmabuf" is what only needed

looking at /usr/src overall, it seems like the latest modification here was june 9th 2025

same goes for gpu firmware

so, if you uninstall FreeBSD-src-sys, verify its really gone from /usr/src/sys and install it again?

I can try that, but it leaves me wondering what other components on my system are not being updated, if any

if it's happened to /usr/src, presumably it could happen with other packages

removing FreeBSD-src{,-sys} complains about a bunch of missing files and leaves an incomplete removal. plenty is still left under /usr/src

pkg check maybe.

fortunately /usr/src can be wiped clean and re-populated. it does not affect the running system

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)

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

so /etc/ssl/cert.pem has a checksum mismatch with the ca_root_nss package, but that's it so far

is it expected that ca_root_nss will have a checksum mismatch? in the package tarball, /etc/ssl/cert.pem is a symlink

if they store ca roots into one file (which is checksummed) and something else will add cert there, then its expected.

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

I know it's supposedly bad practice to mix ports and packages, but building this one from ports seems pretty low risk?

angry_vincent: good point, thanks

drm-66-kmod still fails to build, with different errors this time: termbin.com/2188

at this point /usr/src/sys/sys/vnode.h should be the very latest from the FreeBSD-src-sys package

I'm so confused by this

nobody else appears to be dealing with build errors

I'd contact with maintainer about it.

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

brb, rebooting

nevermind, drm-61 kernel panics on 15. back on 14

what a pain in the ass

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

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

not sure how to get a shareable dump/backtrace from there

that might just be default flags for the debugger

you should look at `sysctl -a | grep panic` and see if anything is set in a way that will actually stop on a panic

but if you dump core you can just load the core

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

yeah we change the defaults for releases

the kernel panics were happening on driver initialization, so before I have an opportunity to tweak sysctls

I guess I could block the driver from loading automatically, and kldload it

but if I could just manually dump from the debugger, that works

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)

that might've caused issues with firefox complaining about a profile downgrade, if I had managed to reach a desktop on 15

kinda surprised by how much the 15 packages are lagging, firefox hasn't gotten any updates in almost 3 weeks?

is there the possibility of just using the firefox package built for 14 on 15, or is backwards compatibility not that consistent?

maybe it'll be moot by the time I actually manage to get 15 to work properly

so around thanksgiving is RELEASE for 15?

HI

Macer: freebsd.org/releases/15.0R/schedule

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

i'm all about it for zfs 2.3 for raidz expansion

i'm going to make a 3 disk raidz2 vdev and keep expanding it so i can get rid of older, smaller drives gradually

Macer: 15.0 # zfs -V -> zfs-2.4.0-rc1-FreeBSD_g00dfa094a zfs-kmod-2.4.0-zfs-2.4.0-rc1-FreeBSD_g00dfa094a

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

# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

gpart: /dev/da0p1: not enough space

it's only: 34 128 1 freebsd-boot (64K)

ha... too small

you need 512k

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.

mzar: worst case, I can reboot, see if it works. If not, rollback.

Do anyone know if this is arcconf is still available somewhere else on the web? paste.ubuntu.com/p/BbVfMGNdcV

here goes... weeeeee!

mzar: it boots.

Mzar: oh. My mistake. I remember AllanJude said it was going to be released in sync with zfs 2.4.

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).

dvl: perhaps you can reduce swap and create another freebsd-boot part, make it bootable and install loader there

Macer: yep, follow his guidance

mzar: Perhaps one day.

mzar: or we could just redeploy the host.

is it a VM ?

mzar: Yes, it is.

mzar: It is so old it still uses UFS for the boot/main drive

zfs is convenient

come to the dark side, we have cookie.

I thought the darkside was hammerfs :)

it boot was small on vm, it would be easier to reimage it?

Hi

avoid zfs hassle by *not* having root-on-zfs. just use zfs for data

Thank's for the fix yesterday..

I succeeded in making pipelight to use native wine

have a different disk for booting/running the os and swap

Is zfs on root a hassle on fbsd?

it's easy to set up, but what happens when there's a zfs problem?

same what happens when you have ufs problem.

I’ve never seen an issue with it in my experience.

what happens if there's ufs problem?

:p

yeah

in worst case you restore from backup.

zfs is more complex for sure

less likely with ufs because it's just been around a lot longer

I usually mirror zroot.

in this case bootloader doesn't fit

zfs has been around sine 2005 (in public), thats 20 years. how long must be "long"?

zfs is on 20 years isn’t it?

i have had a vm (zfs internally) bon-bootable because of changes on the host wrt zfs

I’d expect more an issue with zol but not really on fbsd just because it is so baked in.

also, ufs on freebsd does receive updates even now, so its not as old as you may want to believe.

zfs problems from host?

how

relatively easy to replace the os disk with a standard install then zfs import the data

my single qemu vm runs ufs

i wonder what it would do on zfs

it'd run

it already builds pkg in 4h eh

sure it runs

bonus would be no fsck

i could actually fully nfs it maybe

large parts of it is on nfs

v3, without locks, so it fails for some things :p

Ketas: but what is the underlying fa qemu is using?

it's my armv7 current vm where i build stuff for embedded

*fs

zfs

file

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

So it’s ufs running on top of zfs. :)

f451: using fbsd?

s/if/was/g

yes

yes, the loader has to kept up to date

s/to/to be

That’s not done automatically?

thread is here

-drive file=/root/files/qemus/yellowgreen/.img,format=raw,discard=unmap,detect-zeroes=unmap

that's what it's disk is

not, that's your duty

no, fbsd does not update loader automatically.

FreeBSD user is sysadmin, responsible for the maintentace of the OS

Ah. You’d think that would be a thing. I mean admin has to do all updates anyways right?

use sysutils/loaders-update

this attracts many hobbyists to FreeBSD

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.

i already asked if it could updated automatically

the loader

it's difficult too

there are always + and - sides on automation. altho, I haven't heard much down sides from automated illumos bootloader updates;)

like, where is the loader?

is it on efi part?

on which disk it is?

on how many disks is in on, etc

root disk(s) and efi + freebsd-boot (if present). its that simple.

but where are the root disks?

however, it needs versioning, so you wont downgrade it accidentally.

would that be foolproof to autoassume?

zpool status or see /etc/fstab

zpool layout is easy to parse.

yeah one could look if it had loader before

but i see so many failure point

s

(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)

but basically i could have wholly avoided the issue to not have root-ob-zfs

it's only zfs issue?

upgrading from sources is fastest method

loader is old?

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

and was it fixed0

?

considering stable is for devs

it's the only zfs issue i had - well it's the only one i mention here

sure it's a ooh crap moment

that loader isn't able to read a disk and now you have to boot external

ok found thread - it's here: lists.freebsd.org/archives/freebsd-arm/2023-October/003137.html

yee, its telling loud and clear, one important bit was not updated.

it nearly bite my ass too i think

many years ago, there was issue you had to update system firmware to be able to run next version of os.

on solaris?

how would you update firmware now if os won't run :)

yep, on some sparc, can not remember which...

you do not necessarily need os to update system firmware.

*your* os, that is.

anyway this auto loader update could fail too

who knows

if I remember correctly, this supermicro of mine was needing dos for it;)

sparc dos?

they made it?

i assume it was an x86

supermicro X10SAE (x86)

I think, i used freedos or something like-

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.

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 :)

wasn't aware of sysutils/loaders-update that must be a relatively new port

Oct last year

Do use `show-me` before you shoot yourself in the foot :D

back

:D

Actually with UEFI esp you can actually keep your old loader around for a case the new one may be bad.

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

*half

yes, except with some systems its really annoying to attempt to boot from other half;)

which is why many x86 admins insist on having those raid adapters;)

Mmm, hardware raid, sounded so fancy reading about those in computer magazines in the 1990s ..

small computer running its own os;)

wouldn't touch it with a stick

as long as we have zfs

raid cards make booting easier?

i thought they just corrupt your data

more easily

;)

the have to sell them somehow

recently someone was losing one of 8 hdd and in the end it was either disk issue or lsi issue but not fbsd

but card nicely did hide it up

or whatever it was

owner of a card was confused as card ran "direct" firmware

btw how would one move disks to different machine?

i mean virtually

i recall people sometimes use zfs via iscsi or perhaps ggate

tho at that scale, maybe it's good idea to run something on top instead

Never tried iSCSI, every time I think of it I end up usin plain old NFS

Haven't stumbled upon a usecase for it I guess

There's nvmf(4) too: freebsd.org/status/report-2023-04-2023-06/nvmf

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..?

Does anyone know if it's still possible to build a port that's all statically linked?

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?

Using -vv does show more info in the preparation stage, but nothing more about the error

Hi

There is problem here..

Pipelight needs xattr to run.. is it supported on freebsd?

oh, after more search found user_xattr is supported

but It scares me mounting my / using it, will break the system?

Retrofan: Take a look at rmextattr(8) maybe?

it supported but it just mounting the root partition scares me

using it

could I separate home away from it?

For now, I will try it on my testing partition

You can separate them, sure.

Might already be separated if you're using ZFS.

I will try

no zfs

I want to use zfs now

I really liked

it but the ram usage of it is high :(

You can limit it, if you'd like.

could it only use few MBs?

I suppose so. Likely wouldn't be prudent, though.

What is it using ram for? Usually it’s just arc isn’t it?

Afaik arc will dial down if the system calls for more app memory.

Somewhere read that a 8gb system will die using it..

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.

I am using my pc for many heavy stuff.. so it will continue work

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

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

s/13.x/14.x

Yep. I haven't had any problems in the last couple years, for sure.

yeah the UNIX philosophy..

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

Anyone know if any of the other *bsd's have leading spaces on wc output?

ZFS was vicious on i386

mzar: you said to me that your a freebsd desktop user

sure

So just curios what is your setup..

like X stuff

I am using FreeBSD for everything

:O

XFCE4 works OK

Then you are not a customize fan?

not at all

plain setup...

that's proven to work

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.

Everything just consumes so much RAM. The more RAM you can have (up to a point) the better everything operates.

sure, in the past we were running ZFS on i386 with 512MB of RAM, but this machine retired before FreeBSD 10.0-RELEASE IIRC

rwp: 1GB is barely enough for pkg nowadays, although i think that might be a bug

i had to bump a few 1GB VMs to 2GB just to run pkg upgrade without running out of memory

lol

Makes you wonder what pkg is REALLY doing.

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.

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.

yeah, i do that on my own hardware but this was a project that needed a bunch of small VMs in different locations

so trying to save money :-)

Trying to save money here too!

Storage is the biggest driver of expense. Storage is expensive to rent. RAM is cheaper.

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? termbin.com/2188

starting to suspect that upgrading to 15 from 14 via pkgbase just ruined the system

my /usr/src/sys/sys/vnode.h file matches the one here: cgit.freebsd.org/src/plain/sys/sys/vnode.h?h=stable/15

tm512: this looks like a bug in the header (if it's meant to be self contained) which you could raise on current@

1500063 is outdated

ALPHA1 is 1500064

mzar: I'm aware, but the pkgbase packages are out of date

OK

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

the drm-66-kmod binary package seems to have been built against 63 just fine though (see the Packages section) freshports.org/graphics/drm-66-kmod

is pkgbase built in poudriere ?

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

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

I've never actually used mailing lists for any project, and I don't want to end up subscribed to one

does seem like there is already a mention of the problem on the list, but there hasn't been any response mail-archive.freebsd.org/cgi/getmsg…tch=55791+0+current/freebsd-pkgbase

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

would the current mailing list really be the most appropriate for build failures on 15.0?

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

I guess all of this is what I get for not just installing Linux on this laptop though

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

14.3 has drm-61-kmod

5.15 and 6.1 both have issues that seriously hinder system usability. 6.6 is only available on 15 and 16

I'm wanting to try out the 6.6 drivers

upgrade then

I did, but 6.6 won't build

hence the build failures I pasted termbin.com/2188

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

bummer...

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

like if something about the compiler got messed up

from my experience drm-66-kmod builds fine in recent stable/15

tr a-z A-Z failed due locale

you need something more sophisticated

there's 0 cases where a-z needs locale

:/

locale causes your acme.sh to fail!!!

well, locale does not fail, programmers do;)

well tr could be free form text processing tool that supports all langs but

eh

tr '[:lower:]' '[:upper:]'

mzar: seems not unlikely that going from 14-STABLE to 15.0-PRERELEASE via pkgbase has left this install FUBAR

but I would expect pkg check to complain about checksum mismatches or missing files or the like

"echo abc | tr '[a-z]'" -> "Ac"

tsoome: yeah, that's what i patched into acme.sh

tm512: could be, perhaps some header files are missing or outdated

other patch uses check and then switches to lower <-> upper

tm512: can you see commit hash in uname ?

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

tsoome: what about tr -cd '[:print:]' < /dev/urandom | head -c 32 ? :)

what about sources ? do they match ?

also doesn't do what one honestly expects

the drm-66-kmod sources? I'll have to check that out a bit later, gotta go on some errands

you are expecing valid utf-8 sequences from /dev/urandom?:)

no i expected it to contain, well, printables

i have no idea what actually does

it

to get those, you need to grab byte stream, convert it to your charset (iconv) and then you you have something.

because multibyte chars have specific structure, you can not get that from random number generator.

yeah they are all "printables" i guess

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...

i think world is filled with horrors

i think tr was once also helpful to included superscript 2 in numbers too

because it's a number!!!

can't replicate it now

yeah this is wrong tool

once you go utf-8 you enter true hell

can't even trust eyes now :p

oоοօ

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...

is there a command we can run to purge all swap currently in use?

i wanna reset swap usage back to 0% without reboot

i see 'swapoff -a && swapon -a' in web search is that still the way?

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.

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?

ah it's fast

basically instant

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

im sorry you experienced that

hopefully the GPU hanging issue gets a quick resolution, but dunno how likely that is

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

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

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

kerneldove: That really depends on load and workload generally. Glad it was fast.

gtk ty

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.