Date: Mon, 2 Feb 2015 11:00:47 -0800 From: Nick Rogers <ncrogers@gmail.com> To: Kevin Oberman <rkoberman@gmail.com> Cc: FreeBSD Ports ML <freebsd-ports@freebsd.org>, "Dr. Peter Voigt" <pvoigt@uos.de> Subject: Re: www/squid does not shutdown via rc Message-ID: <CAKOb=Ybbojyeye4v7Ypfp-N8Z3rKnuGbjCHkkULKALZ3baYYeg@mail.gmail.com> In-Reply-To: <CAN6yY1uiFjsyjDdVjiBu5-H1-s-K145H9B4WwpFA4mEtMenxeA@mail.gmail.com> References: <20150126152433.52f07277f377f9396b65c9a8@mimar.rs> <20150127.002919.335530336.yasu@utahime.org> <20150126163934.32f199d43d86a70b00dd7e4a@mimar.rs> <20150127.010539.230444205.yasu@utahime.org> <54C6695E.6010704@freebsd.org> <20150126212514.56c8f0866f1d63bb98089dd0@mimar.rs> <20150126235655.5d371915@kirk.drpetervoigt.private> <CAN6yY1uciVB-83=ECbrtdnNOFDs3VCX9UA97thK8mQ08aavHtw@mail.gmail.com> <20150127035200.GF44537@home.opsec.eu> <54C73A0E.8050501@FreeBSD.org> <20150127115151.afeb1ee969a562e8f42e300c@mimar.rs> <20150128155846.76d77a18@kirk.drpetervoigt.private> <CAN6yY1uiFjsyjDdVjiBu5-H1-s-K145H9B4WwpFA4mEtMenxeA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 30, 2015 at 8:51 PM, Kevin Oberman <rkoberman@gmail.com> wrote: > On Wed, Jan 28, 2015 at 6:58 AM, Dr. Peter Voigt <pvoigt@uos.de> wrote: > > > On Tue, 27 Jan 2015 11:51:51 +0100 > > Marko Cupa=C4=87 <marko.cupac@mimar.rs> wrote: > > > > > On Tue, 27 Jan 2015 07:11:10 +0000 > > > Matthew Seaman <matthew@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=3D 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. > > > > Sorry for the late response. I've had guests for hte past few days and > simply have not had time to properly address your concerns. > > While most of these concerns are not an issue, exactly why gets a bit mor= e > complex. And there are some real issues, but this is an exceptionally > simple case and eliminates most of them. See comments in-line. > > > > > @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. > > > > It does, but very little. In general, freebsd-update is a binary update > tool. While it does update sources, if they are present, it makes no use = of > those sources. > > My instructions provided for saving the GENERIC kernel where freebsd-upda= te > will use it instead of the running kernel. /boot/GENERIC is used only be > freebsd-update. It is otherwise unneeded. This does not touch any files > that will normally require merging, which is often the main complication.= I > am unsure whether it will require a merge of the modified source files, b= ut > that is easily avoidable renaming /sys/kern/kern_sig.c.orig to overwrite > the patched /sys/kern/kern_sig.c file, returning the sources to their > original condition. > # cp /sys/kern/kern_sig.c.orig /sys/kern/kern_sig.c > > This is not really required, but will assure that, from the perspective o= f > freebsd-update, the system will be entirely unchanged. There is simply no > impact on future updates as there are no changes left. > > > > 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-fro= m-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? > > > > The running kernel is in boot/kernel. /boot/GENERIC is not present unless > you create it and, when present, it is used as the kernel which > frebsd-update will patch in the upgrade phase and then install in the > install phase. Actually, the Handbook recommends always keeping a copy of > the GENERIC kernel as /boot/GENERIC. There is no reason not to allow > freebsd-update to update the kernel as it will use /boot/GENERIC and igno= re > the running /boot/kernel/kernel. > Should /boot/GENERIC be a directory containing the contents of the default RELEASE kernel (i.e., a copy of /boot/kernel, including /boot/kernel/kernel, modules, and symbols) OR the actual kernel file itself (i.e., a copy of /boot/kernel/kernel)? > The only issue is a freebsd-update security patch prior to the release of > 10.2 that updates the kernel. To this date there have been none, but it i= s > certainly a possibility. If that should happen, the kernel will no longer > have these patches and you will need to re-apply them, following the same > instructions. Once 10.2 is released, the patches will no longer be needed= . > > > > Furthermore, installing a custom kernel influcences a subsequent build > > world process in a way that I do not yet fully understand. > > > > This is not really a "custom kernel" as it is usually meant. That usually > implies changes to the kernel config file, not patches to the kernel. It > gets a bit more complex if the patches touch code used in any kernel > modules. If that is the case, the process would involve a couple more > steps, but this patch does not do any such things. This is a very simple > case. > > > > > 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. > > > > Actually, dealing with multiple systems would be very little more complex > as, once you have the new kernel built, you simply can copy it to > /boot/kernel/kernel on all other systems. Also copy /boot/GENERIC so that > the next freebsd-update will not be impacted. In any case, you won't need > to worry about this. > > I will agree that, should you not feel comfortable with doing this, you > should not, but it is a very simple case and is a good way to learn about= a > few of the commonly used tools that a system admin may run into on > occasion. I would strongly suggest that you also read the section of the > Handbook that deals with freebsd-update as it may clarify some issues > better than I have. It is at > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgra= ding-freebsdupdate.html > . > It does talk about /boot/GENERIC, which the man page fails to cover. > -- > Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKOb=Ybbojyeye4v7Ypfp-N8Z3rKnuGbjCHkkULKALZ3baYYeg>