Ich will eine Ubuntu 12.04 - Installation mit LUKS auf eine größere
Platte umziehen. Ich habe mich an folgende Anleitung gehalten:
https://help.ubuntu.com/community/ResizeEncryptedPartitions#Detailed_resizing_.2BAH4_Enlarging_an_encrypted_partition
Folgendes habe ich gemacht:
1. Alte Platte (500 GB) mit dd auf neue Platte (1 TB) kopiert.
2. Kopiertes System gebootet - alles läuft
3. Life-CD gebootet
4. Mit Gparted die Extended Partition, die die LUKS-Daten bis zum Ende
der Platte vergrößert.
5. LUKS und LVM im Life-System installiert
sudo apt-get update && sudo apt-get install lvm2 cryptsetup
sudo modprobe dm-crypt
6. Entschlüsseln und LVM aktivieren
sudo cryptsetup luksOpen /dev/sdb5 crypt1
sudo vgscan --mknodes
sudo vgchange -ay
7. Filesystemcheck
sudo e2fsck -f /dev/mapper/lx6-root
Keine Fehler
8. Crypotcontainer vergrößern
sudo cryptsetup resize crypt1
9. Physikalisches LVM-Module vergrößern
sudo pvresize /dev/mapper/crypt1
10. Logisches Volume auf volle Größe erweitern
sudo lvresize -L +465G /dev/lx6/root
Es kommt folgende Fehlermeldung:
1
Rounding up size to full physical extent 454,84 GiB
2
Extending logical volume root to 916,31 GiB
3
Insufficient free space: 116438 extents needed, but only 12 available
Wieso das?
Die ursprüngliche Platte wurde vom Ubuntu-Installer erzeugt:
1
$ sudo lvdisplay
2
--- Logical volume ---
3
LV Name /dev/lx6/root
4
VG Name lx6
5
LV UUID ***
6
LV Write Access read/write
7
LV Status available
8
# open 1
9
LV Size 461,47 GiB
10
Current LE 118137
11
Segments 1
12
Allocation inherit
13
Read ahead sectors auto
14
- currently set to 256
15
Block device 252:1
16
17
--- Logical volume ---
18
LV Name /dev/lx6/swap_1
19
VG Name lx6
20
LV UUID ***
21
LV Write Access read/write
22
LV Status available
23
# open 2
24
LV Size 4,00 GiB
25
Current LE 1023
26
Segments 1
27
Allocation inherit
28
Read ahead sectors auto
29
- currently set to 256
30
Block device 252:2
Stutzig mach mich bei der Beschreibung der Satz (siehe Link oben):
1
1. Boot a live CD and, using any tool, using any tool create a new
2
partition, lets call it /dev/sda6 , next to and to the left of (after)
3
your crypt.
Was soll das "next to and to the left of (after)" heißen? Soll der
bisher gültige, verschlüsselte Datenblock ans Ende der Partition
verschoben werden? Wie soll das gehen? Gparted weigert sich, dort
irgendwas zu verschieben. Ich kann die Partition erweitern, aber das
wars dann auch.
Uhu Uhuhu schrieb:> 9. Physikalisches LVM-Module vergrößern> sudo pvresize /dev/mapper/crypt1
Du vergrößerst das der volume group zugrunde liegende physical volume.
Check mal ob die volume group nicht in dem moment schon automatisch
größer wird.
> 10. Logisches Volume auf volle Größe erweitern> sudo lvresize -L +465G /dev/lx6/root
das logical volume liegt in einer volume group. check mal ob die schon
größer geworden ist (siehe oben). wenn nicht, musst du vielleicht noch
an der hand anlegen. erst danach kannst du das logical volume
vergrößern.
lvm ist so geschachtelt: pv - vg - lv
ansonsten für faule: statt vergrößern einfach auf dem zusätzlichen platz
ein weiteres pv anlegen, das dann der vg hinzufügen. dann kannst du das
lv vergrößern. fertig.
Schon das pvresize bewirkt nichts, bringt aber auch keine Fehlermeldung:
1
$ sudo pvdisplay
2
--- Physical volume ---
3
PV Name /dev/dm-0
4
VG Name lx6
5
PV Size 465,52 GiB / not usable 3,81 MiB
6
Allocatable yes
7
PE Size 4,00 MiB
8
Total PE 119172
9
Free PE 12
10
Allocated PE 119160
11
PV UUID ***
12
13
$ sudo pvresize /dev/mapper/crypt1
14
Physical volume "/dev/dm-0" changed
15
1 physical volume(s) resized / 0 physical volume(s) not resized
16
17
$ sudo pvdisplay
18
--- Physical volume ---
19
PV Name /dev/dm-0
20
VG Name lx6
21
PV Size 465,52 GiB / not usable 3,81 MiB
22
Allocatable yes
23
PE Size 4,00 MiB
24
Total PE 119172
25
Free PE 12
26
Allocated PE 119160
27
PV UUID ***
Der leere Bereich am Ende der Platte ist laut GPartEd in der Extendet
Partition. Trotzdem sieht pvresize nach den 12 PEs, die auf der alten
Platte unbrauchbar hinter dem PV lagen, das Ende der Fahnenstange.
Wie ist das mit LUKS, wenn man einfach ein zweites PV im freien Bereich
anlegt: ist das PV dann mit im LUKS-Container, oder nicht?
Uhu Uhuhu schrieb:> Schon das pvresize bewirkt nichts, bringt aber auch keine Fehlermeldung:
hmm. vermutlich reibt sich der irgendwie mit dem luks. das verwendet ja
intern auch den devicemapper, kann gut sein daß das deshalb nicht
richtig klappt.
sorum hab ich das bisher noch nie probiert, ich hab beim umzug auf
größere platten bisher immer dort alles neu angelegt und dann mit rsync
rübergezogen. waren auch immer ein paar jahre dazwischen, so daß ich auf
der neuen platte immer von den neuen filesystem-features profitieren
wollte.
> Wie ist das mit LUKS, wenn man einfach ein zweites PV im freien Bereich> anlegt: ist das PV dann mit im LUKS-Container, oder nicht?
nein. normal wäre das dann ein 2. luks-container. kannst aber natürlich
die selben passwörter für nehmen.
Gerd E. schrieb:> nein. normal wäre das dann ein 2. luks-container. kannst aber natürlich> die selben passwörter für nehmen.
und müßte dann beim Boot das Paßwort zweimal eingeben - elegant ist das
nicht...
Uhu Uhuhu schrieb:> und müßte dann beim Boot das Paßwort zweimal eingeben - elegant ist das> nicht...
sicher daß dracut so doof ist? ich gehe eigentlich davon aus daß er das
einmal eingegebene passwort auch bei allen anderen luks-containern
probiert. er kann ja feststellen ob das eingegebene pwd gültig ist oder
nicht.
wenn der das nicht kann, wäre das glatt einen grund nen patch für zu
schreiben und das zu fixen.
Gerd E. schrieb:> sicher daß dracut so doof ist?
Ich habe mal zwei Platten mit identischem Paßwort gehabt. Wenn ich die
zweite gemountet habe, hat er das Paßwort abgefragt, obwohl er dasselbe
der Systemplatte seit dem Boot kannte.
Das hat nichts mit Doofheit zu tun, sondern liegt in der Natur der
Sache: LUKS ist ein Chiffriersystem und kein Hilfmittel zum
Durchprobieren von Paßwörtern.
Und stell dir vor: Bob hat ein verschlüsseltes System laufen und im
Schrank liegt eine weitere Platte mit streng geheimem Inhalt, aber
identischem Paßwort. Bob verläßt den Raum, ohne seinen Rechner zu
sperren, Eve bekommt das mit und nutzt die Gelegenheit, zwar nicht daß
Paßwort, dafür aber den Inhalt der streng geheimen Platte geschenkt zu
bekommen...
Hast schon recht, aber es ging ja nur um dracut, also ob das Passwort
ggFs. während des Bootvorgangs kurzzeitig gecached wird. Damit erübrigt
sich das Szenario mit der Platte aus dem Safe :)
Wobei das durchaus ein Thema wäre, wenn die Platten dasselbe rohe
Schlüsselmaterial verwendeten. Deshalb sollte man auch keine
LUKS-Container mal eben komplett klonen.
Malte S. schrieb:> Deshalb sollte man auch keine LUKS-Container mal eben komplett klonen.
Wenn die Urkopie hinterher platt gemacht wird, ist das so sicher, wie
die es die Urkopie auch war.
Uhu Uhuhu schrieb:> Wenn die Urkopie hinterher platt gemacht wird, ist das so sicher, wie> die es die Urkopie auch war.
Völlig klar. Aber es sollen schon Leute auf die Idee gekommen sein,
Rechner mit LUKS zu klonen und dann nur das Passwort zu ändern. Was am
eigentlichen Schlüssel nichts ändert. Somit reicht es, einen einzigen
Klon zu kompromittieren, um alle seine Zwillinge zu entschlüsseln.
Aber zurück zu deinem Anliegen:
Uhu Uhuhu schrieb:> 6. Entschlüsseln und LVM aktivieren> sudo cryptsetup luksOpen /dev/sdb5 crypt1> sudo vgscan --mknodes> sudo vgchange -ay
Sollte passen, aktiviert aber das Device.
Uhu Uhuhu schrieb:> 8. Crypotcontainer vergrößern> sudo cryptsetup resize crypt1
War dieser Schritt erfolgreich?
Bei mir führt der ohne Fehlermeldung KEIN resize durch, wenn das Volume
in Verwendung ist.
Sonst mach mal
sudo vgchange -an
und versuch dann nochmal Schritt 8.
Ja, die habe ich auch mehrmals gefunden :)
Da ich immer neugierig bin und noch nie ein LUKS-Volume in der Größe
verändert hatte, habe ich das mit einem mehr oder weniger vergleichbaren
Setup durchgespielt, nur mit loop-Device statt einer MBR-Partition.
Und da fiel mir auf, dass sich die Größe des dm-crypt-Volumes nach dem
Aufruf von cryptsetup resize nur dann ändert, wenn das darüberliegende
LVM-Zeug nicht aktiviert ist.
Es lässt sich also mutmaßen, dass diese omnipräsente Anleitung zwar
prinzipiell richtig ist, aber z.B. die Schritte zum Verifizieren des
Dateisystems nachträglich trocken eingebaut wurden oder sonstwie die
Reihenfolge durcheinander gekommen ist. Oder einfach nur das vgchange
-an vergessen wurde.
Also bleibt der Vorschlag: deaktiviere die VG und versuch es dann
nochmal mit Schritt 8-10 und erneutes vgchange -ay irgendwo dazwischen
(bin ich mir auch wieder nicht sicher, aber ich glaub, pvresize geht on-
oder offline).
Malte S. schrieb:> Es lässt sich also mutmaßen, dass diese omnipräsente Anleitung zwar> prinzipiell richtig ist, aber z.B. die Schritte zum Verifizieren des> Dateisystems nachträglich trocken eingebaut wurden oder sonstwie die> Reihenfolge durcheinander gekommen ist.
So scheint es... Ich mache heute Abend nochmal alle Schritte und füge
das sudo vgchange -an vor Schritt 8 ein.
Uhu Uhuhu schrieb:> Gerd E. schrieb:>> nein. normal wäre das dann ein 2. luks-container. kannst aber natürlich>> die selben passwörter für nehmen.>> und müßte dann beim Boot das Paßwort zweimal eingeben - elegant ist das> nicht...
Du kannst aber z.B. auch einen Key in einem File ablegen. Das liegt dann
im ersten, par Passwort verschlüsselten Container.
Ich hab hier einen Rechner, wo jedes logische Laufwerk in einem eigenen
LUKS-Container steckt, und ich muß beim Booten nur einmal ein Passwort
eingeben.
Rolf Magnus schrieb:> Du kannst aber z.B. auch einen Key in einem File ablegen. Das liegt dann> im ersten, par Passwort verschlüsselten Container.
Das geht hier nicht, da er sein filesystem ja nicht mounten kann solange
die lvm volume group nicht komplett ist.
> Ich hab hier einen Rechner, wo jedes logische Laufwerk in einem eigenen> LUKS-Container steckt, und ich muß beim Booten nur einmal ein Passwort> eingeben.
jetzt mit der oben von dir beschriebenen technik oder ohne solche
hilfsmittel?
Gerd E. schrieb:> Das geht hier nicht, da er sein filesystem ja nicht mounten kann solange> die lvm volume group nicht komplett ist.
Mit LVM on LUKS geht das nicht. Mit LUKS on LVM schon. Da ist die VG
eben komplett, nur die einzelnen LVs sind geLUKSt.
Uhu Uhuhu schrieb:> 4. Mit Gparted die Extended Partition, die die LUKS-Daten bis zum Ende> der Platte vergrößert.
Du mußt nicht sda2 sondern sda5 vergrößern. Siehe hierzu Dein Bild in
Deinem zweiten Post.
> 5.> 6.> 7.> 8.> 9.
Alle diese Schritte melden keinen Fehler, weil nichts zu tun ist.
> 10. Logisches Volume auf volle Größe erweitern> sudo lvresize -L +465G /dev/lx6/root
Und hier ist kein Platz, weil das PV nicht größer ist, als zuvor.
> Stutzig mach mich bei der Beschreibung der Satz (siehe Link oben):>
1
> 1. Boot a live CD and, using any tool, using any tool create a new
2
> partition, lets call it /dev/sda6 , next to and to the left of (after)
3
> your crypt.
4
>
>> Was soll das "next to and to the left of (after)" heißen? Soll der> bisher gültige, verschlüsselte Datenblock ans Ende der Partition> verschoben werden? Wie soll das gehen? Gparted weigert sich, dort> irgendwas zu verschieben. Ich kann die Partition erweitern, aber das> wars dann auch.
Dies dient nur dazu, den bisher freien Platz hinter Deiner
verschlüsselten Partition mit Zufallswerten zu füllen, sonst könnte man
aufgrund der freien Blöcke auf die Verschlüsselung schließen.
Till Uhde schrieb:> Du mußt nicht sda2 sondern sda5 vergrößern. Siehe hierzu Dein Bild in> Deinem zweiten Post.
OK, sdb2 zu vergrößern war also nur die halbe Miete... Entsprechend hat
mein letzter Versuch eben mit dem sudo vgchange -an auch nichts
gebracht.
Und um sdb5 zu vergrößern muß ich mit fdisk zuerst die Partiton löschen
und dann mit gleicher Anfangsadresse und neuer Länge neu anlegen. Ie
gitt...
> Dies dient nur dazu, den bisher freien Platz hinter Deiner> verschlüsselten Partition mit Zufallswerten zu füllen, sonst könnte man> aufgrund der freien Blöcke auf die Verschlüsselung schließen.
Das ist schon klar und auch schon erledigt. Ich verstehe nicht, was mit
1
next to and to the left of (after) your crypt.
gemeint ist. Wo wird der Platz hinter der letzten Patition links von
ihr angezeigt? In GPartEd jedenfalls nicht.
Am Ende hat da nur mal wieder einer Rinks und Lechts velwechsert...
Uhu Uhuhu schrieb:> OK, sdb2 zu vergrößern war also nur die halbe Miete...
Autsch, ja, übersehen. Oder du nutzt die Gunst der Stunde, diese Kombi
aus logischer und erweiterter Partition loszuwerden und ne primäre draus
zu machen. Das ist doch bei <4 Partitionen so nützlich wie ein Kropf.
Und für mehr gibt es ohnehin GPT und LVM.
Was bringt mir das?
So wie es jetzt ist, brauche ich nur die sdb5 zu löschen und mit
Default-Werten wieder neu anzulegen.
Wenn ich die extented Partition lösche, dann wirds vermutlich
komplizierter und am Ende mach ich mir noch die Daten platt.
So, das nahm ein böses Ende: Das Löschen der sdb5 hat hingehauen, aber
das Neuanlegen geht nicht, weil er meint, die Startadresse müßte
mindestens 503806, während die alte sdb5 bei 501760 lag.
Die sda2 habe ich gelassen, wie sie war. (Die wurde mit GPartEd bis ans
physikalische Ende verlängert.)
Hilft evtl. fdisk -c=dos bzw. fdisk -c?
Hast du die alte Platte noch? Dann könntest du auf der neuen alles neu
anlegen und die Nutzdaten kopieren. Ansonsten könntest, du wenn fdisk
sich weigert, mit dmsetup manuell ein Mapping auf den Bereich der alten
Partition anlegen, um die Daten runterzuretten.
Es ist kein Beinbruch. Ich habe die alte Platte noch und vor der Aktion
ein rdiff-backup von der neuen gezogen, weil ich die die vergangenen 2
Tage in Gebrauch hatte. Ich bringe gerade die alte Platte damit auf den
neusten Stand.
Ich bastel jetzt an dem verunglückten Umzug nicht mehr rum, sondern
partitioniere dort komplett neu und vergrößere bei der Gelegenheit die
Boot-Partition - die ist standardmäßig mit 255 MB etwas mickerig.
Wo legt man am besten die neue Swap an? Direkt hinter Boot, oder ganz
ans Ende? (In der Extended lag sie ganz am Ende)
Uhu Uhuhu schrieb:> Wo legt man am besten die neue Swap an? Direkt hinter Boot, oder ganz> ans Ende? (In der Extended lag sie ganz am Ende)
von der Geschwindigkeit macht das keinen Unterschied - wenn das Swappen
losgeht ist die sowieso im Eimer.
Ich würde den Swap in ein LVM-Volume innerhalb des LUKS-Containers
packen damit der mit verschlüsselt wird. Wenn ansonsten Dein ssh-agent
mal rausgeswappt wird...
Entweder das oder auf eine vom LVM unabhänge Partition, die auch
verschlüsselt ist, aber ohne LUKS, sondern mit einem temporären
Schlüssel, der beim Booten generiert wird und damit wird die
Swap-Partition jedes Mal neu initialisiert. Der Key geht mit dem Verfall
des RAM-Inhalts nach dem Runterfahren verloren. Dann muss er nicht mal
im Hauptcontainer hinterlegt werden.
z.B. drei Partitionen:
|--------------------|
| boot |
|--------------------|
| swap |
|(dm-crypt, temp Key)|
|--------------------|
| LVM-PV |
| (LUKS) |
|--------------------|
Die Details sind größtenteils Geschmackssache. Oder teilweise diktiert,
wenn man z.B. noch andere Systeme dualbooten muss, die weniger flexibel
sind.
Paritioniere eigentlich immer als GPT. Die vielen Einträge brauche ich
nicht, aber schon alleine die Möglichkeit, sprechende Namen (z.B.
hostname:volume-name) mit in der GPT abzulegen und Platten ungeachtet
ihrer Größe gleich zu behandeln ist es mir wert. /boot beginnt bei
Sektor 2048 und ist 99MiB groß, so dass die folgende Partition bei
100MiB beginnt. Das ist dann entweder /, gefolgt von swap und weiteren
(Hauptkandidat /srv) oder meistens ein LVM-PV, in dem sich /, swap und
weitere befinden. Je nach Bedarf mit oder ohne Verschlüsselung.
Thread beobachten
Seitenaufteilung abschalten