From owner-svn-src-head@FreeBSD.ORG Mon Apr 25 05:00:55 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65BBD1065670; Mon, 25 Apr 2011 05:00:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0191A8FC0C; Mon, 25 Apr 2011 05:00:54 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3P4tfRe015983 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 24 Apr 2011 22:55:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <18B3AE1E-467E-4B23-81B9-AB1EDEFE1F7A@gsoft.com.au> Date: Sun, 24 Apr 2011 22:55:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201104240923.p3O9N8QG025386@svn.freebsd.org> <20110424161933.GA18775@vniz.net> <18B3AE1E-467E-4B23-81B9-AB1EDEFE1F7A@gsoft.com.au> To: "Daniel O'Connor" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 24 Apr 2011 22:55:45 -0600 (MDT) Cc: svn-src-head@freebsd.org, Alexander Motin , src-committers@freebsd.org, Andrey Chernov , svn-src-all@freebsd.org Subject: Re: svn commit: r220983 - head X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 05:00:55 -0000 On Apr 24, 2011, at 11:34 AM, Daniel O'Connor wrote: >=20 > On 24/04/2011, at 18:19, Andrey Chernov wrote: >> On Sun, Apr 24, 2011 at 09:23:08AM +0000, Alexander Motin wrote: >>> ATA device names in /etc/fstab or other places, make sure to = update >>> them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX = -> saY, >>> - where 'Y's are the sequential numbers for each type in order of >>> - detection, unless configured otherwise with tunables, see = cam(4)). >>> + where 'Y's are the sequential numbers starting from zero for = each type >>> + in order of detection, unless configured otherwise with = tunables, >>> + see cam(4)). >>=20 >> Is there any way to guess resulting 'Y' numbers _before_ booting new=20= >> kernel? I have remote machine with console access almost impossible = (very=20 >> hard for me). >>=20 >> It seems something like >> vfs.root.mountfrom=3D"ufs:/dev/ada0s1a ufs:/dev/ada1s1a ..." >> (up to max channels) helps to find root, but what about other mounted=20= >> disks? >=20 > The best way is to change to use GPT IDs (/dev/gptid/xxx) if you are = on a GPT system) or UFS IDs (/dev/ufsid/xxx) if you can't. I've been running with ufs labels for a couple of years now, since the = first rumblings of this hit the streets. They work great no matter what = the underlying partitioning scheme. The one drawback is that if you = have multiple disks with the same labels, then the first one wins. = Normally not a problem, but when you have it, you need to ensure the = right one is selected. I avoid this problem by prefixing a hostname to = the label... > gpart list will show the GPTID (rawuuid) and dumpfs will show the UFS = ID. >=20 > The following shell snippet will generate the UFS ID for a given FS. >=20 > getfsid() { > line=3D`dumpfs 2> /dev/null $1 | head | grep superblock\ location` > if [ $? -ne 0 ]; then > return 1 > fi > # dumpfs doesn't print leading 0s > eval `echo $line | sed -nEe 's/superblock location.*id.*\[ (.*) (.*)\ = ]/printf %0x $((0x\1 << 32 | 0x\2))/p'` > } This is also good. Warner=