Re: Finish the link-kit job

2017-06-24 Thread Klemens Nanni
=== RCS file: /cvs/src/distrib/miniroot/install.sub,v retrieving revision 1.1014 diff -u -p -u -r1.1014 install.sub --- distrib/miniroot/install.sub3 Jun 2017 22:27:41 - 1.1014 +++ distrib/miniroot/install.sub

Re: Finish the link-kit job

2017-06-23 Thread Stuart Henderson
On 2017/06/23 16:19, Theo Buehler wrote: > I understood 'manual upgrades' to be 'upgrading without the install > kernel', as described in upgradeXX.html. The link kit is in baseXX.tgz > and will be extracted with it. So you will end up runnig what you > intended to run. It can't work at the

Re: Finish the link-kit job

2017-06-23 Thread Theo de Raadt
> The "problem" with Theo (Buehler)'s approach is that that next boot > will still not use a relinked kernel, Any kernel you build is randomly linked. So yes, the next boot is using a unique kernel. The distinction "relinked kernel" doesn't make sense. > so you need yet another reboot to

Re: Finish the link-kit job

2017-06-23 Thread Paul de Weerd
On Fri, Jun 23, 2017 at 07:53:35AM -0600, Theo de Raadt wrote: | > Perhaps we'll come up with a simpler way down the road, but it isn't | > *that* hard for manual upgrades. once you've installed the kernels, make | > sure you've got the correct hash: | > | > sha256 -h /var/db/kernel.SHA256

Re: Finish the link-kit job

2017-06-23 Thread Theo de Raadt
> Perhaps we'll come up with a simpler way down the road, but it isn't > *that* hard for manual upgrades. once you've installed the kernels, make > sure you've got the correct hash: > > sha256 -h /var/db/kernel.SHA256 /bsd > > and the rc script will do the rest after the next reboot. I

Re: Finish the link-kit job

2017-06-23 Thread Theo Buehler
On Fri, Jun 23, 2017 at 12:37:38PM +0200, Paul de Weerd wrote: > On Fri, Jun 23, 2017 at 04:28:15AM -0600, Theo de Raadt wrote: > | > /mnt/usr/sbin/chroot /mnt /usr/local/libexec/reorder_kernel > | > > | > ... > | > > | > + mail -Es "$(hostname) Kernel relink info" root

Re: Finish the link-kit job

2017-06-23 Thread Paul de Weerd
On Fri, Jun 23, 2017 at 04:28:15AM -0600, Theo de Raadt wrote: | > /mnt/usr/sbin/chroot /mnt /usr/local/libexec/reorder_kernel | > | > ... | > | > + mail -Es "$(hostname) Kernel relink info" root >/dev/null | | No, that isn't cool. | | Yes, we are going to link in the

Re: Finish the link-kit job

2017-06-23 Thread Theo de Raadt
> /mnt/usr/sbin/chroot /mnt /usr/local/libexec/reorder_kernel > > ... > > + mail -Es "$(hostname) Kernel relink info" root >/dev/null No, that isn't cool. Yes, we are going to link in the install media. But not by reusing code that way. Any chroot handling must be done

Re: Finish the link-kit job

2017-06-23 Thread Paul de Weerd
On Wed, Jun 21, 2017 at 01:13:31PM -0600, Theo de Raadt wrote: | Future work should be to see if we can build a fresh kernel at | install/upgrade time, for that "every computer is unique" feel. How about we move the rc bits out from rc and into a small script that we call from rc. Now we can

Re: Finish the link-kit job

2017-06-21 Thread Marc Espie
On Wed, Jun 21, 2017 at 01:13:31PM -0600, Theo de Raadt wrote: > (config(8) was modified because reaching this point on multiple > architectures was EXCEEEDINGLY PAINFUL. I am desperately trying to > avoid Makefile.* divergence) I don't know if modifying config to write more boilerplate is such

Finish the link-kit job

2017-06-21 Thread Theo de Raadt
We've had the linkkit components in the tree for a while, but it has taken nearly 20 rounds between rpe/tb/myself to get the last few bits finished. So that the link kit is cleanly used at reboot, but also fits in with the practices kernel developers follow. Here are the remaining pieces. 1)