===
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
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 point.
> 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 relink
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 /bs
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 /bs
> 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 thin
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 >/dev
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 insta
> /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 mu
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 also
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
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) gap
12 matches
Mail list logo