syscon-hh
Anmeldungsdatum: 8. Oktober 2005
Beiträge: 10220
|
MrGerardCruiz schrieb: Siehe Edit 😉
Nun musst Du aber die /dev/sda2 bitte noch mal als SWAP formatieren! Dann sollte es auch wieder laufen. Und die dann neue UUID bitte noch als resume-Device ins System eintragen. Aber ich schau mir jetzt mal das KUbuntu nach der jetzt laufenden Installtion von Trusty an - ob das anders ist, als alle bisherigen Installationen.
|
Cruiz
(Themenstarter)
Anmeldungsdatum: 6. März 2014
Beiträge: 5557
Wohnort: Freiburg i. Brsg.
|
Wenn du jetzt die sda2 nochmal neu als Swap partitioniere, ist dann nicht die Verschlüsselung über den Jordan?
|
syscon-hh
Anmeldungsdatum: 8. Oktober 2005
Beiträge: 10220
|
MrGerardCruiz schrieb: Wenn du jetzt die sda2 nochmal neu als Swap partitioniere, ist dann nicht die Verschlüsselung über den Jordan?
Nein - das wird durch die /etc/crypttab und die dahinter stehenden Routinen jedes mal neu geregelt.
|
Cruiz
(Themenstarter)
Anmeldungsdatum: 6. März 2014
Beiträge: 5557
Wohnort: Freiburg i. Brsg.
|
|
Cruiz
(Themenstarter)
Anmeldungsdatum: 6. März 2014
Beiträge: 5557
Wohnort: Freiburg i. Brsg.
|
Ich habe das jetzt soweit gemacht, allerdings scheine ich irgendeinen Fehler gemacht zu haben. ***@Schleppmaschine:~$ sudo parted -l
[sudo] password for ***:
Modell: ATA ST9320325AS (scsi)
Festplatte /dev/sda: 320GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Nummer Anfang Ende Größe Typ Dateisystem Flags
1 1049kB 20,0GB 20,0GB primary ext4 boot
2 20,0GB 24,0GB 3989MB primary linux-swap(v1)
3 24,0GB 320GB 296GB primary ext4
Fehler: /dev/mapper/cryptswap1: unbekannte Partitionstabelle ***@Schleppmaschine:~$ cat /etc/crypttab
cryptswap1 /dev/sda2 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Die mapper (oder eine Partition oder Swap) haben und brauchen nie eine Partitionstabelle! Dieselbe Meldung kommt auch bei /dev/sr0 (cdrom). Ich weiß nicht, was hier einige immer mit zufälligen UUIDs haben - ▶ UUIDs sind eineindeutig. Aber nicht ohne Grund wird in der Swapzeile der crypttab /dev/urandom stehen...
|
Cruiz
(Themenstarter)
Anmeldungsdatum: 6. März 2014
Beiträge: 5557
Wohnort: Freiburg i. Brsg.
|
Benno-007 schrieb: Die mapper (oder eine Partition oder Swap) haben und brauchen nie eine Partitionstabelle! Dieselbe Meldung kommt auch bei /dev/sr0 (cdrom). Ich weiß nicht, was hier einige immer mit zufälligen UUIDs haben - ▶ UUIDs sind eineindeutig. Aber nicht ohne Grund wird in der Swapzeile der crypttab /dev/urandom stehen...
Und welche Lehre soll man daraus nun ziehen?
|
tlu
Anmeldungsdatum: 30. Mai 2006
Beiträge: 266
|
Benno-007 schrieb:
Ich weiß nicht, was hier einige immer mit zufälligen UUIDs haben - ▶ UUIDs sind eineindeutig.
Das sehe ich auch so, daher mein Erstaunen über diese Aussage von syscon-hh. Aber hast du vielleicht eine Idee, warum blkid eine unterschiedliche UUID anzeigt? Macht m.E. überhaupt keinen Sinn, muss ein Bug sein.
|
syscon-hh
Anmeldungsdatum: 8. Oktober 2005
Beiträge: 10220
|
So ich habe jetzt mal schnell ein Trusty Kubuntu installiert. Und ja ich muss mich entschuldigen, dort ist tatsächlich ein Fehler im Skript. Ich hatte das nur noch nicht bemerkt, weil meine Trusties alles Upgrades sind und diese Datei richtig übernommen wird. Ich spiele das jetzt noch mal zu Ende, was zu tun ist -den "workarroaund" liefere ich nach.
|
tlu
Anmeldungsdatum: 30. Mai 2006
Beiträge: 266
|
syscon-hh schrieb: So ich habe jetzt mal schnell ein Trusty Kubuntu installiert. Und ja ich muss mich entschuldigen, dort ist tatsächlich ein Fehler im Skript.
Die interessante Frage ist, ob das nur bei Kubuntu so ist oder ein genereller Fehler in Trusty ist.
Ich spiele das jetzt noch mal zu Ende, was zu tun ist -den "workarroaund" liefere ich nach.
Bin ich mal gespannt 😉
|
syscon-hh
Anmeldungsdatum: 8. Oktober 2005
Beiträge: 10220
|
syscon-hh schrieb: Ich spiele das jetzt noch mal zu Ende, was zu tun ist -den "workaroaund" liefere ich nach.
So hier der "workaround":
sudo parted -l # kleines L
Da muss man jetzt die richtige Partition herausfinden - diese hat jetzt keine UUID mehr es sei beispielhaft /dev/sdb3, dann:
sudo -s
umount /dev/sdb3
mkswap /dev/sdb3 # angezeigte UUID in die nächste Zeile übernehmen
echo "RESUME=UUID=143c43d8-0a77-4d62-a7ae-f53a8e0229a9" > /etc/initramfs-tools/conf.d/resume
sudo echo "cryptswap1 /dev/sdb3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256" > /etc/crypttab
update-initramfs -u
exit
Die Datei resume wird für den Bereitschaftsmodus gebraucht, wird aber nicht auf allen Rechnern richtig angewendet. Jetzt nur noch einmal rebooten und den Erfolg abfragen. gruß syscon-hh Nachtrag: Bei mir klappt das jetzt in der Neuinstallation auch nach mehrfachen Rebooten:
laura@kubuntu:~$ swapon -s
Filename Type Size Used Priority
/dev/mapper/cryptswap1 partition 8245244 0 -1
Anmerkung: Die Abfrage der UUID ist natürlich nicht mehr gegeben - aber diese ist im System wegen dem update-initramfs nach wie vor vorhanden. Und auch der Bereitschaftsmodus geht hier ohne Probleme. Nun kümmere ich mich mal um den 953875-Report - mit diesem wurde das von /dev/sdxy auf UUID verändert. Da scheint es ein grundsätzliches Problem zu geben.
|
tlu
Anmeldungsdatum: 30. Mai 2006
Beiträge: 266
|
syscon-hh schrieb:
Bei mir klappt das jetzt in der Neuinstallation auch nach mehrfachen Rebooten:
Danke, bei mir auch! Meine Lösung, die durch blkid genannte UUID in die crpyttab einzusetzen, hatte komischerweise beim 1. Reboot geklappt, danach aber nicht mehr ...
|
syscon-hh
Anmeldungsdatum: 8. Oktober 2005
Beiträge: 10220
|
Der Fehler ist im Skript /usr/bin/ecryptfs-setup-swap enthalten, welches schon bei der Grundinstallation verwendet wird. Und hier scheint das Problem zu liegen! Hier mal die Passage vorher → nachher:
# Add crypttab entry
echo "cryptswap$i $swap /dev/urandom swap,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab
# Add crypttab entry
echo "cryptswap$i UUID=$uuid /dev/urandom swap,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab Begründung: Beim Installieren ist ja die zukünftige UUID für die Partitionen nicht bekannt und in der Regel auch nicht, auf welche /dev/sdxy das System mit der /etc/crypttab zu liegen kommt - insbesondere die Zuordnung mit dev/** macht da im nachhinein Probleme, insbesondere, wenn von einem USB-Stick aus installiert wurde. Darum hatte man sich entschlossen, dass auf UUID umzustellen. Nur hat man dabei nicht bedacht, dass durch die Nutzung des Speicherbereiches auf der Festplatte mit einem /dev/urandom-System die internen Daten verloren gehen und es ja auch sollen. Dustin, weitere Spezialisten und ich sind dran, dieses Problem zu lösen. Kann aber dauern, es hängt einfach zu viel Gegensätzliches dran. Ein paar "ich bin auch betroffen" bei 1310058 könnte es beschleunigen. gruß syscon-hh
|
chilidude
Anmeldungsdatum: 18. Februar 2010
Beiträge: 867
|
tlu schrieb: syscon-hh schrieb:
Bei mir klappt das jetzt in der Neuinstallation auch nach mehrfachen Rebooten:
Danke, bei mir auch! Meine Lösung, die durch blkid genannte UUID in die crpyttab einzusetzen, hatte komischerweise beim 1. Reboot geklappt, danach aber nicht mehr ...
Die UUID wird im ersten Sektor der Partition gespeichert. Da Swap aber keinen Luks-Header hat (der auch eine UUID speichern kann) wirkt die Verschlüsselung auf den ersten Sektor und überschreibt damit die UUID. (Dann kann das System die Partition beim nächsten Start natürlich nicht mehr finden.) Abhilfe schafft entweder die Anagbe im Format "/dev/sdxx" oder die Parameterangabe von "offset" oder "skip", welche Startsektoren aussparen (und damit die UUID nicht überschreiben.) Z.B so: cryptswap1 UUID=37d1cda3-34c1-47d4-9b26-481aed29b0bd /dev/urandom swap,offset=8,cipher=aes-cbc-essiv:sha256
|
syscon-hh
Anmeldungsdatum: 8. Oktober 2005
Beiträge: 10220
|
chilidude schrieb: Abhilfe schafft entweder die Anagbe im Format "/dev/sdxx" oder die Parameterangabe von "offset" oder "skip", welche Startsektoren aussparen (und damit die UUID nicht überschreiben.)
Danke für den Hinweis - wir werden das jetzt mal ausgiebig austesten (auch bitte obige Beteiligte) und dann im 1310058 als Vorschlag einbringen. gruß syscon-hh
|