This is intentional. But the script /etc/rc may not be working exactly as intended yet. rpe, tb and I are still iterating this, and also attempting to satisfy the unhibernate case which requires booting the original kernel.
The intent of the hash is so that a developer can build their own kernel from elsewhere. Upon the next boot, it will notice that that the hash is different. This means the developer is testing their own kernel, and does not want auto relinking to occur. However if the hash matches then /bsd is under system management, and can be relinked. Finally, if there is no hash file, this was an install or an upgrade, and it can go into this managed-mode where it auto relinks at boot. You can also make it relink on future boots by deleting the hash file. As you can tell we're trying to find a happy middle ground between automatic safety, and developers being in control of their own machines. There is also a bootblock change coming, to assist unhibernate. > After upgrading to the latest snapshot I noticed that the kernel is no > longer relinked on boot. The cause seems to be that the SHA256 checksum > doesn't match the kernel. > > # cat /usr/share/compile/GENERIC.MP/SHA256 > SHA256 (/bsd) = > bfcce01e68e62cc5d9666096206492be3f5c310e9711f2a14ac9c75e279585a1 > > # sha256 /bsd > SHA256 (/bsd) = > 10da3cee5c0bf44ce9182b2603be46b2adfc200222ca74d169691f79750bd05b > > # sysctl kern.version > kern.version=OpenBSD 6.1-current (GENERIC.MP) #13: Thu Jun 15 19:34:58 > MDT 2017 > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > Is this on purpose or an error on my side? > > Kind regards, > > > Martijn Rijkeboer > > >
