From owner-svn-src-all@FreeBSD.ORG Tue Nov 18 15:05:33 2014 Return-Path: Delivered-To: svn-src-all@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 D62B5719; Tue, 18 Nov 2014 15:05:32 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9206195; Tue, 18 Nov 2014 15:05:32 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XqkLM-000FLN-L6; Tue, 18 Nov 2014 15:05:24 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id sAIF5NhS006099; Tue, 18 Nov 2014 08:05:23 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18BCjbMHopxAizW2nuYe6zI X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: svn commit: r274653 - head/usr.sbin/freebsd-update From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20141118142449.GW17068@kib.kiev.ua> References: <201411181338.sAIDc9U3051869@svn.freebsd.org> <20141118142449.GW17068@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Nov 2014 08:05:22 -0700 Message-ID: <1416323122.1147.46.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Mark Felder X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 15:05:33 -0000 On Tue, 2014-11-18 at 16:24 +0200, Konstantin Belousov wrote: > On Tue, Nov 18, 2014 at 01:38:09PM +0000, Mark Felder wrote: > > Author: feld (ports committer) > > Date: Tue Nov 18 13:38:09 2014 > > New Revision: 274653 > > URL: https://svnweb.freebsd.org/changeset/base/274653 > > > > Log: > > Re-work non-persistent filesystem detection as it was not possible to > > detect /dev/md backed mfs filesystems that way. > > > > Differential Revision: https://reviews.freebsd.org/D1163 > > Approved by: ian > > > > Modified: > > head/usr.sbin/freebsd-update/freebsd-update.sh > > > > Modified: head/usr.sbin/freebsd-update/freebsd-update.sh > > ============================================================================== > > --- head/usr.sbin/freebsd-update/freebsd-update.sh Tue Nov 18 13:38:07 2014 (r274652) > > +++ head/usr.sbin/freebsd-update/freebsd-update.sh Tue Nov 18 13:38:09 2014 (r274653) > > @@ -604,14 +604,13 @@ fetchupgrade_check_params () { > > echo ${WORKDIR} > > exit 1 > > fi > > - for i in tmpfs mdmfs; do > > - if df -t ${i} ${WORKDIR} >/dev/null 2>1; then > > - echo -n "`basename $0`: " > > - echo -n "${_WORKDIR_bad2}" > > - echo ${WORKDIR} > > - exit 1 > > - fi > > - done > > + case `df -T ${WORKDIR}` in */dev/md[0-9]* | *tmpfs*) > > + echo -n "`basename $0`: " > > + echo -n "${_WORKDIR_bad2}" > > + echo ${WORKDIR} > > + exit 1 > > + ;; > > + esac > > chmod 700 ${WORKDIR} > > cd ${WORKDIR} || exit 1 > > > Why do you suppose that md-backed volumes are not persistent ? > vnode-backed devices are stable. > This is intended to guard against /var being an mfs due to diskless or readonly-root setup by rc.d/var during freebsd-update. I suppose it's possible for someone to configure /var in a persistant file-backed md on such a system. (Hmm, that's maybe even useful with nfs root, I may give that a try.) It looks like the information needed to figure out whether it's persistant or not is available in the kern.geom.conftxt sysctl, but parsing that with shell script is going to lead to some ugly hieroglyphics. Maybe a reasonable compromise would be instead of hard-fail, just warn the user that a memory-backed /var doesn't work and prompt them? (I'm not sure if the script is interactive at this point or not.) -- Ian