while pkg update -> pkg: truncated reply for signature_fingerprintsoutput, wanted 0 bytes

who manages outreach for freebsd

is it the foundation?

I am at a conf right now, and I am currently doing outreach for XMPP

polarian: I think the foundation do a lot, yes

Gedge: I wonder who I would need to speak to

mainly having a supply of stickers to distribute would be cool

freebsdfoundation.org/about-us/contact-us might help

so much cool stuff in the status report

blow the daemon whistle polarian you will summon beastie

good morning

I've got a pkg problem. I created /usr/local/etc/repos/*.conf files for base, kmods and ports. (I'm on 15.0-RELEASE, and I set it up for pkg+https://pkg.freebsd.org/${ABI}/base_release_0 for base, pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest_0 for kmods, and pkg+https://pkg.FreeBSD.org/${ABI}/latest for ports.. but I am getting errors when I run pkg update like pkg: No trusted public keys found and

pkg: Repository FreeBSD-base cannot be opened. 'pkg update' required

how do I fix this?

I installed 15.0 using the pkgbase setup (not freebsd-update)

the handbook's instructions for this look rather outdated

pertho, I hear release notes are more updated.

* more up-to-date .

^ been told so after failing with upgrading by the Handbook.

^ along with the advice to train an LLM upon the documenation :-)

ah.. I think I ran into this: freebsd/pkg #2653#issuecomment-4315260556

should FreeBSD-base repo be enabled?

seems to be disabled in /etc/pkg/FreeBSD.conf

it's correct to override that in /usr/local/etc/repos/?

weird.. I tried pkg install -f pkg and it downgraded from 2.7.4 to 2.6.2

I guess pkg.freebsd.org is bollocksed up somehow

hmm 15.0-p6 isn't out yet? I saw some errata

it is

I guess maybe until this pkg issue is fixed, no upgrade to -p6

which repo gets "FreeBSD-kernel-generic"? Is it actually in ports?

it's in FreeBSD-base, but that repository is disabled.. so how does FreeBSD get its kernel updates?

I enabled it and got the -p6 update kernel.. but in every example I can find, people have this pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/base_release_0 repo disabled in their systems. This is mightily confusing. Is it meant to be enabled or not?

even Dan Langille on his blog post on 15.0 has it disabled: dan.langille.org/2026/02/09/freebsd…-upgrade-installing-my-own-packages

guessing disable if using freebsd-update, enable if using pkgbase

pertho: if you're using pkgbase, FreeBSD-base will already be enabled in /usr/local/etc/pkg/repos. if you aren't, DO NOT enable it, use freebsd-update(8) to update the system

scan: scrub in progress since Sat Apr 25 10:47:08 2026

2.87T / 51.0T scanned at 43.8G/s, 0B / 51.0T issued

blah

there is no use case for having more than 128GB of storage :^)

like ram? 640K is enough

disagree

freebsd will not boot in under 96m

hm, so I can't port freebsd to my wii :(

let's say, as a hypothetical, you were running 13.5, applied quarterly upgrades, and it went sideways because kde is hosed in packages. now you're on a boot environment created before the upgrades. is it safe to delete the "default" boot environment? it seems like it is, but that could be a big mistake i wouldn't want to make.

chriswells0: there's nothing special about the "default" environment

just make sure the active one is the one you want

thanks.

chriswells0, I had a bad upgrade and needed to abandon it once. I booted a Boot Environment. Then eventually deleted the "default" BE and then renamed / promoted the working one to replace "default" with a different one. And my system continues on. The (old) king is dead, long live the (new) king!

These sound like zfs games that I can't play with my ufs system

Yes. So sad.

Reviewing my notes... I booted to a working previous Boot Environment and from there the commands are "bectl destroy default", then "bectl create default" which creates default using the currently booted BE, then "bectl activate default", then "shutdown -r now" to reboot to it.

there's no reason UFS couldn't support boot environments, someone just needs to implement it

Solaris supported BEs with UFS long before ZFS landed there

It's definitely not as simple and straight forward.

right, on Solaris you usually did it by breaking the root mirror, which gave you an instant clone of the running system

that should not be too difficult with GEOM

rwp: thanks. i'm on the fence between renaming this one to default at some point vs using freebsd-14 instead (after the upgrade).

so i may rename to freebsd-13, create freebsd-14, activate that, reboot, and upgrade.

Is it normal that "pkg+https://pkg.FreeBSD.org/${ABI}/latest" is missing packages?

yes, sometimes packages just fail to build and vanish from the repository when the build is published, since there's no manual checking or any kind of automated QA

this is probably less likely if you use quarterly rather than latest

Ok, got it. Thanks.

ibs, A good source of package status information is freshports.org which reports build status. Then often waiting until the build gets fixed and installing the fixed version. Or setting up poudriere local build.

rwp: Ah, ok. Yep..

This is one of those problems that we wish "the powers that be" would have a make-before-break package repository system to avoid the times when the builds are borken. But the problem mostly only affects new installations.

Because an existing installation with everything already installed doesn't notice the problem that the pkg repository is missing something that we already have. It's only on new install that we want to install something and it is not available that we notice and suffer.

it's worth adding "and when you upgrade on a new quarterly branch."

I normally use quarterly and I don't even notice when something failed to build and is not in the repository on an upgrade because I already have it installed. (shrug)

i don't normally have issues either, but plasma is broken on 13.x right now. when pkg said it would remove some of them, i thought it was clear up on the next resolver pass. i was wrong.

would* clear up

Oh sigh. Sorry! That's the problem with heavy Desktop Environments that depend upon everything else in the known universe. Something you have never heard of before is broken and preventing you from running it.

so, i asked claude about using -o to delete the default be and it gave me a back and forth about promoting the active one first. am i in a sane place right now and should i use -o to delete default? pastebin.com/raw/bxYeJiYh

There is something to be said for those of us who eschew those and simply run X Windows with a standard window manager. Just avoid the problems! Not saying you should go all of the way to running twm or anything. But i3 is a nice tiling window manager. And there are many other window managers that are really nice too.

(and do i need to promote first? now it says i already did, which i didn't, but maybe freebsd-update for the last patch did?)

I don't understand the -o part of your question.

I already referenced the commands that I have run to discard a failed upgraded default boot environment and reset to a previous one. No -o in the process as far as I know.

it started as a simple "should i use bectl destroy -o for the default be?" then there's a concern about it deleting the snapshot that the active be is based on.

i normally use -o any time i destroy a be. that's why i asked.

Hmm... I didn't worry so much about that. But it is only a snapshot. That can always be deleted later. I imagine it is safer to leave it. As a just in case you later need to reach into it for some configuration file or something.

This is from my notes of my previous activity: paste.debian.net/plainh/5ed92e23

This is one of those times when being able to use virtual machines to test things out in a testing environment is useful. Can play around on the VM and get comfortable with doing rather deep stuff on a disposable system. Then doing it on your important system after becoming comfortable doing it.

But I suggest leaving the snapshot initially and recovering your working system first. Then after you are back going okay again then you can "zfs list -t snap" and do any disk space cleanup you wish after you are sure you won't be returning to it.