04:55:01 mason: this is all happening when using the 15.0-RELEASE disc1 iso ? 05:02:27 mason: if you want to do a dist set install from media, use dvd1 05:06:03 SponiX: I dont usually use efi because its a pain in the arse, my devices usually run coreboot and I dont use uboot as a payload, I use seabios to boot the loader, and thats it 05:06:06 simples 05:06:10 as booting should be 05:06:20 no random wiping of the nvram 05:06:20 missing efi entries 05:06:32 etc 05:06:47 nd no vulnerability in which the boot splash can be used to pwn the device :p 05:11:24 ivy: seems they might be trying a pkgbase install, where it does pull everything down over the interwebs 05:11:40 polarian: I seemed to have missed prior conversation 05:12:20 SponiX: sorry 05:12:26 I mean to reply to spekul 05:12:44 im half asleep, pulled an all nighter 05:12:47 SponiX: no, pkgbase is included on the media for both disc1 and dvd1. dist sets are only on dvd1 05:12:49 gonna zzz on train a min 05:13:06 also, they specifically mentioned trying to install dist sets 05:13:38 ivy: okay, I will take your word for that. I haven't launched any FreeBSD install media in a long time, and when I did it was CURRENT branch 05:14:06 if dvd1 will solve their problems, that is nice 07:03:58 hm, since upgrading my package build vm to 14.4, I have the problem that sometimes everything goes extremly slow and stays that way, additionally when stuff goes slow, I see failures in -depend phases because pkg has some bad file descriptor, which someone said would be fixed with pkg 2.7, it got rarer with 2.7, with 2.6.2 it basically happened instantly, but I have no idea how to debug this, so 07:04:00 any ideas how to debug this? (sadly freebsd 14.4 and pkg 2.6.2 was at the same time for that vm, so no idea how connected it is with which of them) 12:34:58 pkg -vvv upgrade $thing 12:42:15 f451: was that for me? how would that help figuring out why libreoffice is currently already 4h in phase build while it previously needed under 1h from start to finish? 12:44:04 oh sorry i misread. brain said pkg slow installing 12:46:05 oh not sure it applies to you but there have been llvm changes, now in src.conf or poudrierejail-src.conf i have WITH_LLVM_LINK_STATIC_LIBRARIES= 12:46:08 nimaje: Are you seeing any cpu or ram utilization at cap? 12:46:26 there was some discussion about this on the lists 12:46:57 so added that and rebuilt the jail 12:53:51 cpu utilization is pretty high, but no idea how it compares to previously; no cpu core stayed at 100% the entire time 12:58:51 hm, top says >90% system for cpu, should that be the case while compiling? 13:01:21 yes 13:01:36 very much so, yes 13:13:47 hm, but a load of >7 while one port is building with 3 jobs, another is doing pkg add and the third is running gtk-update-icon-cache seems strange to me 13:15:46 it's not too crazy 13:15:54 especially if you're also running the daily tasks at the same time 13:18:43 a good build system would have all your cores at 100% load fwiw 13:18:59 well, a very efficient build system. ports can't control that for obvious reasons 13:19:19 no, a good build system would have the cores given to it at 100% load 13:20:09 <[tj]> nimaje: building most of your workload should be in user 13:20:21 <[tj]> it being in system implies something is blocking the cores from getting useful work to do 13:20:32 hard drive I/O? 13:21:30 heavy parallelism in build systems is quite difficult to implement, and practically impossible if you have no control over the code you're compiling 13:22:09 <[tj]> ports and the source tree don't get stuck in system for me 13:37:43 builds shouldn't spend much time in system either way. I've seen it happen though, usually it meant the build has somehow got itself deadlocked doing something stupid 13:37:45 nimaje: how old is the builder? 13:58:33 the vm was created about 2 years ago, the host is proxmox on an amd ryzen 7 5700G 14:01:43 i mean the poudriere jail instance - im presuming poudriere is what you're using 14:03:15 ah, I created that jail in march when I upgraded the vm to 14.4 14:04:47 ok - you may wish to make a src.conf for the jail with WITH_LLVM_LINK_STATIC_LIBRARIES= in its jailname-src.conf 14:05:07 then rebuild the jail 14:06:22 so build it from src instead of distribution sets? 14:06:47 there were complaints on the lists of long build times and it was linked to making something in LLVM dynamic. I don't know exactly what. But it's in the last few months 14:07:19 yes. ive never built from dist sets 14:07:53 for all i know they may have fixed it. But I don't know. don't make any changes on the basis of what i say 14:08:43 there may have been a change back to static sefault in main but I'm unsure if it was MFC'd 14:08:57 s/sefault/default/g 14:10:12 but why would it sometimes be fine, but sometimes just switch to be extremly slow? While that variable maybe helps to make builds faster, it doesn't sound like it would help with my problem 14:12:33 depends on whats changed/changing 14:13:01 the port will be changing 14:13:34 also if you're using eg ccache stuff might not already be cached 14:13:57 I hope you solve your problem and get away without having to dig too deeply. build systems and their problems can get "there be dragons" level quickly 14:14:08 (personal trauma) 14:14:17 and I'm pretty sure I have seen that slowdown with pure python ports too 14:16:45 aly clues in /var/log/messages or console.log ? 14:16:47 and one time a bulk was fine, but the one shortly after it, with few changes was slow from the start, so about everything should have been in ccache already 14:19:39 on a -current builder here, librewolf took 00:32:47 this is on a dual xenon/320GB 14:19:48 the last message from /var/log/messages is from before the bulk even started and that bulk was fine for the first hours 14:21:33 also has PARALLEL_JOBS=10 ALLOW_MAKE_JOBS=yes MAKE_JOBS_NUMBER=2 hw.ncpu=20 14:22:09 nimaje: it's going to be difficult to tell there are many factors 14:24:07 ive known some huge things like ungoogled-chromium can take varying times to build but ive put that down usually to changes in the port 14:26:38 ive had libreoffice take 28:19 14:26:39 f451: the problem is that it is not just some things and not just huge things, it is everything, like ports normally taking 1-2 min taking over 20 min 14:27:29 hum... 14:28:10 id be looking at first remaking the builder then checking the hardware 14:28:37 is poudriere builder on a hd or ssd and how full is it 14:29:39 ssd and ~200/250GB used 14:29:49 is it ufs or zfs 14:29:59 zfs 14:30:08 ]id say its too full 14:30:28 zfs needs a ton of slack 14:30:50 4/5ths is too much 14:31:32 run a scrub and garbage collect/move stuff off there you don't need 14:34:07 zfs issue would neatly account for the symptoms you're reporting 14:37:23 https://forums.truenas.com/t/is-the-80-problem-in-zfs-still-relevant/26490 14:59:13 hm, a bit of a problem that each upgrade about doubles the needed space until I upgraded all my machines are upgraded and I can get rid of the old package repo and stuff 15:14:20 nimaje: Might be worth makeing sure you don't have any old snaps or be's that you don't need any longer. 15:14:50 be's do stack and consume space rapidly if you keep em. 15:39:12 for stuff like var/log set zstd compression to 19, maybe clear out /usr/obj* or at least tar it up and compress it, clean out /usr/ports/distfiles that sort of thing 15:39:58 i had a 5.6GB obj tar and zstd -9 and it's like under a gig 15:41:06 stuff like /var/log i turn on compression to 19 and for log rotation turn off compression to bz2 15:42:47 any filesystem thats almost all txtfiles i turn up compression to insane 15:44:16 obj is very compressible but for a functioning obj i dunno about the performance impact of turning compression on. 15:48:37 but obj gets bigger and bigger esp if you poudriere build a lot of builders 15:52:30 SponiX: Yes. ivy: It worked if I let it launch the installer right off. There's some logic that's gone wrong if I invoke it as bsdinstall from the shell. 15:53:22 Well. I should qualify. It was able to get them from the network if I let the installer run right off, as it tried to (and succeeded to) set up the network. 15:53:32 Good call about if I don't want the network though. 15:54:41 yeah, I do clean up old BEs, I don't think there are any other snapshots on that system, except for those @clean snapshots poudriere creates to clone its builders from and there is no /usr/obj here, what needs space is ccache (maybe I should set a lower limit there), distfiles and poudriere (for some reason it didn't create datasets for data/, only for jails and ports, so I don't see how much is 15:54:43 packages and logs 15:55:43 ivy: In this case, FWIW, I'm forcing the ISO up through a flaky IPMI and it's nicer to have a small image to push over the network, while the sets can be hoovered up nicely from the actual host being installed. 17:28:54 Are you all aware of this? I literally just heard about it: https://aisle.com/blog/aisle-discovers-cve-2026-42511-a-21-year-old-freebsd-remote-command-execution-vulnerability 17:31:28 The article includes the published securiy advisory 17:38:47 Corrected in p7 and there's already a p8. Did not know about that one though, no 17:42:19 * CrtxReavr just did the quick & dirty patch & restarted dhclient. 17:47:27 CrtxReavr: hadn't seen that before, thanks for the heads up! very few remote root exploits manage such a wide attack surface 17:49:37 most commonly sshd is targeted, but dhcp client is even better 17:51:23 I'm one step of not getting my fiber card working under freebsd away from being vulnerable 18:01:28 screen -ls 18:01:30 bah 18:05:09 :q 18:05:20 sorry 18:07:03 kldload hax.ko 18:07:05 oops 20:41:27 has anyone upgraded to 15.1-BETA on a pkgbase system? just curious if it was an uneventful experience or to-be-avoided. 21:16:09 pkg search chatterino and pkg search chatty give no output what happened yo this ports? 21:23:43 aGaTHoS: https://github.com/freebsd/freebsd-ports/commit/60c427972bf141b14190f8b7ed9ad26cc4a08976 21:35:08 ok