Date: Fri, 21 Nov 2025 18:35:48 -0800 From: Mark Millard <marklmi@yahoo.com> To: Lexi Winter <ivy@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: changing from pkgbase to regularbase [ evidence gathering for problems when using a pkgbase system ] Message-ID: <6C4D4B62-9B81-4106-9581-54AD6A441CF6@yahoo.com> References: <6C4D4B62-9B81-4106-9581-54AD6A441CF6.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Lexi Winter <ivy_at_freebsd.org> wrote on Date: Sat, 22 Nov 2025 01:35:41 UTC : > void wrote in <71e4b46c-8d69-451d-92ca-79316ffc4b63@app.fastmail.com>: > > On Sat, 22 Nov 2025, at 00:39, Lexi Winter wrote: > > > the point of this warning was to prevent people from running "make > > > installworld" on a pkgbase system. apparently, the warning was not > > > sufficient... > > > > Sorry, I'm not with you. Sufficient for what? I mean it was > > a sufficient warning, I just had to heed it then do further > > things to properly depkgbasify. > > what the warning says is: > > ERROR: This target should not be used on a system installed from > packages. > > nonetheless, you ran make installworld on a system installed from > packages. so, clearly the warning was not sufficient to prevent you > from doing that. > > we are discussing ways to improve this internally, probably by making > the warning more difficult to override... An FYI: I've been doing some of the testing for the jemalloc 5.3.0/kernel error notification issues seen on armv7 and i386 on main 16. (stable/15 and releng/15.0 do not have the asserts enabled to report internal checks.) My context is main 16 for this. But I've been using an official-distribution pkgbase'd environment from long before this activity started. I created an alternate kernel, installed under a distinct name for some of the testing. I did so from a variant of the /usr/src/sys/ for the pkgbase system --not replacing the official kernel(s). I did use installkernel for this, with INSTKERNNAME= in use with DESTDIR=/ . I also touched the c++ compiler (c++ and clang) to allow it to generate core dumps for SIGABRT as the asserts are not failing for libprivateclang.so.19 or libprivatellvm.so.19 problems but libc's jemalloc and/or kernel problems. But I did not use installworld at all. Just selective copies from the built materials. I did use buildworld. I have *.orig files for what I've updated --in order to be able to put back the normal files. Gathering evidence from a pkgbase system for problems that occur is a bit odd for sure. Side Note: The actual activity that is know to be able to produce the failed internal checks is: llvm/clang build activity during buildworld . In some contexts with memory pressure involved, it has been seen on pure armv7, armv7 chroot on aarch64, and i386 chroot on amd64. (No one has reported having a pure i386 test environment.) The error report is indicating that page(s) that were allocated that should have been zero are, at least in part, not zero. My core dumps for an armv7 chroot on aarch64 show the jemalloc 0x5a fill pattern in the non-zero areas. That pattern is for deallocated memory. Michal Meloun's information indicates other, more general types of values are possible. === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6C4D4B62-9B81-4106-9581-54AD6A441CF6>