From owner-freebsd-ports@FreeBSD.ORG Mon Feb 2 23:33:06 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D47E832 for ; Mon, 2 Feb 2015 23:33:06 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 E2EA0774 for ; Mon, 2 Feb 2015 23:33:05 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id b16so20658072igk.1 for ; Mon, 02 Feb 2015 15:33:05 -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=W2ryQk/+DWNpscGzTYCAVvc4pDJjKCZdWNstI3qTjEI=; b=iD4U38wesLm7iouoI6+PfLLiYeja7LRimqpOGXNlpo9l/1SAlSeMSk9czOMGIKySNE Sk4NjPjKPC67sikiHMsDVo/EpuGikTThweNi7Sg81VkvwIRGLmRq8Poiyxy4QmPFEMbz 76FcI0Hj96lbQgpZLO6XkcIkmEcD1ylLrVaOZTIY+v8nENr9kPwow8JrjdmMlzPWsro1 snRKkYN6lH4YOsdW5JGDScrQZFiCCQpaeahk1bs5w7ug/w0ENgny65nJvnV6KwnK4rDW Zr8lqeVpPnHLVKoz7nOxbPmWhZKRoeUr/UA1ujA4uvvrY0NtSGDEdBf/vPcUUa7673Ry /9gg== MIME-Version: 1.0 X-Received: by 10.70.89.225 with SMTP id br1mr33353194pdb.8.1422919985205; Mon, 02 Feb 2015 15:33:05 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.67.22.231 with HTTP; Mon, 2 Feb 2015 15:33:04 -0800 (PST) In-Reply-To: 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: Mon, 2 Feb 2015 15:33:04 -0800 X-Google-Sender-Auth: yqovHm5bxKJ2BFc1BLT8WNMDs-M Message-ID: Subject: Re: www/squid does not shutdown via rc From: Kevin Oberman To: Nick Rogers 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 , "Dr. Peter Voigt" 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: Mon, 02 Feb 2015 23:33:06 -0000 On Mon, Feb 2, 2015 at 11:00 AM, Nick Rogers wrote: > > > On Fri, Jan 30, 2015 at 8:51 PM, Kevin Oberman > wrote: > >> 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. I= t >> > > > 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 jus= t >> > > re-installed my FreeBSD fleet of some 20 virtual servers without >> > > sources included, and I just introduced "binary only" policy (ok I d= o >> > > 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 mo= re >> 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 tha= t >> > 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 n= o >> 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-fr= om-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 kerne= l >> > 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.ol= d >> > 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 unles= s >> 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 o= f >> 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. >> > > Should /boot/GENERIC be a directory containing the contents of the defaul= t > RELEASE kernel (i.e., a copy of /boot/kernel, including > /boot/kernel/kernel, modules, and symbols) OR the actual kernel file itse= lf > (i.e., a copy of /boot/kernel/kernel)? > It should be the kernel file, itself. Copy /boot/kernel/kernel to /boot/GENERIC. If you have a modified kernel you can grab the release kernel from a memstick or other distro. I think the Handbook covers it. I really recommend reading the freebsd-update section before messing with this stuff. It's not terribly long, but provides more detailed information on how to use it than the man page which is more technical and rather terse= . Note that this allows freebsd-update to deal with custom kernels, but not code mods to things that go into modules. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com