On Tue, Dec 12, 2023 at 06:40:32PM +0100, Lennart Poettering wrote: > On Mo, 11.12.23 12:48, Eric Curtin (ecurtin@xxxxxxxxxx) wrote: > > > Although the nice thing about a storage-init like approach is there's > > basically zero copies up front. What storage-init is trying to be, is > > a tool to just call systemd storage things, without also inheriting > > all the systemd stack. > > Just to make this clear: using things like systemd-cryptsetup outside > of the systemd stack is not going to work once you leave trivial > setups. i.e. the TPM hookup involves multiple services these days, and > it's not going to get any simpler. i.e. systemd-tpm2-setup, > systemd-pcrextend, systemd-pcrlock and so on. I am sorry, but doing > reasonable disk encryption with TPM involved means you either buy into > the whole systemd offer (i.e. with the service manager) or you have to > rewrite your own systemd. > > But maybe I am misunderstanding what you are saying here. I think a key factor here is that the initial suggestion was for automotive use cases. One can have a vastly simpler system if one is willing to deliver hardware-specific images, rather than trying to have a single image that supports many different hardware models. Automotive and other embedded systemd understandably do not want to pay for complexity that they do not need, and which is present to support features (such as supporting arbitrary hardware) they will never use. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
