I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc.
Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens).
Now handle the case where you have a bad connection so it is constantly flapping as inserted & not.
Now handle the case where it gets ripped out with no warning.
Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...
I think I get your point, but for what it's worth the sysvinit cryptroot/crypttab setup has worked seamlessly for servers for years. Basically if keyscript fails (smart card not available or challenge material not available or TPM won't unseal) it falls back to ask pass on a TTY with the hopes that you can type something in.
I also do appreciate the systemd features for mobile and desktop devices.
But the sysvinit mechanisms aren't rendered completely irrelevant by systemd; the sheer stupid dumb luck of the the thing is actually deterministic and repeatable in my experience. systemd migrations have exposed hidden dependencies I hadn't previously had to worry about between services, which is good in one way, but not necessarily good in other ways (transient intermittent failures which never occurred under sysv).
Yes, it's unfair to blame systemd for poorly defined services - I do like the concept systemd is offering in that respect. But if I have servers in the rack which have smart cards in them that I know are always attached except for very rare events where a sysadmin will be dealing with things, I don't think there's harm in a 4-line shell script failing maybe once or twice in a server's lifetime if it means not having to maintain bespoke C programs for years and years
I'm sorry. I wasn't clear. I was asking about the work that gets you to the point where the volume appears. You don't necessarily have a device file for the volume, so something needs to be ready to handle that logic when the device is inserted, then when it has figured that out, you have to notify the automounter that it is time to go to work (or not), etc.
Now add logic so that all of this magically gets powered down all the time to conserve power (and then figure out what you do with the filesystem when that happens).
Now handle the case where you have a bad connection so it is constantly flapping as inserted & not.
Now handle the case where it gets ripped out with no warning.
Now handle the case where you have a smartcard and you are using it to provide the key to decrypt another smartcard...