debianforum.de

Folgende Situation: Der Installer vergibt bei einer verschlüsselten Partition einen "mapped device name" nach dem Schema sdax_crypt. Das x steht dann für die Nummer der Partition. Dieser "mapped device name" steht dann auch so auf der Target-Position in der crypttab, und es gibt einige Links die sich auf diesen Namen beziehen.

Ich habe jetzt eine Situation wo das sehr doof ist: ein Rechner mit einer m2-SSD am PCI-Bus als Boot- und Rootlaufwerk. Im Moment hängt die m2 als alleiniger Massenspeicher im Rechner. USB-Sticks sortieren sich dahinter ein, soweit ok. Wenn ich aber weitere SSDs oder Festplatten an SATA anschliesse, werden diese zuerst erkannt und bekommen der Reihe nach Devicenamen zugewiesen, die m2-SSD kriegt ein sdy nach allen anderen Festplatten/SSDs. Fürs Booten geht es wenn im Bios die m2-SSD angesprungen wird.

Ich würde den "mapped device name" jetzt gerne ändern. Wenn ich jetzt sdax_crypt in der crypttab einfach umbenenne, z.B. in ssdx_crypt und ein update-initramfs mache, kriege ich einen Fehler: Hab mich jetzt nicht getraut das scharf zu machen. Die Links auf sdax_crypt werden zum Bootzeitzpunkt angelegt, das sollte also eigentlich gehen. Wo muss ich denn da noch drehen?

Danke und Gruss, Rolf

Die Änderung wird auch erst nach Stoppen des crypt-device gemacht? <-> gegebenenfalls mit einer live-CD durchführen.

cryptsetup: WARNING: invalid line in /etc/crypttab for sdax_crypt -

Vielleicht mit unpassendem Editor gemacht? (Unsichtbare Steuerzeichen)

rendegast hat geschrieben:Die Änderung wird auch erst nach Stoppen des crypt-device gemacht?

Code: Alles auswählen

... umounten ...
... gegebenenfalls lvm stoppen ...
cryptdisks_stop sdax_crypt

<-> gegebenenfalls mit einer live-CD durchführen.

Hab das natürlich im laufenden Betrieb gemacht. Die crypttab liegt ja im Container. Allerdings habe ich eine VM auf meiner Workstation dazu missbraucht, und dann doch neu gebootet: geht natürlich nicht. Den PC selber wollte ich nicht riskieren bevor ich nicht weiss ob und wie es geht.

rendegast hat geschrieben:

cryptsetup: WARNING: invalid line in /etc/crypttab for sdax_crypt -

Vielleicht mit unpassendem Editor gemacht? (Unsichtbare Steuerzeichen)

Code: Alles auswählen

cat -A /etc/crypttab

Der Editor ist der gleiche den ich immer nehme: nano solange die graphische Oberfläche/das Netzwerk nicht verfügbar ist, dann geany. Hat bisher immer funktioniert. Beim nächsten Versuch werde ich da mal genau hinsehen.

Die Idee das über eine Life-DVD mit chroot zu machen könnte ich mal probieren. Kann ich eine VM-Maschine einfach z.B. von Knoppix booten? Hab ich noch nie versucht. Bei einem realen System habe ich so etwas schon mehrfach praktiziert um missglückte Aktionen wieder hinzubiegen.

Gruss Rolf

Nachtrag: habs probiert, man kommt mit Knoppix an die VM dran. Habe erst mal die Original-initrd wiederhergestellt und mal rebootet, die Maschine kommt wieder hoch, wenn auch mit etwas Bauchschmerzen wegen des verdrehten crypttab-Eintrags. Nach nen paar Fehlermeldungen kommt die richtige Entschlüsselung doch zustande mit dem Original-Mapped Device. Falsche Zeichen hab ich nicht drin.

So, und jetzt stecke ich fest und brauche Rat von Leuten mit mehr chroot-Erfahrung.

Randbedingung: Jessie mit /boot auf sda1 und verschlüsseltem root auf sda5 in VM.

Wo ich stehe:
- VM mit Knoppix 7.71 gebootet, root-Terminal geöffnet, in /mnt zwei neue Verzeichnisse boot und root angelegt, das verschlüsselte root geöffnet, die LVMs scharf gemacht.
- Knoppix erkennt die /boot-Partition als /media/sda1. Nach /mnt/boot gemountet, komme dran, ls -la zeigt normale Verhältnisse.
- Das root nach /mnt/root gemounted.
- Die crypttab in /mnt/root/etc ist gepatcht.
- Dann probiere ich ein: chroot update-initramfs /mnt/root -b /mnt/boot -u, es kommt die Meldung /mnt/boot sei kein Directory???? Lasse ich die -b-Option weg findet das update-initramfs das /boot nicht.

Was mache ich den da falsch?

Gruss, Rolf

Problem gelöst, es geht wenn man mit chroot richtig umgeht. Das Ubuntu-Wiki hat mir da weitergeholfen. Wieder was gelernt.

Gruss, Rolf

Etwa per das chroot vorbereitendem
mount --bind /mnt/boot /mnt/root/boot
mount --bind /dev /mnt/root/dev
(wohl noch weitere)
?
<->

- Dann probiere ich ein: chroot update-initramfs /mnt/root -b /mnt/boot -u, es kommt die Meldung /mnt/boot sei kein Directory???? Lasse ich die -b-Option weg findet das update-initramfs das /boot nicht.

rhHeini hat geschrieben:Problem gelöst

Kannst du bitte eine genaue Schritt-für-Schritt Anleitung preisgeben? Ich wäre da sehr dran interessiert, hab vor Tagen vergebens das selbe Versucht. (Was ist bei der chroot-Umgebung zu beachten?)
Ich konnte allerdings statt sdaX_crypt einfach ein mdX_crypt eintragen und es funktionierte. Ich will für "target name" aber gern einen beliebigen Namen vergeben.

Hier ist so etwas wie eine HowTo. Der Umgang mit chroot entspricht weitgehend dem Beitrag aus dem Ubuntu-Wiki https://wiki.ubuntuusers.de/chroot/Live-CD/.

* Auslesen der verwendeten Devices und der Original-crypttab. /boot liegt bei mir auf sda1, das verschlüsselte Device auf sda5, in der crypttab als sda5_crypt eingetragen. Es enthält ein LVM mit swap und root. Ausprobiert mit Jessie in einer virtuellen Maschine und dann mit Erfolg angepasst auf dem Rechner mit der m2-SSD.
* Knoppix booten.
* Terminal öffnen und mit su root-Rechte holen, oder gleich das root-Terminal verwenden.
* Das verschlüsselte System öffnen:
Verwende den neuen Wunschnamen für das Target, hier ssd5_crypt. * LVM einlesen: * Lvm-Volumes öfffnen: * Mounten: * Weitere Systemdirectories einbinden:
* Es erfolgt der Wechsel in das installierte System: * Die crypttab umeditieren auf den neuen Targetnamen.
* Update der initramfs.
* Die chroot-Umgebung mit exit verlassen und neu booten.

Mehr war nicht nötig.

Viel Erfolg, Rolf

Vielen Dank!

rhHeini hat geschrieben:Verwende den neuen Wunschnamen für das Target, hier ssd5_crypt.

Code: Alles auswählen

# cryptsetup luksOpen /dev/sda5 ssd5_crypt

Dieser Schritt wars den ich wohl nicht ganz kapiert hatte. Man muss hier schon den zukünftigen gewünschten Namen eingeben! Der Rest hängt dann von "target device" und der UUID ab.