Date: Mon, 6 Apr 2009 09:32:37 +0800 (CST) From: Tai-hwa Liang <avatar@mmlab.cse.yzu.edu.tw> To: Marcel Moolenaar <xcllnt@mac.com> Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL Message-ID: <0904060920495.5188@www.mmlab.cse.yzu.edu.tw> In-Reply-To: <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> References: <DED07257-A1C7-4504-9A9E-CAAC2A9737D6@mac.com> <60084D1E-9F64-463A-A8E9-7A237D5C7661@mac.com> <0904011910169.29800@www.mmlab.cse.yzu.edu.tw> <DC771BC5-F356-4D81-9082-91C922CCBF38@mac.com> <0904020940371.36257@www.mmlab.cse.yzu.edu.tw> <4CCDEFD6-830E-4C8F-B7A2-B7878F8842BE@mac.com> <0904021314574.37737@www.mmlab.cse.yzu.edu.tw> <E6347C70-099B-494A-89E2-8CBDDAA36A85@mac.com> <09040309313414.76643@www.mmlab.cse.yzu.edu.tw> <A821815A-63BE-4354-A8A9-6C1C8D277422@mac.com> <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> <D4955B7F-2781-4B43-AB91-2B971BB76D27@mac.com> <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0904060920495.5188>