autofs: Make special_media more flexible

[trasz]

Summary

This makes the special_media properly handle GEOM providers
with slashes in their names, instead of quietly ignoring them.

This means it can now expose things like geli(4) attached
to a gptid label, or gmirror(4).

Note that this also exposes aliases created by geom_label(4);
one can use kern.geom.label.*.enable sysctls to get rid of them.

[rkoberman_gmail.com]

Patch is not working for me. When I attach the partition, the '.eli" device is created in /dev/gpt, but when I access it (hls /media/aux), the directory is empty. 'df' does not show the device as mounted. It appears that autofs is trying to use /dev/gpt/aux instead of /dev/gpt/aux.eli. This is obviously the wrong pseudo-device. I think the script needs to ignore any peudo-device if that device is also present with a '.eli' extension. Encrypted partitions are likely unique in this regard.

The output of my working (but insufficiently general) patch for geli support yields:

/etc/autofs/special_media.eli

aux
Recovery
SYSTEM

"aux" is the volume label of encrypted partition in /dev/gpt/aux.eli. "Recovery" and "SYSTEM" are Windows 10 partitions on this dual boot system. Al three show up in /media.

The output of this diff yields:

/etc/autofs/special_media

aux
Recovery
SYSTEM
aux
SYSTEM
SYSTEM
Recovery
Recovery

[rkoberman_gmail.com]

I neglected to note that kern.geom.label.gptid.enable and kern.geom.label.ufsid.enable are set to '0' on my system. I have not attempted playing with these. They were disabled years ago to make hald work with geli. Not sure if could make any difference, but I am pretty sure any impact would not be for the better.

[trasz]

Thank you for testing. The duplicated entries look interesting; I think this is another reason why the special_media map ignores geom_label(4) providers. I think we should have a sysctl that reports not just providers usage counts, but also their geom class names, so we can explicitely filter out labels, while keeping other providers with slash in their names.

[rkoberman_gmail.com]

This is a tricky issue. Back when hald and gnome-mount were first implemented at least 15 years ago I spent a fair bit of time working with marcus@ to get it all working. The code was ugly and should have been fragile, but actually required only one or two minor fixes from then until hald went away. Of course, that is what caused me to try autofs. The problem with geli is that the geli attach generates two devd events.; first, the creation of the gpt/label.eli device followed almost instantly by the creation of the ufs/label device. How autofs handles the attempt to access /media/aux is not clear to me, but mounting either should work. The problem may be that the ufs device will be deleted when the gpt device is mounted. perhaps some sort of race? I assume the internal call of mount in autofs is returning some error, but I don't see any logging of such.