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
