> 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. (like after an install or
> upgrade you're still booting into the release or snapshot kernel,
> instead of a relinked one)
Please, you are making a distinction which will be solved in the next
round of diffs.
> 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.
No. We don't need a damn script which people will play with. The
only tools a user needs to build and install a kernel are:
make
make install
Those will work for all cases.
> Of course, that's not guaranteed to work and has issues with the
> bsd.rd environment as you pointed out.
Again, we don't need a new damn script. The installer is already a
script. We don't need it calling another script. We've been down
this road before, such as the installer doing all the specifics of
what netstart does in a ramdisk context, without requiring all the
specifics not needed in the ramdisk.
>
> | 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.
You haven't completed your reading. "make install" takes care of that.
If you just copy kernels around you are going to screw yourself. Use
"make install". Don't provide people with any other tricky advice,
because it will very soon be wrong.
