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.

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.

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.