mason: this is all happening when using the 15.0-RELEASE disc1 iso ?

mason: if you want to do a dist set install from media, use dvd1

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

simples

as booting should be

no random wiping of the nvram

missing efi entries

etc

nd no vulnerability in which the boot splash can be used to pwn the device :p

ivy: seems they might be trying a pkgbase install, where it does pull everything down over the interwebs

polarian: I seemed to have missed prior conversation

SponiX: sorry

I mean to reply to spekul

im half asleep, pulled an all nighter

SponiX: no, pkgbase is included on the media for both disc1 and dvd1. dist sets are only on dvd1

gonna zzz on train a min

also, they specifically mentioned trying to install dist sets

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

if dvd1 will solve their problems, that is nice

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

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)

pkg -vvv upgrade $thing

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?

oh sorry i misread. brain said pkg slow installing

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=

nimaje: Are you seeing any cpu or ram utilization at cap?

there was some discussion about this on the lists

so added that and rebuilt the jail

cpu utilization is pretty high, but no idea how it compares to previously; no cpu core stayed at 100% the entire time

hm, top says >90% system for cpu, should that be the case while compiling?

yes

very much so, yes

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

it's not too crazy

especially if you're also running the daily tasks at the same time

a good build system would have all your cores at 100% load fwiw

well, a very efficient build system. ports can't control that for obvious reasons

no, a good build system would have the cores given to it at 100% load

nimaje: building most of your workload should be in user

it being in system implies something is blocking the cores from getting useful work to do

hard drive I/O?

heavy parallelism in build systems is quite difficult to implement, and practically impossible if you have no control over the code you're compiling

ports and the source tree don't get stuck in system for me

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

nimaje: how old is the builder?

the vm was created about 2 years ago, the host is proxmox on an amd ryzen 7 5700G

i mean the poudriere jail instance - im presuming poudriere is what you're using

ah, I created that jail in march when I upgraded the vm to 14.4

ok - you may wish to make a src.conf for the jail with WITH_LLVM_LINK_STATIC_LIBRARIES= in its jailname-src.conf

then rebuild the jail

so build it from src instead of distribution sets?

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

yes. ive never built from dist sets

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

there may have been a change back to static sefault in main but I'm unsure if it was MFC'd

s/sefault/default/g

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

depends on whats changed/changing

the port will be changing

also if you're using eg ccache stuff might not already be cached

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

(personal trauma)

and I'm pretty sure I have seen that slowdown with pure python ports too

aly clues in /var/log/messages or console.log ?

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

on a -current builder here, librewolf took 00:32:47 this is on a dual xenon/320GB

the last message from /var/log/messages is from before the bulk even started and that bulk was fine for the first hours

also has PARALLEL_JOBS=10 ALLOW_MAKE_JOBS=yes MAKE_JOBS_NUMBER=2 hw.ncpu=20

nimaje: it's going to be difficult to tell there are many factors

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

ive had libreoffice take 28:19

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

hum...

id be looking at first remaking the builder then checking the hardware

is poudriere builder on a hd or ssd and how full is it

ssd and ~200/250GB used

is it ufs or zfs

zfs

]id say its too full

zfs needs a ton of slack

4/5ths is too much

run a scrub and garbage collect/move stuff off there you don't need

zfs issue would neatly account for the symptoms you're reporting

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

nimaje: Might be worth makeing sure you don't have any old snaps or be's that you don't need any longer.

be's do stack and consume space rapidly if you keep em.

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

i had a 5.6GB obj tar and zstd -9 and it's like under a gig

stuff like /var/log i turn on compression to 19 and for log rotation turn off compression to bz2

any filesystem thats almost all txtfiles i turn up compression to insane

obj is very compressible but for a functioning obj i dunno about the performance impact of turning compression on.

but obj gets bigger and bigger esp if you poudriere build a lot of builders

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.

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.

Good call about if I don't want the network though.

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

packages and logs

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.

Are you all aware of this? I literally just heard about it: aisle.com/blog/aisle-discovers-cve-…ote-command-execution-vulnerability

The article includes the published securiy advisory

Corrected in p7 and there's already a p8. Did not know about that one though, no

CrtxReavr: hadn't seen that before, thanks for the heads up! very few remote root exploits manage such a wide attack surface

most commonly sshd is targeted, but dhcp client is even better

I'm one step of not getting my fiber card working under freebsd away from being vulnerable

screen -ls

bah

:q

sorry

kldload hax.ko

oops

has anyone upgraded to 15.1-BETA on a pkgbase system? just curious if it was an uneventful experience or to-be-avoided.

pkg search chatterino and pkg search chatty give no output what happened yo this ports?

aGaTHoS: freebsd/freebsd-ports 60c4279

ok