From owner-freebsd-current@FreeBSD.ORG Wed May 13 22:50:25 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94D98106566C for ; Wed, 13 May 2009 22:50:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx24.fluidhosting.com [204.14.89.7]) by mx1.freebsd.org (Postfix) with ESMTP id 47F7B8FC12 for ; Wed, 13 May 2009 22:50:25 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 18945 invoked by uid 399); 13 May 2009 22:50:21 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 13 May 2009 22:50:21 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A0B4EAB.30401@FreeBSD.org> Date: Wed, 13 May 2009 15:50:19 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: Jeremie Le Hen References: <20090510165737.GB88857@obiwan.tataz.chchile.org> <4A07AF92.1040309@FreeBSD.org> <20090513065650.GF45358@obiwan.tataz.chchile.org> In-Reply-To: <20090513065650.GF45358@obiwan.tataz.chchile.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-doc@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: New mergemaster option -I, failsafe install files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2009 22:50:25 -0000 Jeremie Le Hen wrote: > On Sun, May 10, 2009 at 09:54:42PM -0700, Doug Barton wrote: >> Jeremie Le Hen wrote: >>> Hi Doug, >>> >>> As you may guess from my multiple emails, I'm in the process of >>> upgrading my jails :-). >>> >>> Since I have one jail per service, a very few number of configuration >>> files are modified on each jail. As most of user of FreeBSD I think, >>> I'm used to run "mergemaster -iU" to automate the process as much as >>> possible. The problem with service jails (chapter 15.6.1 of the >>> handbook) is that / is read-only mounted on all jails, /etc /var /root >>> and a few other places being symlinks to /s, the private read-write >>> space of each jail. Thus when mergemaster tries to update >>> /boot/devices.hints it fails and abort. >> I think the way to solve this problem would be with an >> MM_PRE_COMPARE_SCRIPT that deletes /boot/device.hints (and any other >> relevant files) from the temproot. If they are not present in that >> directory when the comparison starts then it's a non-issue. > > Actually, /boot belongs to the read/only nullfs mount, so it is not > possible to use MM_PRE_COMPARE_SCRIPT from the jail. The only way to > handle this currently is to remove /boot from the jail template. > > I'm Cc:ing -doc@ because chapter 15.6.1 of the handbook (service jails) > needs to be updated to remove /boot from the jail template "mroot". I think you misunderstood my suggestion. I was not suggesting to do anything to the files on the installed system (whether in the jail or in the host). The temproot that I was referring to is the path that mergemaster installs the files to prior to comparing them to the installed versions. When it starts the comparison it simply runs through every file in the temproot and compares it to the equivalent on the live system. If a given file is removed from the temproot before the comparison starts, nothing further will happen with that file. I think something like this would do what you want, it's a modified version of one that I used for a long time before I added the IGNORE_FILES option: #!/bin/sh # NOTE: No PATH needed, because mm's PATH is already draconian enough case "${PRE_WORLD}" in '') rm -f ${TEMPROOT}/boot/device.hints ;; esac You could also try adding the following to either /etc/mergemaster.rc or ~/.mergemasterrc: IGNORE_FILES=/boot/device.hints That _should_ work, but the first method will work for sure. hth, Doug -- This .signature sanitized for your protection