por que o systemd cryptsetup tenta remontar a partição raiz já montada?

1

Eu tenho / etc / crypttab da seguinte forma:

sda7_crypt UUID=<...> /dev/sda8:/keyfile luks,discard,keyscript=/lib/esi/tpm_key_pass

sda7_crypt é o meu sistema de arquivos raiz, então eu uso update-initramfs para decriptá-lo desde o início (caso contrário, eu não poderia continuar a inicialização).

No entanto, o systemd cria automaticamente uma systemd-cryptsetup@sda7_crypt.service unit, que depende de um dev-sda8:-keyfile.device , que expira. Isso eventualmente falha, mas diminui o tempo de inicialização e cria mensagens de erro.

Como indico que isso já está montado pelo initram e não precisa ser montado pelo systemd? Eu tinha pensado sobre a opção noauto no crypttab, mas estava preocupado que isso pudesse impedir que ele fosse carregado no trem elétrico?

ATUALIZAÇÃO:

Eu tentei noauto , não funcionou. Ainda monta em initram, mas também ainda tenta na inicialização. O crypttab agora se parece com:

sda7_crypt UUID=<...> /dev/sda8:/keyfile luks,discard,keyscript=/lib/esi/tpm_key_pass,noauto

O que posso fazer para limpar isso?

    
por deitch 11.04.2016 / 17:11

2 respostas

1

Acontece que este é 2 problemas individuais do systemd, especificamente como systemd-cryptsetup-generator funciona.

  1. Ele não reconhece a opção keyscript=... , por isso, engasga com as chaves que são válidas para passdev como /dev/sda8:/keyfile .
  2. As unidades do systemd geradas automaticamente por systemd-cryptsetup-generator não são inteligentes o suficiente para reconhecer que o item já está montado e, portanto, tenta montá-lo novamente.

Para mais detalhes, veja este link

De acordo com o relatório de erros, você pode impedi-lo de gerar as unidades systemd passando as opções do kernel luks=no , mas isso evita a montagem automática do all crypttab. Tudo bem se tudo o que você tem for criptografado, mas se houver partições individuais separadas, elas não serão montadas.

    
por 12.04.2016 / 12:26
1

De acordo com o relatório de erros do debian, mascarar a unidade systemd é a melhor solução alternativa por enquanto.

systemctl mask systemd-cryptsetup@root_crypt.service

Obrigado a Michel por essa ideia!

    
por 10.05.2018 / 19:19