From owner-freebsd-current@FreeBSD.ORG Mon Apr 6 01:33:02 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 84830106566B for ; Mon, 6 Apr 2009 01:33:02 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.freebsd.org (Postfix) with ESMTP id 265328FC12 for ; Mon, 6 Apr 2009 01:33:01 +0000 (UTC) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id F1F00E43407; Mon, 6 Apr 2009 09:32:37 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mmlab.cse.yzu.edu.tw; s=test; t=1238981558; bh=dUQVp7WfzKu2Cy61qZtEvcPapk3Y01AbNg8oLTElEjE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=a29gsyTSxSdR13q5IYg/jyxjE4/i+rrAaO+XC92Dg9gsvv1VjMohC/hT1f5HmnDBy 0e1yOhstKkxpZvQ0WyrFSfTwMHNBWj4y97L7b3KJU5sS3PiroSvbuQqw74lw2M5Zqk NgZnyw4UW1XBeMaNtMlvSYKgERrLEm5UDDEfV4pg= Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id F0284E43406; Mon, 6 Apr 2009 09:32:37 +0800 (CST) Date: Mon, 6 Apr 2009 09:32:37 +0800 (CST) From: Tai-hwa Liang To: Marcel Moolenaar In-Reply-To: <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> Message-ID: <0904060920495.5188@www.mmlab.cse.yzu.edu.tw> References: <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <0904031327195.78401@www.mmlab.cse.yzu.edu.tw> <8583A3BA-2871-4DF4-9792-1031044A4A22@mac.com> <09040315161311.79260@www.mmlab.cse.yzu.edu.tw> <1DDB4728-7742-4265-999F-F1A0FC69F9E4@mac.com> <0904040858433.86299@www.mmlab.cse.yzu.edu.tw> <7AD352A2-BEDD-4DFD-896D-104E6376D887@mac.com> <09040411131618.87313@www.mmlab.cse.yzu.edu.tw> <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL 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: Mon, 06 Apr 2009 01:33:02 -0000 On Sat, 4 Apr 2009, Marcel Moolenaar wrote: > > On Apr 4, 2009, at 8:16 AM, Tai-hwa Liang wrote: > >> I have to use ad0s7 after moving to GEOM_PART_{BSD,EBR,MBR}; otherwise, >> booting with with /dev/ad0s7a looks like: > >> Can't stat /dev/ad0s7a: No such file or directory > > It just hit me (doh!). The problem is that /dev/ad0s7 is a > compatibility symlink, which exists outside of the GEOM > graph. That is, it's a symlink that geom_dev creates and > it provides an alternate name to the same "entry point". > > In your case another GEOM (gpart for the BSD scheme) is > stacked onto the gpart GEOM for the EBR scheme) -- with > possibly other GEOMs in between. The provider for the 'a' > partition is named based on the underlying consumer, which > is based on the true name of the GEOM: "ad0s3+00103bf1a". > > There's no alias for the device node that corresponds to > this GEOM and based on some alias that was created by some > other geom_dev. This is simply not possible to without > messing things up pretty easily. > > In short: the solution of using a compatibility symlink is > flawed at best and useless in the worst case. Just found another breakage with compatibility symlink: # geli attach -k ~avatar/seprom.bin /dev/ad0s8 Enter passphrase: geli: Provider ad0s8 is invalid. # geli dump /dev/ad0s8 magic: GEOM::ELI version: 3 flags: 0x0 ealgo: AES-CBC keylen: 128 provsize: 48423707136 sectorsize: 4096 keys: 0x01 iterations: 48331 Salt: ..... Master Key: ..... MD5 hash: 38d02b9d0cae948d358e6bc2d570ee7d # Replacing /dev/ad0s8 with /dev/ad0s3+0017cda1 or using old GEOM_{MBR,BSD} solves the problem. > There's no software fix for it. I think we're left with a > simple choice: > 1) have EBR create the "old" names and tell the user to > reboot every time they make a change in FreeBSD and when > booting into FreeBSD after the EBR changed, boot into > single user mode to change /etc/fstab and *then* go into > multi-user mode, or > 2) stick with the new names and tell the user to make this > one-time adjustment during upgrades and that's it. > > If we choose 2, we can argue whether to keep the symlinks > or not. I'm sure there's a small group of people for which > it works, but I fear the majority of people still have > problems. > > Any thoughts? Given that the current symlink approach doesn't work well for me, I think both choices wouldn't make too much differences to me. Frankly, sticking with old GEOM_{MBR,BSD} probably introduces less POLA issues in my case. -- Thanks, Tai-hwa Liang