Eu tive o mesmo problema ao tentar configurar o meu espaço de troca criptografado e acho que cheguei a uma solução. Para começar, aqui estão alguns links que usei na minha pesquisa:
- Simple How-To criptografar espaço de troca com o ecryptfs (quando tudo funciona bem)
- Publicação de Debugging no Blog que depura um problema muito semelhante em profundidade. Eu tenho muitas das minhas ideias daqui, então eu recomendo dar uma lida.
Configuração do problema
Quando eu corri ecryptfs-setup-swap pela primeira vez (note que eu já tinha configurado o espaço de troca quando eu instalei, então eu não precisei fazer o mkswap , recebi uma mensagem de erro dizendo que o espaço de swap não ser montado corretamente.
$ sudo ecryptfs-setup-swap
[sudo] password for isaac:
WARNING:
An encrypted swap is required to help ensure that encrypted files are not leaked to disk in an unencrypted format.
HOWEVER, THE SWAP ENCRYPTION CONFIGURATION PRODUCED BY THIS PROGRAM WILL BREAK HIBERNATE/RESUME ON THIS SYSTEM!
NOTE: Your suspend/resume capabilities will not be affected.
Do you want to proceed with encrypting your swap? [y/N]: y
INFO: Setting up swap: [/dev/nvme0n1p5]
WARNING: Commented out your unencrypted swap from /etc/fstab
marking GPT swap partition /dev/nvme0n1p5 as no-auto...
swapon: stat of /dev/mapper/cryptswap1 failed: No such file or directory
Eu tentei executar o comando novamente e recebi uma mensagem dizendo que eu não tinha mais espaço para swap.
$ sudo ecryptfs-setup-swap
INFO: You do not currently have any swap space defined.
You can create a swap file by doing:
$ sudo dd if=/dev/zero of=/swapfile count=130667600
$ sudo mkswap /swapfile
$ sudo swapon /swapfile
And then re-run /usr/bin/ecryptfs-setup-swap
Verificando novamente a mensagem de erro da primeira execução do comando ecrypt, parece que /dev/mapper/cryptswap1 não existe.
$ ls /dev/mapper/
control
Investigando arquivos relevantes do sistema
Com base no post anterior blog , decidi Comecei a procurar em meus arquivos de sistema por evidências de porque o espaço de swap não estava sendo identificado. O blog menciona que os esquemas de nomeação modificados das partições do disco rígido causam problemas para o ecryptfs e que a mudança para o uso de um identificador baseado em UUID é mais consistente.
$ blkid
/dev/nvme0n1p5: UUID="aea96d7f-e091-460b-95fd-a34ab884d440" TYPE="swap" PARTUUID="0a7db4e0-17bf-40e3-8675-afec7891afc5"
/dev/nvme0n1p1: LABEL="ESP" UUID="C291-E533" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="63fc7fb9-2ca5-422b-90c7-0db698acdb3c"
/dev/nvme0n1p3: UUID="16F4C1EEF4C1D063" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="c04d0838-5570-4bfc-a961-4b9224b8cc0c"
/dev/nvme0n1p4: UUID="0EEE7736EE7714E5" TYPE="ntfs" PARTUUID="4dc6595f-cc9c-4d80-99ab-ffd9cbe3c1d7"
/dev/nvme0n1p6: UUID="8b2f5c94-db79-4c8d-b5c6-403d912bc0dd" TYPE="ext4" PARTUUID="e373c83f-f992-4e62-a235-1fdd01ac7cf0"
Observe que meu espaço de troca é /dev/nvme0n1p5 e tem o UUID aea96d7f... . Agora vou dar uma olhada em /etc/fstab e /etc/crypttab para ver como é a configuração da troca.
$ cat /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>
# / was on /dev/nvme0n1p6 during installation
UUID=8b2f5c94-db79-4c8d-b5c6-403d912bc0dd / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=C291-E533 /boot/efi vfat umask=0077 0 1
# swap was on /dev/nvme0n1p5 during installation
#UUID=aea96d7f-e091-460b-95fd-a34ab884d440 none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw 0 0
$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
cryptswap1 UUID=aea96d7f-e091-460b-95fd-a34ab884d440 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64
Há algumas coisas que vale a pena notar aqui, então eu vou passar por elas uma de cada vez.
- O ecryptfs parece ter modificado corretamente meu
fstabpara desativar meu antigo espaço de troca (comentou a linha com o UUID de troca) e ativar o criptografado. - O crypttab é configurado com o UUID apropriado para mapear para o meu espaço de troca. Isso é um grande problema, se o seu crypttab é configurado com algo além de um UUID (digamos, o nome da unidade em / dev), é possível que o kernel renomeie a unidade e cause problemas (novamente, veja o blog para detalhes). No meu caso, o ecryptfs parece ter configurado a entrada corretamente usando um UUID (meu palpite é que ele é corrigido em 16.04, já que o blog menciona o problema em 14.04).
- O crypttab especifica um deslocamento para o inversor. Mais uma vez, este é um "pegadinha" sutil mencionado no blog, mas se o deslocamento não estiver presente, ele pode aparentemente fazer com que seu disco perca seu UUID porque ele será criptografado.
Por fim, verifiquei swapon para ver se está encontrando algum espaço de troca.
$ swapon -s
Filename Type Size Used Priority
/dev/dm-0 partition 31248892 0 -1
Parece que está apontando para um espaço de troca (do tamanho correto), mas esse espaço de troca não está sendo configurado corretamente em /dev/mapper (como referenciado por fstab).
Solução
Seguindo as sugestões na postagem do blog, decidi verificar se simplesmente reiniciar o serviço cryptdisks resolveria o problema.
$ swapoff -a
$ /etc/init.d/cryptdisks start
$ swapon -a
$ swapon -s
Filename Type Size Used Priority
/dev/dm-0 partition 31248892 0 -1
$ ls -l /dev/mapper/
total 0
crw------- 1 root root 10, 236 Jan 9 11:30 control
lrwxrwxrwx 1 root root 7 Jan 9 12:28 cryptswap1 -> ../dm-0
Neste ponto, parece que meu espaço de troca está configurado corretamente. A execução de htop mostra a quantidade adequada de espaço de troca e os comandos de diagnóstico que eu estava usando acima estão todos saindo positivos, principalmente blkid agora mostra /dev/mapper/cryptswap1 .
$ sudo blkid
/dev/nvme0n1p1: LABEL="ESP" UUID="C291-E533" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="63fc7fb9-2ca5-422b-90c7-0db698acdb3c"
/dev/nvme0n1p3: UUID="16F4C1EEF4C1D063" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="c04d0838-5570-4bfc-a961-4b9224b8cc0c"
/dev/nvme0n1p4: UUID="0EEE7736EE7714E5" TYPE="ntfs" PARTUUID="4dc6595f-cc9c-4d80-99ab-ffd9cbe3c1d7"
/dev/nvme0n1p5: UUID="aea96d7f-e091-460b-95fd-a34ab884d440" TYPE="swap" PARTUUID="0a7db4e0-17bf-40e3-8675-afec7891afc5"
/dev/nvme0n1p6: UUID="8b2f5c94-db79-4c8d-b5c6-403d912bc0dd" TYPE="ext4" PARTUUID="e373c83f-f992-4e62-a235-1fdd01ac7cf0"
/dev/mapper/cryptswap1: UUID="113abaa7-c122-4d47-a826-181ee6a29627" TYPE="swap"
As configurações persistiram durante a reinicialização e tudo parece estar funcionando bem, então, até onde eu sei, isso funcionou. Espero que isso ajude.
Solução alternativa potencial
Para garantir que minha resposta estava funcionando adequadamente, tentei replicar o problema em uma instância do EC2. Eu tive o mesmo comportamento em que executava sudo ecryptfs-setup-swap onde seria erro tentar executar swappon . No entanto, por algum motivo, o mapeamento de dispositivo /dev/dm-0 não parece estar configurado corretamente. Os arquivos /etc pareciam estar ok, então tentei simplesmente reinicializar a instância. Isso pareceu funcionar muito bem; no entanto, eu recomendo pelo menos inspecionar as configurações apropriadas antes de reinicializar para ter certeza de que elas estão configuradas corretamente para que o kernel possa montar a troca quando você reiniciar.