Swap funktioniert nicht bei einer sauberen 14.04-Installation mit verschlüsseltem Heimnetzwerk

28

Update 3:

Ich habe mich dazu entschlossen, das System von Grund auf neu zu installieren, um etwaige herumliegende Krusten zu entfernen, da ich auch nach dem Upgrade einige andere Probleme hatte. Dieses Problem blieb jedoch bestehen.

Bei einer Neuinstallation führt die Auswahl der Installation mit "verschlüsseltes Zuhause" zu einer fehlerhaften verschlüsselten Auslagerungskonfiguration.

Update 2:

Ich habe die Partitionierungsreihenfolge behoben, über die sich cfdisk beschwert hat, aber das Problem bleibt bestehen. Der Swap ist jetzt auf / dev / sda6 und ich kann ihn wie folgt zum Laufen bringen:

~$ sudo mkswap /dev/sda6
Setting up swapspace version 1, size = 7998460 KiB
no label, UUID=18881d0f-d9ec-43be-a23f-0cbd78ea6d22

$sudo nano /etc/crypttab # Update crypttad with new UUID

$ sudo /etc/init.d/cryptdisks reload
 * Stopping remaining crypto disks...
 * cryptswap1 (stopped)...                                               [ OK ] 
 * Starting remaining crypto disks...                                        
 * cryptswap1 (starting)..
 * cryptswap1 (started)...                                               [ OK ] 
$ sudo swapon -a

$ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May 11 09:04 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 11 09:08 18881d0f-d9ec-43be-a23f-0cbd78ea6d22 -> ../../sda6
lrwxrwxrwx 1 root root 10 May 11 09:04 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda5
lrwxrwxrwx 1 root root 10 May 11 09:04 A800B16E00B143DA -> ../../sda1
lrwxrwxrwx 1 root root 10 May 11 09:04 D28230E68230D129 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 11 09:08 fcc8c419-8fec-4d4d-b55e-9e4c3b04d21d -> ../../dm-0

Aber nach einem Neustart lässt sich der Swap nicht aktivieren und sieht wieder so aus:

$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May 11 09:12 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 11 09:12 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda5
lrwxrwxrwx 1 root root 10 May 11 09:12 A800B16E00B143DA -> ../../sda1
lrwxrwxrwx 1 root root 10 May 11 09:12 D28230E68230D129 -> ../../sda2

Ich vermute im Moment, dass beim Einrichten der Festplatte als verschlüsseltes Linux der Partitionstyp nicht mehr erkannt und daher nicht richtig geladen wird, was dazu führt, dass die Partition nicht für ihre UUID registriert wird und Cryptswap den Fehler nicht findet. Aber ich weiß nicht, wie ich das beheben soll.

Aktualisierte Frage:

Weitere Tests ergaben, dass ich den Swap durch Ausführen von $ mkswap / dev / sda5 zum Laufen bringen konnte

und dann aktualisiere ich / etc / crypttab mit der richtigen UUID und folge den hier beschriebenen Schritten: Wie richte ich eine verschlüsselte Auslagerungsdatei ein?

Das Problem bleibt jedoch bestehen, wenn ich den Computer neu starte. Die Datei / dev / sda5 wird bei der Ausführung nicht angezeigt

$ ls -l /dev/disk/by-uuid/

Wenn ich mache:

$ cfdisk /dev/sda 

Ich erhalte folgenden Fehler:

FATAL ERROR: Bad logical partition 6: enlarged logical partitions overlap
                      Press any key to exit cfdisk

Das grafische Dienstprogramm "Disks" beklagt keine Fehler beim Öffnen der Festplatte.

$ sudo fdisk -l

Disk /dev/sda: 256.1 GB, 256060514304 bytes
255 heads, 63 sectors/track, 31130 cylinders, total 500118192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x619aebf1

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848   100870143    50331648    7  HPFS/NTFS/exFAT
/dev/sda3       191397888   192397311      499712   83  Linux
/dev/sda4       192399358   500117503   153859073    5  Extended
/dev/sda5       484118528   500117503     7999488   82  Linux swap / Solaris
/dev/sda6       192399360   484118527   145859584   83  Linux

Partition table entries are not in disk order

Ursprüngliche Frage:

Nach dem Upgrade auf 14.04 (von 13.04) kam es auf meinem Computer zu starken Verlangsamungen. Als ich top lief, bemerkte ich, dass kswap0 viel CPU-Zeit in Anspruch nahm. Mir ist auch aufgefallen, dass ich keinen Swap Space hatte!

$ sudo swapon -a
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory

Es scheint ein Problem mit meinem verschlüsselten Swap-Setup zu geben (wusste nicht einmal, dass ich eines hatte)

$ cat /etc/crypttab 
cryptswap1 UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May  6 11:00 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3
lrwxrwxrwx 1 root root 10 May  6 11:00 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda6
lrwxrwxrwx 1 root root 10 May  6 11:00 A800B16E00B143DA -> ../../sda1
lrwxrwxrwx 1 root root 10 May  6 11:00 D28230E68230D129 -> ../../sda2

Und schau auf meine fstab

$ 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/sda6 during installation
UUID=19aa372c-05c8-4226-8f09-c54e5566e816 /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda3 during installation
UUID=08b07f88-6da5-4b40-b062-42b3bb1c5f00 /boot           ext2    defaults        0       2
# swap was on /dev/sda5 during installation
#UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 none            swap    sw              0       0
/dev/mapper/cryptswap1 none swap sw 0 0

Ich vermute, dass beim Setup von sda5 etwas nicht stimmt, aber ich weiß nicht, wie ich es beheben soll, da es für die Verschlüsselung eingerichtet ist. Würde mich über Hilfe bei der weiteren Vorgehensweise freuen.

Ajn
quelle
Ich weiß nichts über verschlüsselte Partitionen, aber dieser erste Fehler deutet darauf hin, dass die Swap-Partition nicht bereitgestellt wurde. Auch die Montagezeile dafür in der / etc / fstab ist auskommentiert. Ich würde nur versuchen, diese Zeile zu
dekommentieren
Ich bin mir ziemlich sicher, dass es auskommentiert werden soll, und die Zeile cryptswap1 ist dafür verantwortlich, es indirekt mithilfe der Informationen in / etc / crypttab zu mounten. Ihr Vorschlag würde es sicherlich unverschlüsselt einhängen?
AJN
1
Ob das funktioniert? https://ubuntuforums.org/showthread.php?t=2224129 Ich bin mir bei einigen Befehlen unsicher und möchte Ubuntu nicht vermasseln.
Es sieht ähnlich aus wie das, was ich versucht habe. Ich würde erwarten, dass es für einen Neustart funktioniert und dann nicht mehr funktioniert, sobald Sie den verschlüsselten Swap zum ersten Mal aktiviert haben.
AJN
Im Moment habe ich mich wieder dem regulären Tausch verschrieben. Das Hauptszenario, gegen das ich Verschlüsselung verwende, ist, wenn jemand meinen Laptop stiehlt und jemand mit mäßigen Linux-Kenntnissen sich entscheidet, um zu sehen, ob er etwas Interessantes findet. Ich habe nichts, von dem ich glaube, dass es jemand wertvoll genug finden würde, um zu versuchen, Fragmente davon aus dem Swap wiederzugewinnen. Es sollte wirklich eine Installationsoption sein, um verschlüsseltes Zuhause + regulären Austausch zu verwenden.
AJN

Antworten:

16

Bekannter Bug

Es gibt einen Fehler (siehe unten), der UUIDdie Partition überschreibt, sobald Daten darauf geschrieben werden. Aus diesem Grund können Sie die nicht verwenden, UUIDum auf die Partition zu verweisen, die für den verschlüsselten Austausch verwendet werden soll.

Swap Space wird heutzutage kaum noch genutzt. Auf meinem Computer wird Swap nur verwendet, wenn ich meinen 40. Tab öffne. Wenn ich keinen Swap habe, kommt mein Computer plötzlich zum Stillstand und der Browser schließt sich von selbst. Oder im Fall des ChromiumBrowsers "sterben" plötzlich viele Registerkarten.
Aus diesem Grund scheint die Referenzierung /dev/disk/by-uuid/in Ihrem /etc/crypttabSystem eine Weile zu funktionieren. Sobald jedoch der Swap-Bereich tatsächlich verwendet wird, wird der überschrieben, da die gesamte Partition für die verschlüsselte Datenspeicherung verwendet wird.UUID

Einfache Lösung

Die einfache Lösung besteht darin, die Swap-Partition nach Gerät in Ihrem Verzeichnis zu referenzieren /etc/crypttab, z. B .:

cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

Warnung: Dies ist wahrscheinlich auf einem Laptop sicher (ich benutze es so), aber wenn Sie sich auf einem Desktop mit austauschbaren Laufwerken befinden oder andere Gründe für das Ändern des Laufwerk- / Partitionslayouts haben, möchten Sie dies nicht tun Die normale Speicherpartition wird möglicherweise plötzlich zum Auslagern verwendet.

Hinweis: Sie müssen neu starten, damit diese Änderung wirksam wird, da nur beim Booten /dev/mapper/cryptswap1erstellt wird.

Richtige Lösung

Der richtige Weg, dies zu beheben, besteht darin, sicherzustellen, dass der Teil der Raw-Partition, in der die UUIDDaten gespeichert sind, nicht durch verschlüsselte Auslagerungsdaten überschrieben wird, sodass sie beim Neustart weiterhin vorhanden sind. Ich bin mir jedoch nicht sicher, wo das UUIDsteht und wie viel Bytes es benötigt. Sie können es auf eigenes Risiko folgendermaßen testen:

cryptswap1 UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 /dev/urandom swap,offset=36,cipher=aes-cbc-essiv:sha256

Beachten Sie die offset=36.

Wenn Sie ein Ubuntu One- Konto haben, melden Sie sich an und gehen Sie auf dem Launchpad zu Bug # 1310058 und wählen Sie (oder klicken Sie hier): "Dieser Bug betrifft mich auch", damit der Bug an Popularität gewinnt und häufiger behoben wird.


Update 27.10.2014

Ich bin auch darauf gestoßen. Nicht von mir verifiziert. Es sieht aus wie ein offsetTrick mit mehr Ausführlichkeit und Kommentaren zum Wiederaufbau eines kaputten Swap.

https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22

Redsandro
quelle
5
Ich möchte nur bemerken, dass der Fehler unter bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875 verfolgt wird, da der Status vor ein paar Tagen (Mitte März 2015) "behoben veröffentlicht" ist Dieser Fix gilt nur explizit für den 15.04. Ich schaue, ob es auf 14.04 LTS zurückportiert wird ... und wie das "offizielle" Update-Verfahren aussehen könnte
Tommy Trussell
1
@TommyTrussell: Kein Backport wäre verrückt nach LTS. Bugs für wichtige Dinge wie dieses sind noch fast ein Jahr nach der Veröffentlichung offen, weshalb selbst die großen Linux-Distributionen niemals mit OSX und Windows mithalten können. Unglücklicherweise.
Redsandro
Mir ist keine öffentliche Diskussion über Fehler bekannt, da diese in OSX und Windows behoben werden. Wie können sie also "auf Augenhöhe" sein? Nach meiner Erfahrung mit OSX werden Fehler behoben oder nicht. Keine öffentliche Diskussion, daher sind sie "undurchsichtig". Ich habe nur die neue Fehlernummer erwähnt (weil die, die Sie verlinkt haben, doppelt markiert wurde), damit Sie Ihre Referenz aktualisieren können. Wie Sie aus der Diskussion im Forum sehen können, das in Bug 953875 erwähnt wird, kann sich die stabilste Korrektur je nach dem Init-System unterscheiden, das in 15.04 geändert wird. SO kann der 14.04-Fix technische Herausforderungen für die Aufwärtskompatibilität haben.
Tommy Trussell
Ich sage nur, Sie werden auf einem System wie Windows oder OSX niemals so etwas wie "Oh, übrigens, SWAP ist kaputt" sehen . Dies ist die Art von Kernfunktionalität, die RTM niemals erhalten würde, bevor sie nicht getestet und behoben wurde. Das ist alles. Aus Sicherheitsgründen keine öffentlichen Diskussionen, aber es gibt immer noch Statistiken .
Redsandro
@Redsandro Nun, es ist ein freies Betriebssystem und solche Dinge werden erst vor der Veröffentlichung behoben, wenn die Leute den Fehler beim Testen der Veröffentlichung entdecken. Nach der Veröffentlichung ist es einfach zu riskant, dass das Beheben des Fehlers die Konfiguration anderer Personen beeinträchtigt. Es kann jedoch in einer neueren Version behoben werden - es kann sich also lohnen, diese zu verwenden -, aber Zwischenversionen sind normalerweise instabiler als LTS-Versionen, da der Schwerpunkt eher auf allgemeinen Updates liegt. Aber Sie haben herausgefunden, warum das Testen / Beheben von Fehlern / Qualitätssicherung (QS) so wichtig ist und Ubuntu dabei immer besser wird.
Ads20000
9

Ich hatte genau das gleiche Problem in Ubuntu 14.04 und bin auf diesen Thread gestoßen; Dieser Link , den der Mutant zur Verfügung stellte, funktionierte gut für mich. Ich habe die /dev/disk/by-idReferenz anstelle von / dev / sdXY verwendet, da diese Referenz nicht immer auf dieselbe physische Partition verweist. Meine /etc/crypttabendete wie:

cryptswap1 /dev/disk/by-id/wwn-0x500...-part6 /dev/urandom swap, cipher=aes-cbc-essiv:sha256
DoubleE
quelle
3
Dies ist die richtige und einfache Lösung!
Serge Stroobandt
7

Verwenden Sie einfach einen unverschlüsselten Swap

... und zu Hause verschlüsselt bleiben

Ich habe einige der anderen hier vorgeschlagenen Lösungen ausprobiert. Obwohl sie nach einem Warmstart weiter arbeiteten, scheiterten sie schließlich alle nach einem Herunterfahren und einem Kaltstart.

Dies sagt uns, dass wir es tatsächlich mit einem doppelten Fehler zu tun haben:

  1. Die UUID des Swap-Laufwerks wird vom Verschlüsselungssystem überschrieben
  2. Beim Booten tritt ein Timeout-Problem auf.

Diese Überlegungen spiegeln sich auch in den Kommentaren zum entsprechenden Fehler wider, der bei Launchpad abgelegt wurde . Mit der bevorstehenden Umstellung von Upstart auf systemd wird jedoch nur wenig getan, um den Fehler auf aktuellen LTS-Systemen zu beheben.

An diesem Punkt kamen mir folgende Gedanken:

  1. Während der Systeminstallation habe ich darum gebeten, nur meine \homePartition zu verschlüsseln , sonst nichts.
  2. Das Risiko, keine verschlüsselte Swap-Partition zu haben, ist eher begrenzt.
  3. Es liegt an Canonical, ihre Tat zu bereinigen. Ich werde keine Zeit mehr damit verschwenden.

Hier ist meine Lösung, um den Swap als normalen, unverschlüsselten Swap wiederherzustellen, ohne das gesamte Betriebssystem neu installieren zu müssen.

  1. Wenn Sie dies noch nicht getan haben, installieren Sie blkid:$ sudo apt-get install blkid
  2. Bearbeiten /etc/crypttabund löschen Sie die gesamte cryptswap1Zeile:$ sudo nano /etc/crypttab
  3. Starten Sie GParted über das Systemeinstellungsmenü.
  4. Sie sehen eine Partition mit einem Ausrufezeichen. Dies sollte die fehlerhafte Swap-Partition sein. Wählen Sie es sorgfältig aus und formatieren Sie es in eine linux-swapPartition. Nachdem Sie diesen Vorgang angewendet haben, werden Sie über die neue UUID der wiederhergestellten normalen Swap-Partition informiert. Sie haben die Möglichkeit, diese Informationen zu speichern. Ist dies nicht der Fall, können Sie die neue UUID jederzeit über die Befehlszeile abrufen blkid:$ sudo blkid
  5. Jetzt ist es Zeit, wieder /etc/fstabzu alter Pracht zu kommen:$ sudo nano /etc/fstab

    • Entfernen Sie die gesamte Zeile mit einem Verweis auf /dev/mapper/cryptswap1.
    • Kommentieren Sie die alte swapZeile aus, indem Sie den Hash #vor entfernen UUID=....
    • Ersetzen Sie nun die alte UUID durch die zuvor erhaltene neue.
    • Schreiben Sie die Datei durch Drücken von Ctrl+ aus O und beenden Sie sie nanomit Ctrl+ X.
  6. Sobald dies alles erledigt ist, können Sie den neuen unverschlüsselten Swap bereits jetzt verwenden mit: $ sudo swapon -a
  7. Diese Lösung übersteht sowohl einen Warmstart als auch ein Herunterfahren mit einem Kaltstart.
Serge Stroobandt
quelle
1
Dies ist die einzige Antwort, die für mich funktioniert hat, obwohl ich alles andere ausprobiert habe.
Fifaltra
In gparted hat meine Swap-Partition das Boot-Flag. Funktioniert das noch oder kann ich nicht mehr hochfahren?
Christian Skjødt
@ ChristianSkjødt Auf Ihrer Swap-Partition sollte das Boot-Flag nicht gesetzt sein. Wie auch immer, das obige Verfahren würde nichts davon beeinflussen.
Serge Stroobandt
2

Werfen Sie einen Blick auf diese . Ich habe dieses Problem durch einfaches Ersetzen von UUID = ... durch / dev / sda3 in / etc / crypttab behoben.

Mutant
quelle
1
Führen Sie zuerst "sudo fdisk -l" aus, um zu überprüfen, wie Ihre Swap-Partition heißt. Es kann sich um "/ etc / sda5" oder eine andere Partition handeln. Bearbeiten Sie dann Cryptab wie von mutant beschrieben. Das hat bei mir geklappt und übersteht einen Neustart. Dies ist definitiv ein Fehler, da ich dieses Problem bei einer Neuinstallation auf einer neuen SSD habe. Ich habe bei der Installation die Option "Heimatverzeichnis verschlüsseln" gewählt, viel besser, um / home nach der Installation zu verschlüsseln, insbesondere, wenn Sie Dateien von einem alten / Heimatverzeichnis aus einer früheren Installation kopieren.
Paul Williams
Das sudo fdisk -lwar etwas, was niemand sagte. Danke dafür! :)
Aman Alam
Sie sollten zumindest die Leute warnen, dass sich /dev/sd*Pfade nach Belieben ändern können und die falsche Partition durch den Datenaustausch zerstört wird. /dev/disk/by-idist überlegen.
underscore_d
0

Ich habe dieses Problem, genauso wie die fraglichen Leute 332625 . Bei einer Kombination aus Anhalten und Neustarten geht die UUID Ihrer Swap-Partition verloren (wie der Kommentar in Ihrer / etc / fstab besagt, bestätigen Sie dies mit sudo blkd), sodass die Zeile in Ihrer / etc / crypttab, in der diese UUID als verschlüsselter Swap verwendet wird, fehlschlägt.

Ich habe kein Glück, wenn ich / etc / crypttab wechsle , um den /devNamen der Partition ( in Ihrem Fall / dev / sda6 ) oder den dev/disk/by-id/Namen anstelle der verschwindenden UUID zu verwenden.

Das Aufgeben des verschlüsselten Austauschs ist leider die einfachste und bislang beste Lösung.

Skiseite
quelle
Dieses Problem ist sehr alt Ich frage mich, warum sie es nicht bereits behoben haben. Jetzt habe ich das gleiche Problem mit meinem Desktop und kann es nicht mehr zum Laufen bringen. Ich habe es in der Vergangenheit auf meinem Laptop behoben, kann mich aber nicht erinnern, wie :(
Tomasb