Ich hatte das gleiche Problem beim Versuch, meinen verschlüsselten Swap-Bereich einzurichten, und denke, ich bin zu einer Lösung gekommen. Um hier zu beginnen, hier ein paar Links, die ich in meiner Forschung verwendet habe:
- Einfache Anleitung zum Verschlüsseln des Swap Space mit ecryptfs (wenn alles richtig funktioniert)
- Debuggen eines Blogposts, der ein sehr ähnliches Problem ausführlich debuggt. Ich habe viele meiner Ideen von hier bekommen, daher würde ich empfehlen, sie zu lesen.
Problemeinrichtung
Beim ecryptfs-setup-swapersten Ausführen (beachten Sie, dass ich bei der Installation bereits einen Swap-Bereich eingerichtet hatte, sodass ich dies nicht tun musste, wurde die mkswapFehlermeldung angezeigt, dass der Swap-Bereich nicht ordnungsgemäß bereitgestellt werden konnte.
$ 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
Ich habe versucht, den Befehl erneut auszuführen, und eine Meldung erhalten, dass ich keinen Swap Space mehr habe.
$ 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
Wenn Sie die Fehlermeldung aus der ersten Ausführung des Befehls ecrypt überprüfen, /dev/mapper/cryptswap1scheint sie nicht vorhanden zu sein.
$ ls /dev/mapper/
control
Untersuchung relevanter Systemdateien
Basierend auf dem zuvor erwähnten Blog- Beitrag habe ich beschlossen, in meinen Systemdateien nach Beweisen zu suchen, warum der Swap-Bereich nicht identifiziert wurde. Der Blog erwähnt, dass die geänderten Benennungsschemata von Festplattenpartitionen Probleme für ecryptfs verursachen und dass die Umstellung auf die Verwendung einer UUID-basierten Kennung konsistenter ist.
$ 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"
Beachten Sie, dass mein Swap Space /dev/nvme0n1p5die UUID ist und hat aea96d7f.... Jetzt werde ich einen Blick darauf werfen /etc/fstabund /etc/crypttabsehen, wie die Swap-Konfiguration aussieht.
$ 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
Es gibt ein paar Dinge, die es wert sind, hier erwähnt zu werden, also werde ich sie einzeln durchgehen.
- ecryptfs scheint meine ordnungsgemäß geändert zu haben
fstab, um meinen alten Swap-Bereich ( auskommentierte Zeile mit der Swap-UUID) zu deaktivieren und den verschlüsselten zu aktivieren.
- Das Crypttab wird mit der entsprechenden UUID eingerichtet, um es meinem Swap Space zuzuordnen. Dies ist eine große Sache. Wenn Ihr Crypttab nicht nur mit einer UUID (z. B. dem Namen des Laufwerks in / dev) eingerichtet ist, kann der Kernel das Laufwerk möglicherweise umbenennen und Probleme verursachen (weitere Informationen finden Sie im Blog ). In meinem Fall scheint ecryptfs den Eintrag mithilfe einer UUID ordnungsgemäß eingerichtet zu haben (ich vermute, dass er am 16.04 gepatcht wurde, da der Blog das Problem am 14.04 erwähnt).
- Das Crypttab gibt einen Offset für das Laufwerk an. Auch dies ist ein subtiles "Gotcha", das im Blog erwähnt wird. Wenn der Offset jedoch nicht vorhanden ist, kann dies anscheinend dazu führen, dass Ihr Laufwerk seine UUID verliert, da es verschlüsselt wird.
Schließlich habe ich überprüft swapon, ob ein Swap Space gefunden wurde.
$ swapon -s
Filename Type Size Used Priority
/dev/dm-0 partition 31248892 0 -1
Es sieht so aus, als würde es auf einen Swap-Bereich (mit der richtigen Größe) verweisen, aber dieser Swap-Bereich wird darin nicht ordnungsgemäß eingerichtet /dev/mapper(wie von fstab angegeben).
Lösung
Nach den Vorschlägen im Blog-Beitrag habe ich mich entschlossen, zu prüfen, ob ein einfacher Neustart des cryptdisksDienstes das Problem lösen würde.
$ 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
An diesem Punkt scheint mein Swap Space richtig konfiguriert zu sein. Beim Ausführen htopwird die entsprechende Menge an Swap-Speicherplatz angezeigt, und die oben verwendeten Diagnosebefehle werden alle positiv angezeigt, insbesondere blkidjetzt /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"
Die Einstellungen blieben während des Neustarts erhalten und alles scheint in Ordnung zu sein. Soweit ich das beurteilen kann, hat dies funktioniert. Hoffentlich hilft das.
Mögliche alternative Lösung
Um sicherzustellen, dass meine Antwort ordnungsgemäß funktioniert, habe ich versucht, das Problem auf einer EC2-Instanz zu replizieren. Ich hatte das gleiche Verhalten beim Ausführen, sudo ecryptfs-setup-swapbei dem beim Ausführen ein Fehler auftreten würde swappon. Aus irgendeinem Grund /dev/dm-0schien die Gerätezuordnung jedoch nicht richtig eingerichtet zu sein. Die /etcDateien schienen in Ordnung zu sein, also habe ich versucht, die Instanz einfach neu zu starten. Dies schien gut zu funktionieren; Ich würde jedoch empfehlen, vor dem Neustart zumindest die entsprechenden Konfigurationseinstellungen zu überprüfen, um sicherzustellen, dass sie korrekt eingerichtet sind, damit der Kernel den Swap beim Neustart bereitstellen kann.
swapon -abekomme ichswapon: stat of /dev/mapper/cryptswap1 failed: No such file or directory