LUKS, EXT4 & resize2fs | LVM

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
jko
Beiträge: 19
Registriert: 20.02.2014 15:46:08

LUKS, EXT4 & resize2fs | LVM

Beitrag von jko » 07.03.2014 10:25:39

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

Benutzeravatar
peschmae
Beiträge: 4844
Registriert: 07.01.2003 12:50:33
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: nirgendwo im irgendwo

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von peschmae » 07.03.2014 13:02:31

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ä
"er hätte nicht in die usa ziehen dürfen - die versauen alles" -- Snoopy

jko
Beiträge: 19
Registriert: 20.02.2014 15:46:08

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von jko » 07.03.2014 16:22:11

peschmae hat geschrieben: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.
Zuletzt geändert von jko am 07.03.2014 17:21:45, insgesamt 1-mal geändert.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von wanne » 07.03.2014 17:05:17

Ja, parted kennt kein LUKS und will immer dateisysteme mitverkleinern. Nimm (c)fdisk. Oder für gpt (c)gdisk.
rot: Moderator wanne spricht, default: User wanne spricht.

jko
Beiträge: 19
Registriert: 20.02.2014 15:46:08

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von jko » 07.03.2014 19:02:42

wanne hat geschrieben: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
Beiträge: 19
Registriert: 20.02.2014 15:46:08

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von jko » 07.03.2014 23:30:08

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
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von wanne » 08.03.2014 21:17:34

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.
rot: Moderator wanne spricht, default: User wanne spricht.

dirk11
Beiträge: 2812
Registriert: 02.07.2013 11:47:01

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von dirk11 » 08.03.2014 23:19:02

wanne hat geschrieben: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
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von wanne » 09.03.2014 00:32:49

dirk11 hat geschrieben: 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.
rot: Moderator wanne spricht, default: User wanne spricht.

jko
Beiträge: 19
Registriert: 20.02.2014 15:46:08

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von jko » 09.03.2014 21:24:08

wanne hat geschrieben: [*]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
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von wanne » 10.03.2014 00:07:16

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.
rot: Moderator wanne spricht, default: User wanne spricht.

jko
Beiträge: 19
Registriert: 20.02.2014 15:46:08

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von jko » 20.03.2014 19:38:13

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
Beiträge: 2812
Registriert: 02.07.2013 11:47:01

Re: LUKS, EXT4 & resize2fs | LVM

Beitrag von dirk11 » 20.03.2014 20:32:57

jko hat geschrieben:GPT funktioniert nur mit EFI?
Nö. Auch mit oldschool-BIOS. Man benötigt GPT aber nur bei Platten >2TB.

Antworten