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 /bsd
| >
| > and the rc script will do the rest after the next reboot. I think this
| > is bearable.
|
| I think that is bad advice. At next reboot, it will build a new
| kernel using the link kit. But where's the step that updates the link
| kit?? You didn't describe it, so uhm... two boots later you'll be
| running something different than intended.
The compile.tgz tarball will have been updated, but not yet extracted.
Something /etc/rc will do at the next boot.
The "problem" with Theo (Buehler)'s approach is that that next boot
will still not use a relinked kernel, so you need yet another reboot
to relink. (like after an install or upgrade you're still booting
into the release or snapshot kernel, instead of a relinked one)
That's the benefit of having a simple to use script to call from
userland *before* the reboot: you get that "every computer is
unique"-feel you mentioned.
Of course, that's not guaranteed to work and has issues with the
bsd.rd environment as you pointed out.
| The correct process is much simpler. In a kernel compile directory,
| simply type
|
| make install
|
| That updates the kernel, the link kit, and the hash.
Although a very cool solution for those machines where I (and other
people) build kernels, this is about an in-place upgrade using
snapshot or release kernels and file sets: the kernel compile
directory doesn't necessarily exist.
Paul 'WEiRD' de Weerd
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
