On a system which was installed several years ago, back when the automatic disklabel gave 2 GB to /usr, that filesystem is filling up to the point sysupgrade failed. sysclean helped me get enough space to upgrade, but in searching for other things to clean up, I discovered a large (225 MB) newbsd.gdb file in the kernel relink directory.
The Makefile in said directory removes bsd.gdb before renaming newbsd to bsd. I think it should be removing newbsd.gdb instead, like so: ==== --- /usr/share/relink/kernel/GENERIC.MP/Makefile~ Sun Apr 13 09:19:41 2025 +++ /usr/share/relink/kernel/GENERIC.MP/Makefile Wed Jun 11 12:51:38 2025 @@ -2434,7 +2434,7 @@ ${SYSTEM_LD_HEAD} ${SYSTEM_LD} swapgeneric.o ${SYSTEM_LD_TAIL} - rm -f bsd.gdb + rm -f newbsd.gdb mv -f newbsd bsd update-link: ==== I believe that is what was intended here? There doesn't appear to be a bsd.gdb file created by the relink: ==== ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS} text data bss dec hex 26850486 490416 1351680 28692582 1b5d066 mv newbsd newbsd.gdb ctfstrip -S -o newbsd newbsd.gdb rm -f bsd.gdb <== should be newbsd.gdb mv -f newbsd bsd ==== This takes my system from /usr being 91% full down to 79%. Obviously the free space is still needed temporarily during the relink. I can't find the CVS/git source of this Makefile -- its header appears to match sys/arch/amd64/conf/Makefile.amd64, but that file doesn't contain the newbsd rule. It's part of the /usr/share/relink/kernel.tgz tarball in the base set, but what builds that tarball? Thanks, Andrew