From owner-freebsd-ports@FreeBSD.ORG Sat Jan 31 04:51:27 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D8C1B4D for ; Sat, 31 Jan 2015 04:51:27 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01AECAC4 for ; Sat, 31 Jan 2015 04:51:27 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kx10so60117946pab.12 for ; Fri, 30 Jan 2015 20:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iMwNhIklzor4JSD4GJRHKtmLy/EOD9RI0eX/Szbgfuk=; b=LX3Syvzz07ObN4dEvDgd/f0YK39qI9z8iFDERrhHHkBXCEc7ooEGxZHODanTh/b1Ng e32DqnhsATLfm8GSxd5fceDP1E6vYDYg+Avw7ezskkRa1wvXXNC7WW7Wf1q8ZBnzGCXa 0gvg8fJbP7Ap+V54u4Ygc1qbS/R+w0xxj6+4o5ZzPdu5c+Y2DUZEd3qT4rzfrR6IzXBw 3yPoWuaFcGApBO5g18iIIihjBISLSL920yyGHr9uJXGltPHMW96WEN1YNpFJLE8xYbYU PXShiQd0+oOsRa3NvXpqJJ4rad+1b7UIdWFSBv6L4sx5cnhBOMKzzPw7/CB+Pgjj9XRY ZuGg== MIME-Version: 1.0 X-Received: by 10.70.89.225 with SMTP id br1mr13964735pdb.8.1422679886510; Fri, 30 Jan 2015 20:51:26 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.22.231 with HTTP; Fri, 30 Jan 2015 20:51:26 -0800 (PST) In-Reply-To: <20150128155846.76d77a18@kirk.drpetervoigt.private> 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> <20150127035200.GF44537@home.opsec.eu> <54C73A0E.8050501@FreeBSD.org> <20150127115151.afeb1ee969a562e8f42e300c@mimar.rs> <20150128155846.76d77a18@kirk.drpetervoigt.private> Date: Fri, 30 Jan 2015 20:51:26 -0800 X-Google-Sender-Auth: Pi-2Rf1UP5Rg4Iq_TdFzOtksnwY Message-ID: Subject: Re: www/squid does not shutdown via rc From: Kevin Oberman To: "Dr. Peter Voigt" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD Ports ML X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jan 2015 04:51:27 -0000 On Wed, Jan 28, 2015 at 6:58 AM, Dr. Peter Voigt wrote: > On Tue, 27 Jan 2015 11:51:51 +0100 > Marko Cupa=C4=87 wrote: > > > On Tue, 27 Jan 2015 07:11:10 +0000 > > Matthew Seaman 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 more 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-update 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, but 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 of 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 ignore the running /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 is 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-upgradi= ng-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