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

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.
Thanks,
-Garrett

$ cat ~root/bin/installkernel
#!/bin/sh

SRCCONF=${SRCCONF:=/etc/src.conf}

set -e

for i in $(make -f "$SRCCONF" -V KERNCONF); do
    # Using svn info is bad because that captures the sourcebase revision,
    # which may or may not match the actual kernel being installed's revision.
    # Something like `strings kernel | awk '/^FreeBSD [0-9]+/' ' would be
    # better.
    sudo make installkernel \
        KERNCONF=$i \
        INSTKERNNAME=$i.r$(svn info | awk '/^Revision/ {print
$2}')${SUFFIX:+.$SUFFIX} \
        $*
done

Example:

$ make -VKERNCONF -f /etc/src.conf
BAYONETTA
$ cd /usr/src && ~root/bin/installkernel && ln -sfh BAYONETTA
/boot/kernel && reboot