Meu objetivo é atrasar o desbloqueio deste USB para depois que o sistema inicializar com o ssh.serviceativo e nunca expirar até que seja digitado. No entanto, o tempo limite ainda acontece e prossegue para getty. Você não pode digitar sua senha quando o prompt de senha aparecer (o TTY não está anexado)
Eu tenho copiado o que autoresulta /etc/crypttabem via systemd-cryptsetup-generator. Eu também estive olhando systemctl list-dependenciespara ver o que sysinit.targetdá systemd-ask-password-console.pathpara anexar ao console TTY.
/etc/crypttab
crypt /dev/disk/by-label/crypt none nofail,noauto,timeout=0,x-systemd.device-timeout=0
/etc/systemd/system/finish.target
[Unit]
Description=Mount crypt USB
Requires=multi-user.target
[email protected] systemd-ask-password-console.path
After=ssh.target
[email protected]
[Install]
WantedBy=multi-user.target
Se eu fizer Wants=mnt-crypt.mountou Wants=dev-mapper-crypt.devicerealmente respeitar os tempos limite, mas ainda não aceitar a entrada de senha.
ls -la /etc/systemd/system/multi-user.target.wants/finish.target
lrwxrwxrwx. 1 root root 33 Jun 6 00:04 /etc/systemd/system/multi-user.target.wants/finish.target -> /etc/systemd/system/finish.target
systemctl list-dependencies
● ├─finish.target
● │ ├─systemd-ask-password-console.path
● │ ├─[email protected]
│ └─...
Se o fizer, systemctl restart systemd-ask-password-console.serviceposso realmente começar a digitar a senha e ela funcionará como esperado tanto no terminal em execução quanto no console na tela ( /dev/tty1).
Parece que há um relacionamento em algum lugar que impede systemd-ask-password-consoleo início após a inicialização inicial, porque ele começará com prazer mais tarde ao lado de systemd-ask-password-wall.
Mesmo se eu copiá-lo e editá-lo como um novo serviço, ele também iniciará o systemd-ask password --watch --consoleprocesso.