Date: Sun, 14 Aug 2011 11:35:38 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Freddie Cash <fjwcash@gmail.com> Cc: Alexander Best <arundel@freebsd.org>, freebsd-current@freebsd.org Subject: Re: [rfc] replacing /boot/kernel.old with a unique directory name Message-ID: <CAGH67wSLQZ7%2BuBtRQPfL5n4Cd57-AQ4vYahXhOj9%2BWKKuGPmtg@mail.gmail.com> In-Reply-To: <CAOjFWZ5uQ72D9H5SQnuS0uL3eszkZuGa0jHieo7WDaEOSFnAgQ@mail.gmail.com> References: <20110813195127.GA34295@freebsd.org> <CAOjFWZ5uQ72D9H5SQnuS0uL3eszkZuGa0jHieo7WDaEOSFnAgQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 14, 2011 at 10:56 AM, Freddie Cash <fjwcash@gmail.com> wrote:
> On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best <arundel@freebsd.org>wro=
te:
>
>> 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 a=
s
>> the
>> results of target installkernel, we create a unique directory name for t=
he
>> 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 kern=
el
>> without /dev/{u}random support.
>>
>
> A better method may be to use KODIR to install the *new* kernel to a uniq=
ue
> directory via installkernel (make KERNCONF=3DSOMEKERNEL
> KODIR=3D/boot/SOMEKERNEL-rev-whatever installkernel) and then using "next=
boot
> -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next bo=
ot.
>
> 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 t=
he
> new kernel works. =A0And 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=3D${SRCCONF:=3D/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 revisi=
on.
# Something like `strings kernel | awk '/^FreeBSD [0-9]+/' ' would be
# better.
sudo make installkernel \
KERNCONF=3D$i \
INSTKERNNAME=3D$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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGH67wSLQZ7%2BuBtRQPfL5n4Cd57-AQ4vYahXhOj9%2BWKKuGPmtg>