Re: Removal of GEOM_BSD, GEOM_MBR, GEOM_PC98 and GEOM_SUNLABEL

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