Antes de apresentar novos relatórios de bugs, decidi tentar obter apoio na minha situação aqui. Desculpe pelo meu Inglês (pode parecer frustrante) com antecedência, sinta-se à vontade para perguntar sobre detalhes adicionais e obrigado !! A formatação de perguntas é muito complicada, desculpe lol, então aqui está a versão em texto para o caso de link
A configuração é simples assim (sem lvm, 2 hdds, sem raid):
- & gt; / etc / fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/sda2_crypt / ext4 errors=remount-ro 0 1
# /boot was on /dev/sdc1 during installation
UUID=664ca8af-34b8-4012-ba27-9f48044b6e4e /boot reiserfs notail 0 2
/dev/mapper/sdb1_crypt /media/storage ext4 noatime,sync 0 2
/dev/mapper/sda1_crypt none swap sw 0 0
- & gt; / etc / crypttab
sda1_crypt /dev/sda1 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sda2_crypt UUID=bc4ff5ca-d27a-423b-9ab1-806b64556ace /boot/key luks
sdb1_crypt UUID=85baac75-dae4-4807-98dd-65d17d0c66f4 /boot/key luks
/ dev / sda2 e / dev / sdb1 têm um & apenas Slot0 para autorização / boot / key, o que resulta em:
update-initramfs: Generating /boot/initrd.img-3.8.0-28-generic
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
e sistema não inicializável.
No entanto, ter o sda2 com a única autorização de senha do & amp; s Slot0 funciona com um automount de significado sem falhas durante a inicialização via auth de arquivo de chave luks para / dev / sdb1
- & gt; / etc / crypttab
sda1_crypt /dev/sda1 /dev/urandom cipher=aes-xts-plain64,size=256,swap
sda2_crypt UUID=bc4ff5ca-d27a-423b-9ab1-806b64556ace none luks
sdb1_crypt UUID=85baac75-dae4-4807-98dd-65d17d0c66f4 /boot/key luks
Obter suporte relacionado a essa configuração parece não ser tão fácil, então talvez não seja um bug, porque não tenho certeza sobre os próximos momentos:
1. É necessário ter uma opção de script para usar a autorização luks com base em um arquivo de chave para drive com ponto de montagem em / (root fs)?
A questão apareceu depois de ver / usr / share / initramfs-tools / hooks / cryptroot; lendo o # 13 do link e:
"No entanto, se você deseja usar configurações mais complexas (como root-us-usb-memory), você pode criar um script que execute todas as etapas necessárias para recuperar a chave e imprima-a stdout. " Daqui /usr/share/doc/cryptsetup/README.initramfs.gz
2. Eu "posso criá-lo" ou "must" para montar o rootfs usando o arquivo de chave?
A situação é totalmente incerta para mim, porque:
Por que preciso de um keycript (se eu precisar de um) para / device, mas não para meu / media / storage? Levando em conta a minha configuração com o arquivo de chave para ambos em removível / boot.
Por que preciso do script de chave se estiver claro que a mídia removível / de inicialização com o arquivo de chave está acessível devido ao fato de que / dev / sdb1 finalmente vem como dispositivo mapeado luks montado em seu ponto de montagem de acordo para / etc / fstab?
Se eu não precisar do keycript, por que estou recebendo o aviso do initramfs hook, que verifica se eu tenho um ou não para montar o dispositivo root? (terminando com o sistema não inicializável)
Se acima as coisas estão claramente definidas, eu tenho a última pergunta: isso é um bug ou recurso? Porque ele costumava trabalhar na minha configuração anterior 12.04 como eu estou tentando fazer o trabalho agora em 13.04 recém-instalado, o que significa que algo foi corrigido deixando-me assim ou de outra forma algum recurso (s) foram adicionados.
Extra:
# If keyscript is set, the "key" is just an argument to the script
if [ "$key" != "none" ] && [ -z "$KEYSCRIPT" ]; then
echo "cryptsetup: WARNING: target $target uses a key file, skipped" >&2
return 1
fi
}
Existe apenas para garantir que eu recebo um aviso inútil de acordo com o fato de que é! = nenhum? Desculpe por ser tão noob.