A "gshsec label" command writes metadata to two providers (confirmed by a gshsec dump right after), but there's no particular command to ask the kernel to try to look for providers which are a part of a gshsec set. So /dev/shsec/entry isn't populated automatically at times, although right after the "gshsec label" command it existed and works fine. But also because "gshsec label" seems destructive I would prefer that it would check for existing GEOM labels of any kind, requiring a "-f" to force overwrite. I had used it again thinking that it would detect a presence of an existing gshsec set and that the label command would trigger its appearance in /dev/shsec/. I'd like to see gshsec and others check for the presence of existing GEOM metadata, even of the same time, and to require -f to overwrite that. Also I'd like autodetection of a GEOM setup such as gshsec to be more comprehensive, or I'd like the user to specifically be able to manually request that this GEOM set be enabled (either through a gshsec command or some global GEOM command). Fix: None How-To-Repeat: Use gshsec label, stop and disconnect and remove one of the providers (suppose it is a .eli and one does geli detach). Notice how that upon reattach the gshsec label isn't automatically populated. Similarly note that there seems to be no way to resume an existing gshsec, even though there is actual metadata stored! Note that gshsec label will happily overwrite with a new label even if there is already existing data.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped