Re: Kernel relinking not working after upgrade to latest snaphot
Thanks for the detailed update, very helpful. Regards, Leighton On Fri, Jun 16, 2017 at 04:28:59PM +0200, Martijn Rijkeboer wrote: > On 06/16/17 16:11, Theo de Raadt wrote: > > 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. > > OK, good to know. > > > >> 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 > >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > >> > >> > >> Is this on purpose or an error on my side? > >> > >> Kind regards, > >> > >> > >> Martijn Rijkeboer >
Re: Kernel relinking not working after upgrade to latest snaphot
On 06/16/17 16:11, Theo de Raadt wrote: > 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. OK, good to know. >> 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 >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> >> >> Is this on purpose or an error on my side? >> >> Kind regards, >> >> >> Martijn Rijkeboer
Re: Kernel relinking not working after upgrade to latest snaphot
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 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > Is this on purpose or an error on my side? > > Kind regards, > > > Martijn Rijkeboer > > >
Kernel relinking not working after upgrade to latest snaphot
Hi, 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 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Is this on purpose or an error on my side? Kind regards, Martijn Rijkeboer
