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

Reply via email to