[rfc] replacing /boot/kernel.old with a unique directory name

[Freddie Cash]

On Sun, Aug 14, 2011 at 11:35 AM, Garrett Cooper <yanegomi at gmail.com> wrote:

> On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash <fjwcash at gmail.com> wrote:
> > On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best <arundel at freebsd.org
> >wrote:
> >
> >> hi there,
> >>
> >> i just had the following idea: how about instead of copying the current
> >> kernel
> >> to /boot/kernel.old and then installing the new one under /boot/kernel
> as
> >> the
> >> results of target installkernel, we create a unique directory name for
> the
> >> old
> >> kernel?
> >>
> >> something like /boot/kernel-r${revision}-${/dev/random}?
> >>
> >> that would let people not only boot the previous kernel, but all kernels
> >> that
> >> have been replaced by target installkernel. this would make tracking
> >> issues,
> >> which have been introduced by a certain commit much easier, imho.
> >>
> >> i don't think implementing this logic would be that difficult. the only
> >> problem
> >> i see is with ${/dev/random} in the case where people are running a
> kernel
> >> without /dev/{u}random support.
> >>
> >
> > A better method may be to use KODIR to install the *new* kernel to a
> unique
> > directory via installkernel (make KERNCONF=SOMEKERNEL
> > KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using
> "nextboot
> > -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next
> boot.
> >
> > You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
> > then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
> > /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
> >
> > Sure, it's not automated yet, but the building blocks are there.
> >
> > This way, you never disturb the currently working kernel until you know
> the
> > new kernel works.  And if things go south with the new kernel, a simple
> > reboot is all that's needed to revert back to the working /boot/kernel.
> >
> > All that's needed is to automate things a bit (pick KODIR, set nextboot,
> > create a post-install target of some kind to run after booting the new
> > kernel).
> >
> > And, this leaves all of your kernels around if you want to play with
> > different ones.
>
>    Again, why build more complexity into the system when it does what
> you want in a more generic manner? Just to illustrate what I do on a
> weekly basis, here's my script and example invocation (I have other
> instances where I have more KERNCONFs and things are more
> complicated). You shouldn't have to do much more than what I did below
> when dealing with your specific case of interest -- especially
> because, as you and others have identified elsewhere it may not work,
> it might fill up whatever partition /boot is on, etc.
>

Unless I'mmissing something, we're saying essentially the same thing
(install new kernel to unique directory) , but you've done the work to
actually automate it.  :)

-- 
Freddie Cash
fjwcash at gmail.com