01:36:54 while pkg update -> pkg: truncated reply for signature_fingerprintsoutput, wanted 0 bytes 08:46:29 https://www.tomshardware.com/tech-industry/cyber-security/iran-claims-us-exploited-networking-equipment-backdoors-during-strikes 09:33:01 who manages outreach for freebsd 09:33:05 is it the foundation? 09:33:23 I am at a conf right now, and I am currently doing outreach for XMPP 09:33:40 polarian: I think the foundation do a lot, yes 09:34:30 Gedge: I wonder who I would need to speak to 09:34:53 mainly having a supply of stickers to distribute would be cool 09:36:19 https://freebsdfoundation.org/about-us/contact-us/ might help 10:07:05 so much cool stuff in the status report 10:08:09 blow the daemon whistle polarian you will summon beastie 10:08:38 good morning 10:58:11 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 10:58:17 pkg: Repository FreeBSD-base cannot be opened. 'pkg update' required 10:58:20 how do I fix this? 10:58:42 I installed 15.0 using the pkgbase setup (not freebsd-update) 11:07:51 the handbook's instructions for this look rather outdated 11:10:53 pertho, I hear release notes are more updated. 11:11:05 * more up-to-date . 11:11:33 ^ been told so after failing with upgrading by the Handbook. 11:12:01 ^ along with the advice to train an LLM upon the documenation :-) 11:14:10 ah.. I think I ran into this: https://github.com/freebsd/pkg/issues/2653#issuecomment-4315260556 11:16:12 should FreeBSD-base repo be enabled? 11:16:22 seems to be disabled in /etc/pkg/FreeBSD.conf 11:16:48 it's correct to override that in /usr/local/etc/repos/? 11:22:43 weird.. I tried pkg install -f pkg and it downgraded from 2.7.4 to 2.6.2 11:23:01 I guess pkg.freebsd.org is bollocksed up somehow 11:34:16 hmm 15.0-p6 isn't out yet? I saw some errata 11:42:26 it is 11:44:46 I guess maybe until this pkg issue is fixed, no upgrade to -p6 11:47:58 which repo gets "FreeBSD-kernel-generic"? Is it actually in ports? 12:01:21 it's in FreeBSD-base, but that repository is disabled.. so how does FreeBSD get its kernel updates? 12:09:32 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? 12:09:54 even Dan Langille on his blog post on 15.0 has it disabled: https://dan.langille.org/2026/02/09/freebsd-15-0-after-upgrade-installing-my-own-packages/ 12:11:07 guessing disable if using freebsd-update, enable if using pkgbase 15:26:00 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 15:51:35 scan: scrub in progress since Sat Apr 25 10:47:08 2026 15:51:37 2.87T / 51.0T scanned at 43.8G/s, 0B / 51.0T issued 15:51:39 blah 16:18:35 there is no use case for having more than 128GB of storage :^) 16:42:17 like ram? 640K is enough 17:38:15 disagree 17:38:26 freebsd will not boot in under 96m 17:46:20 hm, so I can't port freebsd to my wii :( 19:06:45 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. 19:11:25 chriswells0: there's nothing special about the "default" environment 19:11:45 just make sure the active one is the one you want 19:13:59 thanks. 19:58:19 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! 19:59:50 These sound like zfs games that I can't play with my ufs system 20:00:37 Yes. So sad. 20:05:15 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. 20:05:20 there's no reason UFS couldn't support boot environments, someone just needs to implement it 20:05:27 Solaris supported BEs with UFS long before ZFS landed there 20:05:47 https://vermaden.wordpress.com/2021/04/02/ufs-boot-environments/ 20:06:12 It's definitely not as simple and straight forward. 20:07:46 right, on Solaris you usually did it by breaking the root mirror, which gave you an instant clone of the running system 20:07:52 that should not be too difficult with GEOM 20:36:38 rwp: thanks. i'm on the fence between renaming this one to default at some point vs using freebsd-14 instead (after the upgrade). 20:39:07 so i may rename to freebsd-13, create freebsd-14, activate that, reboot, and upgrade. 21:13:09 Is it normal that "pkg+https://pkg.FreeBSD.org/${ABI}/latest" is missing packages? 21:14:10 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 21:14:55 this is probably less likely if you use quarterly rather than latest 21:26:13 Ok, got it. Thanks. 21:27:31 ibs, A good source of package status information is https://www.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. 21:31:43 rwp: Ah, ok. Yep.. 21:47:56 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. 21:48:03 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. 21:53:58 it's worth adding "and when you upgrade on a new quarterly branch." 22:03:32 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) 22:05:02 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. 22:05:16 would* clear up 22:06:15 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. 22:08:28 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? https://pastebin.com/raw/bxYeJiYh 22:08:59 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. 22:09:07 (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?) 22:10:58 I don't understand the -o part of your question. 22:12:10 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. 22:12:17 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. 22:12:46 i normally use -o any time i destroy a be. that's why i asked. 22:14:11 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. 22:15:55 This is from my notes of my previous activity: https://paste.debian.net/plainh/5ed92e23 22:18:52 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. 22:20:21 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.