Date: Wed, 1 May 2013 08:23:57 +0200 From: Oliver Pinter <oliver.pntr@gmail.com> To: Brett Glass <brett@lariat.org> Cc: Glen Barber <gjb@freebsd.org>, Chris Rees <utisoft@gmail.com>, Colin Percival <cperciva@freebsd.org>, freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver Message-ID: <CAPjTQNELg_yGMjEhRxLJmWGd07Nyf8oQriN-==Tt8m%2Biq4ge%2BQ@mail.gmail.com> In-Reply-To: <201305010243.UAA08356@lariat.net> References: <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <CADLo839_J40E4O2s7Af3r1stH98B-fjKtBwmNovaPfY7peqi7Q@mail.gmail.com> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> <201305010149.TAA07809@lariat.net> <20130501022228.GD1579@glenbarber.us> <201305010243.UAA08356@lariat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/1/13, Brett Glass <brett@lariat.org> wrote:
> At 08:22 PM 4/30/2013, Glen Barber wrote:
>
>>Maybe I am missing the fundamental usage of freebsd-update(8). How does
>>using freebsd-update(8) to fetch src/ updates install a new kernel?
>
> When you use freebsd-update(8) in the usual manner, it fetches all of the
> source and binary updates necessary to bring the system up to the latest
> security patch level. When a userland binary is updated, it overwrites the
> source and binary. But when the kernel is updated, it moves /boot/kernel to
> /boot/kernel.old and then drops a GENERIC kernel into /boot/kernel. If
> there were no loadable modules in /boot/kernel at the start of the update,
> none are placed in /boot/kernel afterward. This is problematic, because
> the custom kernel that previously resided in /boot/kernel might have had
> some
> necessary modules built in... and they will not be available, either as
> compiled-in modules or as loadable modules, at the next reboot.
>
> To leave the system in a precarious state, where a power glitch could
> leave it unable to reboot, does not seem to me like a good idea. If
> /boot/GENERIC exists (which means that the administrator has built a custom
> kernel and saved the GENERIC kernel there), best to update /boot/GENERIC and
>
> leave the custom kernel in place, to be rebuilt if needed.
>
> The administrator will probably want to rebuild his or her custom kernel
> after the update... unless it didn't contain the code that was fixed by
> the patch, in which case there's no need. (My kernel didn't contain NFS,
> and I didn't build any loadable NFS modules, so I actually didn't need a
> rebuild.)
The ultimate solution for you described in loader.conf(5).
kernel Name of the kernel to be loaded. If no kernel name is set,
no additional modules will be loaded. The name must be a
subdirectory of /boot that contains a kernel.
And set INSTKERNNAME in make.conf - this are in Makefile.inc1.
--8<--
#!/bin/sh
echo "INSTKERNNAME=magickernel" >> /etc/make.conf
echo "kernel=magickernel" >> /boot/loader.conf
cd /usr/src
make kernel
-->8--
good luck :)
>
> --Brett Glass
>
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPjTQNELg_yGMjEhRxLJmWGd07Nyf8oQriN-==Tt8m%2Biq4ge%2BQ>