Connor Schech <[email protected]> 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 and bsd.mp is discarded; if switching to SMP on > the VM or migrating to another SMP host, there is no way for KARL to > recover and relink the GENERIC.MP objects because it only reordered objects > for GENERIC the first time, even after the SHA256 hash for /bsd is updated.
The installed is quite clear: it picks one, or the other. > This single path of execution of KARL has bothered me for several releases, > since it ignores the fact there are two types of kernels and also lots of > usage scenarios that need both or handle reordering both types properly. The machine you install on remains the same. If you change the machine, why don't you reinstall. Seriously, why is this our problem? > Since reordering the kernel is not optional in the install nor controllable > after the install with rcctl like library_aslr, reordering both the sp and > mp kernels if both install sets are selected instead of removing one makes > sense, because all users then have access to both types of > properly-reordered official kernels from the default install, and can also > choose one or the other install set to begin with if both are not needed. > Reordering a kernel should work at any point in time when it has been > checkpointed using its current SHA256 hash, regardless of whether the > system was initially booted in MP mode or SP mode. On amd64, the GENERIC.MP link-kit is 347M. Upon install, we delete the other kernel link kit to save space. I think the GENERIC link kit is around 300MB. If we keep an additional 300MB of storage on the disk, shall we direct all the complaints to you? What do you think the response will be?
