I've just run syspatch on a 6.5 box and obviously I've allocated the space
poorly but because of that, this happened:
drogo# syspatch
Get/Verify syspatch65-001_rip6cks... 100% |***********************| 196 KB
00:00
Installing patch 001_rip6cksum
Get/Verify syspatch65-002_srtp.tgz 100% |*************************| 4316 KB
00:00
Installing patch 002_srtp
Get/Verify syspatch65-003_mds.tgz 100% |**************************| 49488 KB
00:02
Installing patch 003_mds
/: write failed, file system is full
tar: Failed write to file usr/share/relink/kernel/GENERIC.MP/pmap.o: No space
left on devi
ce
/: write failed, file system is full
tar: Failed write to file usr/share/relink/kernel/GENERIC.MP/powernow-k8.o: No
space left
on device
tar: Failed write to file usr/share/relink/kernel/GENERIC.MP/ppp_tty.o: No
space left on d
evice
tar: Failed write to file usr/share/relink/kernel/GENERIC.MP/process_machdep.o:
No space l
eft on device
...
... Lots of this; doesn't need repeating.
...
tar: Unable to create usr/share/relink/kernel/GENERIC.MP/xen.o: No space left
on device
tar: Failed write to file var/syspatch/65-003_mds/003_mds.patch.sig: No space
left on devi
ce
Relinking to create unique kernel... done; reboot to load the new kernel
Errata can be reviewed under /var/syspatch
drogo# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/sd2a 254M 153M 88.3M 63% /
/dev/sd2d 3.4G 1.7G 1.6G 52% /usr
/dev/sd2e 254M 18.0M 223M 7% /var
/dev/sd3a 1.8T 326G 1.4T 19% /srv
/dev/vnd3a 19.7G 3.2G 15.5G 17% /var/www/htdocs/OpenBSD
drogo# ls -l /bsd*
-rwx------ 1 root wheel 15623498 Jun 6 18:57 /bsd
-rwx------ 1 root wheel 15629498 May 20 02:17 /bsd.booted
-rw------- 1 flak wheel 10224165 Apr 30 08:35 /bsd.rd
-rwx------ 1 root wheel 15527075 Apr 30 08:35 /bsd.sp
drogo# date
Thu Jun 6 18:58:23 UTC 2019
I'm not sure what this means it's stuffed into /bsd but I've kept it,
/bsd.booted and the relink directory and repaired and relinked manually. I'm
not attaching them to this because obviously they're too big but here's the
relink.log:
drogo# cat /srv/broken-20190606/kernel/GENERIC.MP/relink.log
(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0xcccccccc gapdummy.o
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
text data bss dec hex
12913621 546360 671744 14131725 d7a20d
mv newbsd newbsd.gdb
ctfstrip -S -o newbsd newbsd.gdb
rm -f bsd.gdb
mv -f newbsd bsd
umask 077 && cp bsd /nbsd && mv /nbsd /bsd && sha256 -h /var/db/kernel.SHA256
/bsd
Kernel has been relinked and is active on next reboot.
SHA256 (/bsd) = 40b52473bed49fca4f4d4218cd0d5062902d7f3398d3e833888b8494dc2f0b55
drogo# cat /srv/broken-20190606/kernel.SHA256
SHA256 (/bsd) = 40b52473bed49fca4f4d4218cd0d5062902d7f3398d3e833888b8494dc2f0b55
I didn't think to check what the return code from syspatch was but I suspect it
was zero.
In a little while I'll dig around in syspatch/relink to see if I can figure out
what's going on (I'm in the middle of something else now and system patching
was itself just a yak) but I wanted to post this in case anyone already
familiar with those two processes can jump straight to the problem.
Cheers,
Matthew
