Ubuntu 17.04 Swap Bug

Kaum installiere ich Ubuntu mal neu und schon stoße ich auf einen blöden Bug.

Dieser Fehler im neuen Ubuntu 17.04 wäre mir vielleicht gar nicht aufgefallen, wenn ich ältere Hardware genutzt hätte. Aber dieses Ubuntu läuft auf ein nigelnagelneuen Intel NUC Mini Rechner. Der hat DDR4 und eine SSD und da erwartet man kein gestartetes System erst nach über einer Minute. Vor allem war schon der Live Ubuntu USB-Stick wesentlich schneller.

Wer die Vorgeschichte überspringen möchte kann gleich zur Problemlösung bei verschlüsseltem Home Verzeichnis springen.

Nach Recherche stellte sich heraus das es auf jeden Fall etwas mit den eingebunden Partitionen zu tun hat. Es gibt aber mehrere Auslöser die so ein Verhalten erzeugen können. Wer Ubuntu beim Systemstart über die Schulter guckt und den Ladebildschirm gegen die Konsole austauscht, wird eventuell einen Meldung sehen, welche den Systemstart um 1 Minute und 30 Sekunde verzögert: (1 of 2) A start job is running for dev-...

Wer im Internet sucht findet schnell gute Ansätze. Beispielsweise bei Ubuntuusers. Dabei geht es in Richtung der Konfigurationsdatei fstab im Verzeichnis /etc/ welche für das Einhängen der Partitionen alle Informationen bereitstellt. Hier sollten heutzutage für die Partitionsbezeichnungen nur noch sogenannte UUIDs verwendet werden und die können wohl unter Umständen falsch sein. Das kommt aber eher bei bestehenden Systemen vor, aber nicht wie bei mir, mit einer Neuinstalltion.

Dennoch habe ich diese Datei geöffnet und mit den Werten, die der Befehl blkid bereitstellt verglichen. Der Befehl blkid zeigt unter anderem die jetzt aktuellen UUIDs der eingebunden Speichermedien an.

Hinweis: Wer systemnahe Dateien verändern möchte, sollte davor gleich eine Kopie abspeichern. Am besten mit der Endung .bak für Backup. 

Sollte es notwendig werden Systemdateien anzupassen, müssen diese mit Rootrechten aufgerufen werden.

Mit Terminaleditor Nano:

sudo nano /etc/fstab

Oder mit dem Gnome Editor:

sudo gedit /etc/fstab  

Nun mit einem extra Terminalfenster die eigentlichen Werte der angeschlossenen Speichermedien auslesen:

sudo blkid 

Stimmen die UUIDs tatsächlich nicht überein, sollten diese korrigiert werden. Das könnte dann schon für viele die Problemlösung gewesen sein.

Nur nicht bei mir...

Zur Problemlösung bei verschlüsseltem Home Verzeichnis

Wenn dies noch nicht der Fall ist und man weiß das bei der Installation die Verschlüsselungsoption gewählt wurde, dann wird man bei Ubuntu 17.04 zum Opfer eines Bugs geworden sein. Dieser ist auch schon gemeldet und wird hoffentlich in den nächsten Versionen nicht noch mal auftreten. Dort gibt es aber auch schon Lösungen.

Das Problem ist die neue Swap Datei, die bei Ubuntu 17.04 nun standardmäßig angelegt wird bzw. deren Verschlüsselung. Ähnlich wie bei Windows gibt es nun eine Auslagerungsdatei und nicht wie sonst bei den meisten Linux Distributionen üblich, eine Swap Partition. Das Problem führt uns von der fstab Datei weg. Denn dort steht für die Swap Datei (/swapfile) logischerweise keine UUID und das ist richtig. Die nächste Zeile darin führt uns aber zu einer Konfigurationsdatei die für die Verschlüsselung dieser Auslagerungsdatei zuständig ist. Diese nennt sich crypttab und befindet sich im selben Vezeichnis.

Folgendes wird drin stehen:

cryptswap1 UUID=XXXXXXX-XXXXXX-XXX /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

Und diese Zeile ist falsch. Weil das neue Ubuntu keine Swap Partition mehr erstellt kann die UUID nicht funktionieren. Folgende Änderung muss nach aktuellen Stand drin stehen:

cryptswap1 /swapfile /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

Erst dann kann das System die Swap Datei beim Booten verschlüsselt einbinden und es kommt zu keiner Verzögerung. Dies lässt sich mit der Systemüberwachung schnell überprüfen. Dort muss das Swapfile beim nächsten Startvorgang erkannt werden. Wenn nicht bleibt die Stelle weiterhin ausgegraut.

UPDATE 20.10.2017

Bei Ubuntu 17.10 scheint es keine Verzögerung mehr zu geben, dennoch wird die Swap-Datei nicht mit eingebunden. Das ist wiederum über die Systemüberwachung zu sehen. Der Fix von oben kann genauso angewendet werden, dann geht es.