Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL

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_at_mac.com