From owner-svn-src-all@freebsd.org Fri Apr 8 05:44:59 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 424BAB07726 for ; Fri, 8 Apr 2016 05:44:59 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AC401934 for ; Fri, 8 Apr 2016 05:44:59 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x22c.google.com with SMTP id s79so125544190oie.1 for ; Thu, 07 Apr 2016 22:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=smBFZtwosPP2IlQYO8YX0nZ4/Rpufz/nhm48tPETzDU=; b=mNl33zup0Y8+qeHj10KFjEpeQm9iqK/4ofbYWr/WTitUG2NHQYa1nle3glqY3Gg4eW aCJDnGPH+W3ilwazh3patMF13J7gS1y3CyX959VSD90DEk4eCmNpM//YUpAHFHA7DgmZ eDtwXaQFv7aurvnmGkJjicrkz/W9RkvxGAl48zid191Zx94NBh3vMO/9R3h4t4DGsm9Y +KytX2gVFQsUXoh8OiTnL6fSKehivMqxxH2DybPVo4QhsSYdY2R8OEGW+Z5FWoClg4JX MjQ0h6jA4jMhD3+L6VTDeIYtXRff5FaPJCUt+fjgosfcyCx+S1vCQCW2EZozLHcYWACm kx6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=smBFZtwosPP2IlQYO8YX0nZ4/Rpufz/nhm48tPETzDU=; b=BnDPZtwdlYRFFHg1Q9FWS8m1Biv2ppweGS+GCy4ttEarWkEPvVYZ7oFJraOVjTSXy9 HVjr2D3W2mGjKr6iIQaorkqPncv5j/b4A8+yd2CSETGRNimbuXgq4belyhcbEqwLl08B KTv9s3tGPk2Bk5OIKTIkUq3IUQxgzK9T51/S2hY0KbPko9WzXgRg4KIAcY+C3ElHKJCi j8r/iNjGI62FwSeqmGP2AnvdBfrWyfPInToV6kvn0H84umXazr+Ii6pUfOid4G52uFHg kYxI2KzGZdUuD0OLzJNS4SlHAZiL+ygwtcC2OJ17uANKiCxGbptBL0rMsVEfQyUZqwG0 11Qw== X-Gm-Message-State: AD7BkJIuKAA4MbURhuCqq4Zrzntny3Zk17uLtB0jkkgmpSsdGU5Wwm9tegIUxIYbgUMu7NeB5Jg9u5a+y/TUJs0s MIME-Version: 1.0 X-Received: by 10.157.15.136 with SMTP id d8mr3591200otd.20.1460094298221; Thu, 07 Apr 2016 22:44:58 -0700 (PDT) Sender: sobomax@sippysoft.com Received: by 10.157.15.5 with HTTP; Thu, 7 Apr 2016 22:44:58 -0700 (PDT) In-Reply-To: <20160408121934.H1779@besplex.bde.org> References: <201604080024.u380OL4Q087516@repo.freebsd.org> <20160408121934.H1779@besplex.bde.org> Date: Thu, 7 Apr 2016 22:44:58 -0700 X-Google-Sender-Auth: YzH64lgHp5eLfcs_0oAP1zsN1TI Message-ID: Subject: Re: svn commit: r297690 - head/sys/boot/forth From: Maxim Sobolev To: Bruce Evans Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 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: Fri, 08 Apr 2016 05:44:59 -0000 Hi Bruce, thanks for the input! I will see if I can move that piece into loader.8 and extend it a bit from the source "documentation". -Max On Thu, Apr 7, 2016 at 8:38 PM, Bruce Evans wrote: > On Fri, 8 Apr 2016, Maxim Sobolev wrote: > > Log: >> Document vfs.root.mountfrom. >> >> Reviewed by: imp, wblock >> > > The format of this variable is still undocumented, except in the source > code. > > Modified: head/sys/boot/forth/loader.conf.5 >> >> ============================================================================== >> --- head/sys/boot/forth/loader.conf.5 Fri Apr 8 00:01:19 2016 >> (r297689) >> +++ head/sys/boot/forth/loader.conf.5 Fri Apr 8 00:24:21 2016 >> (r297690) >> > > This variable is (partly) documented in a different wrong file than the > source file. It isn't a loader option. It is a kernel tunable. No > other kernel tunables are documented in loader.conf.5. Some of them are > documented in loader.8 (not really the right place --- loader is just 1 > way of setting them, and isn't a way of reading or interpreting them). > loader.8 also documents most loader options as BUILTIN ENVIRONMENT > VARIABLES. It does this much better than loader.conf.5. It documents > 30 such options and only has a couple of ordering errors in the list, > whie loader.conf.5 documents 15 such options in random order. About > half of the 15 are in both, and their descriptions give quite different > details in a quite different style (too much double quoting in > loader.conf.5). loader.8 documents only 16 tunables, with more ordering > errors that for options. > > @@ -112,6 +112,31 @@ The name must be a subdirectory of >> that contains a kernel. >> .It Ar kernel_options >> Flags to be passed to the kernel. >> +.It Ar vfs.root.mountfrom >> +Specify the root partition to mount. >> +For example: >> +.Pp >> +.Dl vfs.root.mountfrom="ufs:/dev/da0s1a" >> > > The source code gives the details needed to actually use this variable > without guessing from a single example. It gives both an informal and > formal description: > > X /* > X * The root filesystem is detailed in the kernel environment variable > X * vfs.root.mountfrom, which is expected to be in the general format > X * > X * :[][ :[] ...] > X * vfsname := the name of a VFS known to the kernel and capable > X * of being mounted as root > X * path := disk device name or other data used by the filesystem > X * to locate its physical store > X * > X * If the environment variable vfs.root.mountfrom is a space separated > list, > X * each list element is tried in turn and the root filesystem will be > mounted > X * from the first one that suceeds. > X * > X * The environment variable vfs.root.mountfrom.options is a comma > delimited > X * set of string mount options. These mount options must be parseable > X * by nmount() in the kernel. > X */ > > I thought that these careful descriptions were broken using sbufs which > accidentally (?) changed the separator from space to newline. However, > I can' find any trace of this in my config files -- they now just use > a space. I might have just been confused by old kernels not supporting > lists. > > I mainly use this feaature to work around the renaming of ad to ada and > loss of the compatibility support for this. My lists look like > "ufs:ad4s3a ufs:ada0s3a ufs:ad0s2a". Old kernels don't support lists, > but they also don't support ada; they use the first entry and this works > although the documentation says it shouldn't (the comment says that > the format is :[] and doesn't mention field separators or > trailing garbage). FreeBSD-11 doesn't supprt ad, but it supports lists; > so it uses the second entry. This works on 2 systems with similar disk > numbering. The third entry is for another system with different disk > numbering an no ad4. This almost never works -- with old kernels, the > list doesn't work, and with new kernels the list works and ada0 exists > and ada0s3a exists, but it is not the right boot partition. This works > with intermediate kernels with lists but no ada0, so that the third > entry is used. > > Bruce > >