Cruiz
(Themenstarter)
Anmeldungsdatum: 6. März 2014
Beiträge: 5557
Wohnort: Freiburg i. Brsg.
|
Vielen Dank stefanott für dieses perfekte Tutorial. Das sollte seinen Einzug ins Wiki finden bis das Problem upstream gelöst ist. Bei mir hat es sehr gut funktioniert. Ich stimme aber megacloud zu, dass dieses Problem dringend upstream auf die ToDo Liste gesetzt werden müsste. Hat jmd. einen aktuellen Bugreport dazu in dem das Thema ist? Natürlich ist LUKS im Linux-Umfeld inzwischen erste Wahl aber gerade für mobile Geräte mit nicht so wichtigen Daten und stationäre Mehrbenutzersysteme ist ecryptfs immer noch die optimale Lösung. Das wäre im Debian-Jargon eigentlich ein RC Bug.
|
megacloud
Anmeldungsdatum: 13. März 2007
Beiträge: 10
|
nur ganz kurz: nach einem release-upgrade von einem frisch installierten ubuntu 13.10 auf version 14.04 war swap verfügbar.
|
MattVanDoorn
Anmeldungsdatum: 2. Mai 2014
Beiträge: 16
|
Also ich hab mein System neu aufgesetzt (Ubuntu 14.04 "Trusty Tahr").
Nach der Anleitung im Wiki Manuelle Partitionierung, also auch den Swap Speicher angelegt (sda5). Anschließend das Home-Verzeichnis verschlüsseln lassen.
Siehe da, kein swap-Speicher! Habe dann wie von stefanott geschriebene Anleitung befolgt, aber am Ende zeigt er mit mit
swapon -s keinen swap-Speicher an:
swapon -s
Filename Type Size Used Priority sudo blkid
/dev/sda1: UUID="41a97d55-4816-4926-a728-1be716fca294" TYPE="ext2"
/dev/sda5: UUID="d8b632a4-1ce8-4170-abfd-24bddb80fb5e" TYPE="swap"
/dev/sda6: UUID="da8529ba-a8a1-4755-b3c9-6f09bcb05dc5" TYPE="ext4"
/dev/sda7: UUID="26bf7be6-655c-4d36-bf9b-8ea085e12936" TYPE="ext4" Scheint so, als wäre die swap-Partition noch nicht eingehängt?
Oder hat es was zu tun, dass ich Ubuntu benutze? Trotzdem vielen Dank an stefanott für die gute Anleitung! Edit: weitere Ausgaben: sudo lsblk -o NAME,UUID,LABEL,FSTYPE,MOUNTPOINT
NAME UUID LABEL FSTYPE MOUNTPOINT
sda
├─sda1 41a97d55-4816-4926-a728-1be716fca294 ext2 /boot
├─sda2
├─sda5 d8b632a4-1ce8-4170-abfd-24bddb80fb5e swap
│ └─cryptswap1 (dm-0)
├─sda6 da8529ba-a8a1-4755-b3c9-6f09bcb05dc5 ext4 /
├─sda7 26bf7be6-655c-4d36-bf9b-8ea085e12936 ext4 /home
└─sda8
sr0 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=da8529ba-a8a1-4755-b3c9-6f09bcb05dc5 / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=41a97d55-4816-4926-a728-1be716fca294 /boot ext2 defaults 0 2
# /home was on /dev/sda7 during installation
UUID=26bf7be6-655c-4d36-bf9b-8ea085e12936 /home ext4 defaults 0 2
# swap was on /dev/sda5 during installation
#UUID=973ce90d-73e6-4e39-8bbb-8019d79be96f none swap sw 0 0
/dev/mapper/cryptswap1 none swap sw,noauto 0 0
|
stefanott
Anmeldungsdatum: 29. Oktober 2009
Beiträge: 134
|
Hallo MattVanDoorn, zeige mal noch die Ausgabe von cat /etc/rc.local Stefan
|
MattVanDoorn
Anmeldungsdatum: 2. Mai 2014
Beiträge: 16
|
cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
echo "cryptswap1 UUID=d8b632a4-1ce8-4170-abfd-24bddb80fb5e /dev/urandom swap,offset=8,cipher=aes-cbc-essiv:sha256" > /etc/crypttab
cryptdisks_start cryptswap1
sleep 5
swapon /dev/mapper/cryptswap1
echo "#/etc/crypttab wird beim booten durch /etc/rc.local neu erstellt" > /etc/crypttab
exit 0
|
stefanott
Anmeldungsdatum: 29. Oktober 2009
Beiträge: 134
|
Sieht richtig aus, zeige mal noch die Ausgabe von cat /etc/crypttab Stefan
|
MattVanDoorn
Anmeldungsdatum: 2. Mai 2014
Beiträge: 16
|
cat /etc/crypttab
cryptswap1 UUID=d8b632a4-1ce8-4170-abfd-24bddb80fb5e /dev/urandom swap,offset=8,cipher=aes-cbc-essiv:sha256
|
Cruiz
(Themenstarter)
Anmeldungsdatum: 6. März 2014
Beiträge: 5557
Wohnort: Freiburg i. Brsg.
|
Da steht bei mir folgendes:
cat /etc/crypttab
#/etc/crypttab wird beim booten durch /etc/rc.local neu erstellt
|
stefanott
Anmeldungsdatum: 29. Oktober 2009
Beiträge: 134
|
Hallo MattVanDoorn, ich würde sagen Du hast noch nicht neugestartet, deshalb wurde /etc/rc.local noch nicht ausgeführt (es sind insgesamt 2 reboots notwendig). Danach sieht der Eintrag in der /etc/crypttab wie bei MrGerardCruiz aus. Die /etc/crypttab wird beim Neustart jedesmal mit der auskommentierten Zeile #/etc/crypttab wird beim booten durch /etc/rc.local neu erstellt überschrieben. Das ist so gewollt und Vorraussetzung, so dass diese in Kombination mit "noauto" in der /etc/fstab beim Start nicht gleich, sondern erst später durch die Einträge in /etc/rc.local eingebunden wird um Timingprobleme aus dem Wege zu gehen. Der notwendige Eintrag mit der UUID Deiner Swap-Partition wird dabei nur temporär kurz in die /etc/crypttab geschrieben. Stefan
|
B601
Anmeldungsdatum: 10. Juli 2009
Beiträge: 105
Wohnort: Wien
|
Hallo, habt ihr schon daran gedacht, dass es auch einfacher geht? Im Gegensatz zu einem "normalen" Filesystem muss ich als Mensch von Swap ja nichts auslesen (können). Das heißt, ich brauche das Passwort gar nicht zu kennen und ich kann es jedes Mal beim Hochfahren des Rechners neu und zufällig verschlüsseln (was gleichzeitig auch sicherer ist). Dazu braucht man bloß einen Eintrag in der /etc/crypttab, z.B.:
cryptswap /dev/sdaX /dev/urandom swap,cipher=aes-cbc-essiv:sha256 und einen in der /etc/fstab:
/dev/mapper/cryptswap none swap sw 0 0 Ihr braucht auch keine Angst zu haben, wenn ihr z.B. eine externe Festplatte ansteckt, die beim nächsten Booten zufällig /dev/sda wird (kann nur mit eSATA passieren). Denn wenn ein "fremdes" Dateisystem auf dem Device /dev/sdaX gefunden wird, wird es nicht überschrieben. Das wird nur gemacht, wenn sich darauf bereits ein altes ecryptfs befindet oder das Device leer ist. Dh. vor dem erstmaligen Erstellen muss der Anfang ausgenullt werden, z.B.:
sudo dd if=/dev/zero of=/dev/sdaX bs=1M count=1 Viel Spaß!
|
stefanott
Anmeldungsdatum: 29. Oktober 2009
Beiträge: 134
|
B601 schrieb:
habt ihr schon daran gedacht, dass es auch einfacher geht?
Hallo B601, das tut es ja leider nicht, deshalb die ganzen Umstände. Der von Dir beschriebene Weg ist absolut korrekt, aber zum einen geht das dann wieder über Upstart und dann ist vermutlich "/dev/mapper/cryptswap1" wieder nicht bereit, zum anderen ist laut Analyse von anderen Usern ein offset notwendig, da sonst die UUID überschrieben wird. Klar wenn Du /dev/sdaX verwendest hast Du das Problem vermutlich nicht, aber mit offset=8 kann problemlos UUID verwendet werden und damit ist auch das von Dir erwähnte Verhalten beim anstöpseln einer externene HD elegant gelöst. Stefan
|
B601
Anmeldungsdatum: 10. Juli 2009
Beiträge: 105
Wohnort: Wien
|
stefanott schrieb: B601 schrieb:
habt ihr schon daran gedacht, dass es auch einfacher geht?
Hallo B601, das tut es ja leider nicht, deshalb die ganzen Umstände. Der von Dir beschriebene Weg ist absolut korrekt, aber zum einen geht das dann wieder über Upstart und dann ist vermutlich "/dev/mapper/cryptswap1" wieder nicht bereit, zum anderen ist laut Analyse von anderen Usern ein offset notwendig, da sonst die UUID überschrieben wird. Klar wenn Du /dev/sdaX verwendest hast Du das Problem vermutlich nicht, aber mit offset=8 kann problemlos UUID verwendet werden und damit ist auch das von Dir erwähnte Verhalten beim anstöpseln einer externene HD elegant gelöst. Stefan
Doch, zumindest bei mir scheint es auf diese Weise immer zu funktionieren. Hingegen hat der beschriebene Workaround bei mir genau ein einziges Mal funktioniert; ab dem zweiten Neustart wieder nicht mehr. Upstart sehe ich nicht als großes Problem, schließlich handelt es sich um eine LTS, und die hält mindestens 2 Jahre. Wer gerne die Zwischenversionen verwendet, muss ohnehin damit rechnen, dass nach jedem Upgrade etwas nicht mehr so funktioniert wie vorher.
|
B601
Anmeldungsdatum: 10. Juli 2009
Beiträge: 105
Wohnort: Wien
|
B601 schrieb:
Doch, zumindest bei mir scheint es auf diese Weise immer zu funktionieren.
Ähm ... tut es leider nicht. Nach einem Neustart schon, aber nicht nach Herunterfahren und wieder Einschalten. Sehr seltsam... Und zwar ist der Fehler der, dass zwar das Devicemapping erzeugt wird, aber kein Swap. Workaround - in /etc/rc.local zusätzlich eintragen: sleep 10
mkswap /dev/mapper/cryptswap >/dev/null 2>&1 Aufgrund des Eintrags in der /etc/fstab wird anschließend /dev/mapper/cryptswap automatisch - ohne weiteren Befehl - benützt!
|
stefanott
Anmeldungsdatum: 29. Oktober 2009
Beiträge: 134
|
B601 schrieb:
Nach einem Neustart schon, aber nicht nach Herunterfahren und wieder Einschalten. Sehr seltsam... Und zwar ist der Fehler der, dass zwar das Devicemapping erzeugt wird, aber kein Swap. Workaround - in /etc/rc.local zusätzlich eintragen: sleep 10
mkswap /dev/mapper/cryptswap >/dev/null 2>&1 Aufgrund des Eintrags in der /etc/fstab wird anschließend /dev/mapper/cryptswap automatisch - ohne weiteren Befehl - benützt!
Hallo B601, kleine Zusammenfassung vorab: Auszug aus man crypttab und Erklärung des Parameters swap: Run mkswap on the created device. Auszug aus man cryptdisks_start: DESCRIPTION: cryptdisks_start is a wrapper around cryptsetup that parses /etc/crypttab just like the initscript /etc/init.d/cryptdisks does and starts the dm-crypt mapping that corresponds to <name>.
Auszug aus man mkswap: After creating the swap area, you need the swapon command to start using it. Wenn Du also eine /etc/crypttab hast, welche einen gültigen und nicht auskommentierten Eintrag hast, passieren imho zwei Dinge: 1. cryptdisks_start wird durch Upstart geladen 2. mkswap in Deinem Fall wird ausgeführt wenn /etc/rc.local ausgeführt wird, unabhängig ob cryptdisks bereit ist. Dies geschieht bereits durch den Parameter swap in der /etc/crypttab 3. Wenn die /etc/fstab erst nach Punkt 3 berücksichtigt wird dann vielleicht, aber "noauto" und bewusstes swapon kann ich steuern B601 schrieb:
Upstart sehe ich nicht als großes Problem, schließlich handelt es sich um eine LTS, und die hält mindestens 2 Jahre. Wer gerne die Zwischenversionen >verwendet, muss ohnehin damit rechnen, dass nach jedem Upgrade etwas nicht mehr so funktioniert wie vorher.
Die Fehlermeldung "/dev/mapper/cryptswap1 is not ready yet or not present" sehe ich nun schon seit 4 Jahren, davon sind also schon zwei LTS betroffen. Wohlgemerkt alles frische Installationen über das normale Setup mit verschlüsseltem Homeverzeichnis. Ich fürchte der Fehler wird über den gesamten Supportzeitraum von 14.04 bestehen bleiben. Stefan
|
B601
Anmeldungsdatum: 10. Juli 2009
Beiträge: 105
Wohnort: Wien
|
stefanott schrieb:
Wenn Du also eine /etc/crypttab hast, welche einen gültigen und nicht auskommentierten Eintrag hast, passieren imho zwei Dinge: 1. cryptdisks_start wird durch Upstart geladen 2. mkswap in Deinem Fall wird ausgeführt wenn /etc/rc.local ausgeführt wird, unabhängig ob cryptdisks bereit ist. Dies geschieht bereits durch den Parameter swap in der /etc/crypttab 3. Wenn die /etc/fstab erst nach Punkt 3 berücksichtigt wird dann vielleicht, aber "noauto" und bewusstes swapon kann ich steuern
Die Fehlermeldung "/dev/mapper/cryptswap1 is not ready yet or not present" sehe ich nun schon seit 4 Jahren, davon sind also schon zwei LTS betroffen. Wohlgemerkt alles frische Installationen über das normale Setup mit verschlüsseltem Homeverzeichnis. Ich fürchte der Fehler wird über den gesamten Supportzeitraum von 14.04 bestehen bleiben.
Ich glaube, hier liegt ein kleines Missverständnis vor. Der Eintrag in der crypttab sollte eigentlich mit dem Öffnen nicht nur das verschlüsselte Device mit zufälligem Schlüssel/Passwort erzeugen, sondern anschließend sollte cryptsetup implizit mit dem Formatieren der Swap-Partition beauftragt werden. Dieser Eintrag sollte also alles in einem einzigen Schritt machen. Das heißt, der Eintrag in der rc.local holt nur das mkswap nach, das cryptsetup komischerweise nach Poweron nicht selbst ausführt. Eine Fehlermeldung erscheint nur in der syslog, nicht auf dem Bildschirm:
May 7 06:33:06 myhostname kernel: [ 20.276274] device-mapper: ioctl: Unable to change name on mapped device cryptswap_unformatted to one that already exists: cryptswap Für mich bedeutet dass, dass wahrscheinlich auf Grund von nach Poweroff notwendigen und länger dauernden Geräteinitialisierungen der Bootvorgang in einer anderen Reihenfolge bzw. mit unterschiedlichen Zeitabläufen stattfindet als nach Reboot. Und diese Änderung bewirkt in irgendeiner Form eine Blockade. Dh. die Äbhängigkeiten sind in den Upstart-Scripts in irgendeiner Form nicht korrekt bzw. "spuckt" irgendwo noch ein altes Sysinit-Script rein. Ich möchte aber jetzt nicht den Bootvorgang analysieren 😉. Ich bin mit dem Workaround zufrieden. Im Übrigen hatte ich auf zwei anderen Rechnern eine 13.10-Installation, bei der dies seit jeher (also 9.04 bzw. 10.04) völlig problemlos funktionierte! Das dürfte also geräteabhängig sein... (Einer dieser Rechner wurde nun ersetzt, der andere wird in Kürze auf 14.04 LTS upgegradet.)
|