Resposta curta:
Problema do UUID:
Você deve ter isso em /etc/crypttab :
cryptswap1 /dev/sda4 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
e esta linha no final de /etc/fstab
/dev/mapper/cryptswap1 none swap sw 0 0
Certifique-se de não usar o uuid no arquivo cryptab.
Suspender problema:
Agora vamos usar um truque para normalizar o comportamento da troca logo antes de reiniciar ou desligar:
Crie um script /etc/init.d/cryptswap.sh com este conteúdo:
#!/bin/bash
/etc/init.d/cryptdisks-early restart
Torne-o executável com:
sudo chmod +x /etc/init.d/cryptswap.sh
Para fazer as coisas corretamente, vamos usar links e números para que sejam executados no momento certo, seja para reinicialização ou desligamento:
cd /etc/rc6.d
sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh
cd /etc/rc0.d
sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh
O importante aqui é o número 10 no nome porque o script deve ser executado antes do S40, que começa a fazer o swap; mais tarde, outro script removerá os dispositivos criptografados. O ponto é que a sequência original falha e precisamos da reinicialização para deixá-la passar sem problemas.
É isso aí!
Nota: este é um hack sujo, e pode acontecer que o reinício não seja capaz de consertar o que está acontecendo às vezes. Alguém entre os desenvolvedores responsáveis por swap e / ou cryptsetup deve ir fundo e ver por que, após a suspensão, a troca é deixada em um estado que faz com que swapoff /dev/mapper/cryptswap1 e /etc/init.d/cryptdisks-early stop falhem. Se você executar esses comandos, verá o swapoff reclamar sobre o cabeçalho do swapfile. Além disso, você verá cryptdisks-early enviando uma "falha" ao tentar parar /dev/mapper/cryptswap1 .
Redundância / histórico:
No começo eu pensei que o problema dele estava ligado ao comportamento do kernel pelo libblk, provavelmente um bug (não intencional). Parece que o problema é ter uma tabela de partições editada por diferentes "sistemas de arquivos". O kernel se recusa a preencher /dev/disk/by-uuid/ porque detecta várias assinaturas de sistemas de arquivos editando a tabela de partições. Isso pareceu importante, pois o script /usr/bin/ecryptfs-setup-swap usa o UUID para referenciar entradas que cria para /etc/crypttab .
A correção deve ser para recriar todas as partições do mesmo sistema de arquivos, inicializando em alguma mídia ao vivo. Veja: link
No entanto, isso não funciona porque o ecryptfs / crypttab "reformata" a partição de troca em cada inicialização; você não pode ver um uuid para a partição swap depois de executar o ecryptfs-setup-swap e reiniciar, porque você não deveria. Isso significa que, após a inicialização, a partição não será encontrada pelo crypttab se referenciada pelo uuid, como declarado na outra resposta.
Continuando, uma possível solução foi desistir do uso de uuids e apenas substituí-los em / etc / crypttab com uma notação diferente: somente / dev / sdXX funciona porque os outros são perdidos quando o mkswap é executado nos scripts do crypttab. É assim que os fóruns sugerem para resolver o problema. Isso é necessário.
Isso não funcionou totalmente embora. Eu especulei que havia algum bug no crypttab ( /etc/rcS.d/S26cryptdisks-early - > /etc/init.d/cryptdisks-early - > /lib/cryptsetup/cryptdisks.functions ). Então eu fui cavar lá e não encontrei nada. Na verdade, executar /etc/init.d/cryptdisks-early restart funciona bem, uma vez inicializado, o link /dev/mapper/cryptswap1 é gerado.
Uma correção possível que vi naquele momento, foi mover o swap para um "arquivo" que ocupa todo o espaço na partição swap. Isso é sujo, requer um ponto de montagem, etc. A idéia é que você criaria um arquivo do tamanho da partição inteira, que seria montado como um ext4 regular em say / swap, e o uso do arquivo criptografado como swap. Algo parecido com isto:
-
No formato GParted como ext4; observe que isso formatará a partição e gerará um novo UUID; não use sudo mkswap /dev/sdXX , pois a partição será montada automaticamente se marcada como swap
-
sudo mkdir /swap
-
ls -l /dev/disk/by-uuid/
-
sudo gedit /etc/fstab # adicionar UUID=XXXXXXXXXXXXXXXXXXXXXXXXX /swap ext4 defaults 0 2
-
sudo mount /dev/sdXX /swap
-
sudo dd if=/dev/zero of=/swap/swapfile bs=1024 count=800000
-
sudo mkswap /swap/swapfile
-
sudo swapon /swap/swapfile
-
sudo ecryptfs-setup-swap
Mas eu odiava, então eu não tentei isso.
Outra possível correção que vi foi configurar manualmente, desistindo da geração automatizada de chaves aleatórias, assim: link
Depois de explorar um pouco o local do manual, de alguma forma eu consertei as coisas fazendo o que o /usr/bin/ecryptfs-setup-swap faz primeiro (confira para ver como funciona, apenas edite /etc/crypttab e /etc/fstab ) e execute manualmente o script que são executados na inicialização: /etc/init.d/cryptdisks-early restart ; Mas isso quebrou novamente. Repensando sobre a questão do currículo, encontrei o padrão. Ele quebra no reboot que segue uma suspensão e fica quebrado. Para refixá-lo, é preciso fazer um:
sudo /etc/init.d/cryptdisks-early restart
Depois disso, o swap é montado com sucesso e sem desperdício, desde que você não suspenda. É aqui que o roteiro proposto na resposta curta vem.