On Tue, 27 Jan 2015 11:51:51 +0100 Marko Cupać <marko.cu...@mimar.rs> wrote:
> On Tue, 27 Jan 2015 07:11:10 +0000 > Matthew Seaman <matt...@freebsd.org> wrote: > > > On 2015/01/27 03:52, Kurt Jaeger wrote: > > > Doesn't installing a custom kernel break freebsd-update ? > > > > No. freebsd-update has always supported using a custom kernel. It > > helps if you name your kernel something other than GENERIC, which > > you do by creating a modofoed kernel config file > > in /usr/src/sys/amd64/conf (or i386 if that's your architecture): > > eg. > > > > % cat FOO > > include GENERIC > > > > ident FOO > > > > and then add: > > > > KERNCONF= FOO > > > > to /etc/make.conf > > > > You should also edit /etc/freebsd-update.conf and change the > > 'Components' line to remove 'kernel' from the list. > > > > None of this is absolutely necessary, but it will help you avoid > > accidentally ending up with the generic kernel. > > > > In any case, what you will need to do is rebuild your kernel and > > reinstall it any time freebsd-update touches the kernel. You can > > use freebsd-update to maintain the kernel sources, which will pull > > in the needed updates to the kernel sources. > > The timing for this is really unfortunate for me, because I have just > re-installed my FreeBSD fleet of some 20 virtual servers without > sources included, and I just introduced "binary only" policy (ok I do > build my own ports on one server in poudriere, but all other servers > use packages). > > I guess theoretically it is possible to make "kernel build server" > which will build custom kernel for distribution to other servers. I > am just not sure how will RELEASE userland tolerate STABLE kernel. > > Does this sound reasonable? Any tips? > > Thank you in advance, Thanks to all who contributed to this thread. @Kevin: Your outline of kernel patching procedure is helpful and corresponds in most aspects what I have thought so far. I aggree with you that patching, building and installing a custom kernel can be managed. And I am sure that I can do it. So getting a custom kernel installed is one thing but keeping your system in a manageable way is another. Kurt and Mattew pointed out that you want to keep freebsd-update working in a reliable way and this obviously needs some manual interaction. Information about it is not too easily gathered and answers given here still leave some question open to me. I have had a hard time with freebsd-update when upgrading 10.0-RELEASE -> 10.1-RELEASE: https://forums.freebsd.org/threads/segmentation-fault-while-upgrading-from-10-0-release-to-10-1-release.48977/page-2#post-277094 and I do not want to get even more trouble letting freebsd-update confuse my system with a mixture of GENERIC and custom kernels ending in a situation where none of them is able to boot. I have learned that I can advice freebsd-update to not update my kernel but am still confused whether it is the version under /boot/GENERIC or the one under /boot/kernel. And I would like to know how to tell FreeBSD how to boot a certain kernel. All I know so far is that if a kernel fails to boot you have to boot into recovery and move kernel.old to kernel. Is there a boot menu available with the FreeBSD boot loader which would simplify life a lot? Furthermore, installing a custom kernel influcences a subsequent build world process in a way that I do not yet fully understand. If all above is clarified I could go the way of using a custom kernel. But to be honest: I would do it only, because I have just one FreeBSD server to mannage this way. The other FreeBSD based servers have FreeNAS and pfSense and are managed differently. But if I was an administrator with several FreeBSD servers, this would not be a way to go. Regards, Peter _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"