LUKS, EXT4 & resize2fs | LVM

[jko]

Hallo Forum,

folgendes Problem:

Meine HDDs sind aufgeteilt in:
-------------------------------------------------------------------------------------------
2 LVM Volumgroup + 2 LUKS Container
*) VG root
-> / /tmp /var /usr
*) VG data
-> Daten Raid mit extra Mountpoint (betrifft das Problem nicht)
*) Luks AES Container (nicht im LVM!)
/home und swap
--------------------------------------------------------------------------------------------

Jetzt ist mir das /usr LV voll gelaufen. Mein /home LUKS hat
aber noch viel Platz frei (80 GB+) oder so. Daher wollte ich
die /home partition verkleinern um danach der VG root und
danach dem /usr mountpoint den Platz zu geben.

Daraufhin hab ich /home ausgehängt (umount) um
im init 1 (single shell) ein resize2fs auf die Partition
(/dev/mapper/sdx4_crypt) zu starten. Sprich auf den Mapper.
Die Partition mit dem LUKS Container wäre dann /dev/sdx4.
Leider hab ich vorher vergessen denn Container mit
cryptsetup zu schließen
Trotzdem hat das resize2fs funktioniert und mir
laut df die Mapper Partition um 20 GB verkleinert.
cryptsetup status sdx_crypt liefert aber noch die
alte Größe. Sprich irgendwie muesste ich jetzt
/dev/sdx auf die größe von /dev/mapper/sdx_crypt
anpassen. Dadurch muesste sich der LUKS
Container verkleinern und auf der Festplatte
Platz freigeben den ich dann der VG zuordnen
könnte in dem meine /usr LV auf Platz wartet.

Geht das? Wenn wie?

Freu mich auch über links zu doku von LUKS Containern.

grüße
jko

[peschmae]

Soweit ich das also verstanden habe, hast du bisher dein ext4 verkleinert, was auf einer Luks-Partition liegt? Als nächstes musst du nun den Luks-Container entsprechend verkleinern - das geht mit cryptsetup --size 10924 resize /dev/sda812

Wobei du bei --size die Zielgrösse (in vielfachen von 512 byte) und am Ende das das device auf dem der Luks container liegst angibst. Wenn die --size zu klein ist (kleiner als dein ext4) dann verlierst du dabei Daten!

Daran anschliessend musst du noch die Partition verkleinern....

MfG Peschmä

[jko]

Als nächstes musst du nun den Luks-Container entsprechend verkleinern
Daran anschliessend musst du noch die Partition verkleinern....

Ok den Container hab ich verkleinert. parted liefert mir jetzt allerdings
Error: /dev/sdx: unrecognised disk label
zurück wenn ich partitionieren will?

[EDIT
fdisk erkennt die Partition auch nicht (unallocated 512-byte sectors)

D.h. parted und fdisk erkennen die Partion mit dem LUKS
nicht.

[wanne]

Ja, parted kennt kein LUKS und will immer dateisysteme mitverkleinern. Nimm (c)fdisk. Oder für gpt (c)gdisk.

[jko]

Ja, parted kennt kein LUKS und will immer dateisysteme mitverkleinern. Nimm (c)fdisk. Oder für gpt (c)gdisk.

Stimmt mit fdisk funktionierts...

Und jetzt als letztes noch den neuen freien Platz der HDD der VG bzw.
dem LVM zuweisen. Geht das? [EDIT] Leider kann ich gerade keine
primären Partitionen mehr anlegen (sind schon vier) und wenn ich die LUKS auf
extended setze funktioniert sie nicht mehr. [/EDIT]
Der freie Platz liegt ja jetzt am Ende der Platte (zuvor kommt das LUKS und davor dann das LVM).
Funktioniert das ohne das ich das LUKS überschreibe (LVM vergrößern).
Will nach der sectoren mathematik jetzt nich noch einen dummen
Fehler machen

[EDIT]
Mist schon passiert. Hab versucht die LUKS Partition auf extended zu
setzen statt auf primary und die partionstabelle geschrieben. Seit dem startet
die LUKS partition nicht mehr!

[EDIT]
Also den luks header mit cryptosetup zu backupen ist sehr empfehlenswert!
So hab ich die partition wieder herbekommen... [/EDIT]

[jko]

Also den luks header mit cryptosetup zu backupen ist sehr empfehlenswert!
[/EDIT]

nach ein paar Crash's ein Versuch hier eine Lösung
zu finden:

Meine derzeitige Partionstabelle (SSD)
1) /dev/sda1, ext2, /boot, primäre Partition
2) /dev/sda2, LUKS_crypto, swap, primäre Partition
3) /dev/sda3, LVM2, / /tmp /usr/ /var, primäre Partition
4) /dev/sda4, LUKS Container, /home, primäre Partition
5) 20 freie GB

Biser geschehen: resize von /dev/sda4 (-20GB)

Versucht habe ich: /dev/sda2 als auch /dev/sda4 auf extended umzustellen was
jedesmal zu einem crash geführt hat und ich die Header der Partition
wiederherstellen musste. Dann wäre ein anbinden von den 20GB
an 3) recht einfach. (als eigene Partition)

Hat jemand eine Idee wie ich das bewerkstelligen kann die 20 GB
an /dev/sda3 zu hängen?

[wanne]

Für die Zukunft: Niemals 4 Primäre Partitionen anlegen. Am besten gleich von Anfang vielleicht 1 oder 2 Primäre an den Anfang legen und ab dann Logische benutzen. Es gibt glaube ich nur noch LILO, der nicht mit logischen zurecht kommt.
Da wäre hilfreich (Damit man nicht umrechnen muss gleich in 4 facher Ausführung ):

Code: Alles auswählen

sfdisk -l -u S /dev/sda
sfdisk -l -u B /dev/sda
sfdisk -l /dev/sda

Wenn die Partitionen in der Reihenfolge sind und nirgends freier platz dazwischen ist hast du wohl ein relativ hässliches Problem, weil du die sda3 nicht anfassen willst, weil die in deiner initrd hängt und die so ziemlich in der Mitte hängt.
Die sauberste Methode ist wohl ein Backup und dann Neu partitionieren.
Sonst würden mir folgende (wirklich) dirty hacks einfallen:

• sda2 löschen und den Freien unpartitionierten Platz in ein loopAES packen. (da kann man sda und ein offset angeben) Dann hättest du die sda2 für die letzten 20GiB. Achtung offset wird in 512 byte blücken angegeben. Wenn du dich da verrechnest schreibt der dir den SWAP knadenlos dahin egal was da sonst ist!
• / den LUKS-Container darauf und sda3 Um ein einen cylinder verkleinern. Dann kannst du dahinter eine Extended bis zum Ende hinpacken und sda5 dann genau da anfangen lassen wo jetzt sda4 anfängt. danach kannst du die /etc/crypttab auf anpassen und sda4 durch sda5 eretzen.
• sda2 löschen und durch eine Erweiterterte von da bis zum ende erstellen (sfdisk -f kann das obwohl da schon sda3 und sda4 drauf liegt) sda5 wird dann die neue LUKS für swap sda6 kannst du dann hinter sda4 packen. (Achtun -f erlaubt dir wunderbar auch die Partition auf eine andere Zu legen, was dann zu ziemlich unbrauchbarem Datensaalat führt. ) Sowas geht eigenltich nicht aber der Linux-Kernel sollte mit zurecht kommen. Hat den Vorteil dass / unangetastet bleibt und du mit einem Backups MBR wieder auf jeden fall / und /boot hast.
• gdisk kann MBR-Partitionen in GPTs umwandeln. Ich weiß nicht wie zuverlässig das funktioniert aber danach hast du 128 Mögliche Partitionen.

Wenn du zu einer Möglichkeit mehr infos willst, kann ich das noch etwas ausführlicher beschreiben.

Allgemein: Wenn du mit sfdisk arbeitest: probier das vorher aus. Der will immer den Anfang und die Größe von allen Partitionen wenn du da was weglässt bleibt die Partition nicht gleich sondern wird gelöscht außerdem solltest du beim kopieren aufpassen, dass du die gleich Einheit (-u) eingestellt hast.

[dirk11]

Es gibt glaube ich nur noch LILO, der nicht mit logischen zurecht kommt.

Es ist bestimmt ein halbes Jahrzehnt her, dass ich LiLo benutzt habe, aber an derlei Probleme kann ich mich nicht erinnern.

[wanne]

aber an derlei Probleme kann ich mich nicht erinnern.

OK dann kann wohl auch LILO mit Logischen boot-Partitionen umgehen. Noch ein Grund weniger Primäre zu nutzen.

[jko]

[*]gdisk kann MBR-Partitionen in GPTs umwandeln. Ich weiß nicht wie zuverlässig das funktioniert aber danach hast du 128 Mögliche Partitionen. [/list]
Wenn du zu einer Möglichkeit mehr infos willst, kann ich das noch etwas ausführlicher beschreiben.

Allgemein: Wenn du mit sfdisk arbeitest: probier das vorher aus. Der will immer den Anfang und die Größe von allen Partitionen wenn du da was weglässt bleibt die Partition nicht gleich sondern wird gelöscht außerdem solltest du beim kopieren aufpassen, dass du die gleich Einheit (-u) eingestellt hast.

Danke erstmal. Die ersten Variationen hab ich im Ansatz bereits versucht. Erstmal muss ich meinem System V irgendwie
beibringen das das crypto swap nicht mehr funktioniert Sonst hängt der Kernel beim booten.

Ansonsten klingt das mit gpt interessant. Werde mir das mal ansehen. Ist das nicht eher etwas für UEFI und Windows
und so?

[wanne]

Eigentlich ist GPT einfach ein anderes Partitionierungsformat. EFI ein BIOS ersatz. Windows 8 ein Betriebssystem.
Nur Microsoft hat da einiges zusammengemixt. Da funktionieren wohl nicht so ganz alle Kombinationen miteinander. Oder bekommen zumindest kein Logo.
Ich muss allerdings sagen, dass ich noch nie produktiv eine DOS-Partitionstabelle in eine GPT umgewandelt habe. Ich weiß nur das gdisk das macht, wenn man es auf eine normale Partitionstabelle loslässt.
Ich weiß auch nicht ob jeder Bootloader da problemlos mit zurechtkommt.

[jko]

Die Frage wäre jetzt halt noch EFI als BIOS Ersatz für Windows? Aber
ich glaub Android ist damit auch schon ganz gut?

GPT funktioniert nur mit EFI?

Also ich bin momentan vorsichtig. System V ist bei jessie schon noch
aktuell oder schon systemd? Würde gerne mal meine Cryptoverzeichnisse
aus dem boot Prozess nehmen... Das müsste doch gehen.

[dirk11]

GPT funktioniert nur mit EFI?

Nö. Auch mit oldschool-BIOS. Man benötigt GPT aber nur bei Platten >2TB.