If you replace the kernel by hand, that is precisely what happens. It assumes you are going to be developing kernels, and therefore won't touch it. It reports that.
If you manually hash the kernel, upon your next boot it will start replacing it, because the relink process believes it is in control of kernel replacement > I just ran into an issue that I was working through on the #openbsd IRC > channel that I figure I'd report with a work around. > > /usr/libexec/reorder_kernel reports that it's unable to relink my kernel due > to a SHA mismatch: > -- > Oct 9 09:36:52 stump reorder_kernel: kernel relinking failed; see > /usr/share/compile/GENERIC.MP/relink.log > -- > > Where '/usr/share/compile/GENERIC.MP/relink.log' contains: > -- > (SHA256) /bsd: FAILED > -- > > The fix was easy enough: > -- > doas sha256 -h /var/db/kernel.SHA256 /bsd > -- > > I'm not sure where the original SHA256 came from, but it didn't end up > matching any of the kernels distributed with 6.2 stable. > > With the above command, the reorder_kernel script is all happy now. > > Thanks! >
