Date: Sat, 04 Apr 2009 09:09:55 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: Tai-hwa Liang <avatar@mmlab.cse.yzu.edu.tw> Cc: freebsd-current@freebsd.org Subject: Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL Message-ID: <42E3BB6C-16C7-4211-A4FD-A362383418E9@mac.com> In-Reply-To: <09040423143118.91304@www.mmlab.cse.yzu.edu.tw> References: <DED07257-A1C7-4504-9A9E-CAAC2A9737D6@mac.com> <gqt3um$f77$3@ger.gmane.org> <20090331155542.74d89d64@ernst.jennejohn.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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?
--
Marcel Moolenaar
xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42E3BB6C-16C7-4211-A4FD-A362383418E9>