In case this problem is of any concern to anyone else and not just myself,
the following is the minimal patch that I could come up with that preserves
the idempotency of /usr/libexec/reorder_kernel and thus does not create any
unnecessary corner cases that need to be taken into account separately:
It's important to note that the SHA256 hash checked against /bsd stored in
/var/db each time reorder_kernel is called has no bearing on the integrity
or consistency of the files present at compile-time for the next reordering
in /usr/share/relink. If a signed SHA256.sig file (or two, GENERIC.sig
I compressed the GENERIC link kit with tar czf and it becomes 114MB, all
other things being equal to what is done now. That becomes significant for
users with many instances or embedded devices. There are trade-offs
involved, so to speak.
On Wed, May 27, 2020, 21:30 Theo de Raadt wrote:
>
Connor Schech wrote:
> I tried sending this via sendbug but my host was invalid. this is a
> 'system' problem.
>
> When installing OpenBSD 6.7 amd64 and selecting both bsd.mp and bsd in the
> install sets, indicating that both are desired, on a single core machine or
> VM only bsd is reordered
Hi,
I tried sending this via sendbug but my host was invalid. this is a
'system' problem.
When installing OpenBSD 6.7 amd64 and selecting both bsd.mp and bsd in the
install sets, indicating that both are desired, on a single core machine or
VM only bsd is reordered and bsd.mp is discarded; if
