On Wed, Jul 15, 2026 at 09:30:53PM +0000, Lloyd wrote: > Hello misc@, I'm sharing a situation I ran into recently. > > I had a machine where running syspatch was not displaying the most > recent July patchsets and was erroneously reporting fully up to date. > > I knew this to be false so I started to dig deeper. > > After some analysis it was found the patches were being downloaded from > the mirror but were quietly being discarded. > > This particular box had an issue of broken kernel relink; somehow the > *.o files were deleted. I'm not sure the circumstances but it was likely > due to a contribution of my carelessness while troubleshooting. It did > not seem like a big deal, relink was being skipped so I went on my way. > > Patches that impact the kernel are supplied as *.o files via syspatch. > > The ls_missing() function of syspatch will audit the patchsets and if > any files are missing on the running system it will ignore and skip it. > > syspatch assumes that the "sets" were opted out on that system during > installation (even if it's base) so assumes the patch doesn't apply. > > Per the comments in syspatch(8): > > > # no earlier version of _all_ files contained in the tgz > > # exists on the system, it means a missing set: skip it > > Well, it *could* mean a missing set. > > This seems like a hole in the syspatch logic. I will be the first to > acknowledge the fix is to "fix the broken system" which is what I > was forced to do, but I see an opportunity here. > > OpenBSD could benefit from something similar to Microsoft's sfc.exe > tool, which does an integrity check on the base system files. If files > are missing or don't match the hash, the files are restored from a known > good copy (e.g. the sets or syspatch archive). This would save you from > re-running sysupgrade on the entire system. > > Some of this logic likely already exists in security(8), sysupgrade(8), > and friends. IMO it could be adapted to perform a system audit function.
Hi. Well, syspatch is not wrong per se in this situation. A Kernel patch is provided with updated .o files. If you deleted the existing ones, then patching would break since reoder_kernel would fail (since it would only have the new .o files without anything else). The comment in syspatch about a missing set might not be perfectly exact but syspatch is right not to try and apply this. You can't run reorder_kernel with most of /usr/share/relink/kernel/... being empy. -- Antoine
