[nicht lösbar]/etc/crypttab und systemd

[debianoli]

Hallo,

ich habe mir Jessie installiert und nur mein Home-Verzeichnis per luks verschlüsselt. Dies entsperre ich durch einen Eintrag in der /etc/crypttab, wodurch ich während des Boot-Vorgangs mein Passwort eingeben muss.

Das funktioniert unter Wheezy ganz gut, das System warted, bis ich das Passwort eingegeben habe. Bei Jessie allerdings mach systemd Terror und sagt etwas von einem Prozess der in 1 Min 30 Sek startet. Auch schreibt mit systemd immer etwas in die Zeile während der Passwort eingabe. Die funktioniert trotzdem

Fragen: Ist der EIntrag in der /etc/crypttab für systemd noch nötig oder muss ich dafür bei systemd etwas anderes eintragen?

Kann man systemd dazu zwingen, abzuwarten bis ich mein Passwort eingegeben habe? Mir ist die Bootzeit soweit egal, ich will erst mein Passwort in Ruhe eingeben, ehe das System ganz bootet.

[rendegast]

Vielleicht klassisch?

Code: Alles auswählen

aptitude install sysvinit-core

Vor dem Rebooten kontrollieren, ob /sbin/init erstellt wurde (kein Link mehr auf systemd).

[debianoli]

Du würdest systemd einfach runterschmeisen? Das wäre auch eine Option, an die ich gedacht hatte.

Allerdings würde ich auch gerne wissen, wie man das mit den Bordmitteln von systemd löst. Das muss doch irgendwie gehen. Mir würde auch ein Hinweis auf die dafür zuständigen systemd-Komponenten reichen. Denn man systemd wirft einiges aus und verweist dabei auf die man-Pages der einzelnen Komponenten. Das sind rund 12 oder so.

[schwedenmann]

Hallo


Ich kann dieses Verhalten nicht nachvollziehen.

Habe selbst ein encryptetes physikalisches device mt 4 LVM drau. Das entsperrren per passphrase nach dem Booten klappt problemlos, incl. systemd auf Debian-Sid kernel 3.16.0-4 .


mfg
schwedenmann

[rendegast]

Habe selbst ein encryptetes ...

Glück gehabt? Schlauer durchgeführt?
Erklärung des Problems oder Lösung?

Denn man systemd wirft einiges aus und verweist dabei auf die man-Pages der einzelnen Komponenten. Das sind rund 12 oder so.

Ich denke da eher an

Code: Alles auswählen

# systemctl | wc -l
212
# systemctl -a | wc -l
431

Wobei durch das undifferenzierte(?) Parallelstarten womöglich mehr als 12 in Betracht kämen.
Ein

Code: Alles auswählen

$ apt-get -s purge systemd-sysv systemd
HINWEIS: Dies ist nur eine Simulation!
         apt-get benötigt root-Privilegien für die reale Ausführung.
         Behalten Sie ebenfalls in Hinterkopf, dass die Sperren deaktiviert
         sind, verlassen Sie sich also bezüglich des reellen aktuellen
         Status der Sperre nicht darauf!
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
   sysvinit-core (2.88dsf-58)
Die folgenden Pakete werden ENTFERNT:
   libpam-systemd* (215-11)
   systemd* (215-11)
   systemd-sysv* (215-11)
Die folgenden NEUEN Pakete werden installiert:
   sysvinit-core (2.88dsf-58)
0 aktualisiert, 1 neu installiert, 3 zu entfernen und 1 nicht aktualisiert.
Purg libpam-systemd [215-11]
Purg systemd-sysv [215-11] [init:amd64 ]
Inst sysvinit-core (2.88dsf-58 Debian:unstable [amd64])
Conf sysvinit-core (2.88dsf-58 Debian:unstable [amd64])
Purg systemd [215-11]

(zumindest hier, und bis heute)
erscheint mir da eine praktikable Alternative.
<->
Meine lvm hier (ohne crypt) starten gelegentlich(!) nicht rechtzeitig, welche Schraube drehen? In welche Richtung?

Code: Alles auswählen

# dpkg-query -L lvm2 | grep systemd
/lib/systemd
/lib/systemd/system
/lib/systemd/system/lvm2-activation-early.service
/lib/systemd/system/lvm2-activation.service
/lib/systemd/system/lvm2-lvmetad.service
/lib/systemd/system/lvm2-lvmetad.socket
/lib/systemd/system/lvm2-monitor.service
/lib/systemd/system/lvm2-pvscan@.service
/lib/systemd/system/lvm2.service -> lvm2-activation.service

[schwedenmann]

Hallo

Glück gehabt? Schlauer durchgeführt?
Erklärung des Problems oder Lösung?

Oder anderrum wird ein Schuh draus, es hat nichts mit systemd zu tun.

Das ist ne alte Konfiguration , noch vor systemd

mfg
schwedenmann

[rendegast]

Oder anderrum wird ein Schuh draus, es hat nichts mit systemd zu tun.
Das ist ne alte Konfiguration , noch vor systemd

Ich beziehe das jetzt auf mein Problem, da oben "ich habe mir Jessie installiert".
Bei mir wheezy->jessie ist der Zustand

Code: Alles auswählen

# find /etc/systemd | grep lvm | sort
/etc/systemd/system/local-fs.target.wants/lvm2-activation-early.service
/etc/systemd/system/local-fs.target.wants/lvm2-activation.service
/etc/systemd/system/sysinit.target.wants/lvm2-lvmetad.socket
/etc/systemd/system/sysinit.target.wants/lvm2-monitor.service

und das entspricht dem eines frisch aufgesetzten jessie resp. neu installiertem lvm2 (vorher keine "rc lvm"-Reste).

[debianoli]

Oder anderrum wird ein Schuh draus, es hat nichts mit systemd zu tun.

Das ist ne alte Konfiguration , noch vor systemd

Dann sag mir, wie ich eine mit Luks verschlüsselte Partiton am besten mit Systemd einbinde? Per /etc/crontab wird die verschlüsselte Partition mit e2fsck beim Hochfahren geprüft.

Zudem: Ich nutze kein LVM. Das ist ein älteres BIOS-Netbook mit einer Festplatte und 4 primären Partitionen: 1 x Swap, 1 x Home und 2 Partitionen für jeweils ein System.

Ich habe mein /home seit Squeeze verschlüsselt und installiere immer in eine freie Partition ein "neues" Debian. Der richtige Wechsel auf eine andere Debian-Version kommt erst, wenn ich mit dem neu aufgesetzten System zufrieden bin. Was bei Testing für mich Sinn macht.

[debianoli]

Das ist jetzt meine Lösung. Dann warte ich mit dem EInsatz von systemd wohl noch etwas ab...

Vielleicht klassisch?

Code: Alles auswählen

aptitude install sysvinit-core

Vor dem Rebooten kontrollieren, ob /sbin/init erstellt wurde (kein Link mehr auf systemd).

[Lord_Carlos]

Meine crypttab mit debian testing sieht so aus:

Code: Alles auswählen

sdb6_crypt UUID=86d9a130-5989-4b9c-b461-e7b4a6f0d520 none luks

Password wird ohne Probleme beim starten abgefragt. Systemd ist vorhanden.

Eingerichtet hat das ganze die Installation, ich glaube nicht das ich da viel veraendert habe.

[debianoli]

Password wird ohne Probleme beim starten abgefragt. Systemd ist vorhanden.

Meine crypttab sieht genauso aus. Das Passwort wird auch abgefragt, allerdings laufen dabei immer irgendwelche Infos von sytsemd über den Bildschirm und warnen mich vor einem Prozess, der in 1 Min 30 eine entsperrte Partition erwartet. Das wollte ich abstellen oder zumindest verstehn, welcher Dienst das wie macht.

[Lord_Carlos]

Achso, das habe ich falsch verstanden.

[Sigi44]

Ich habe exakt dieselbe Lage und dasselbe Problem wie Debianoli.

Ich vermute die Abhängigkeiten bei den Init-Skripten sind nicht sauber programmiert. Es wird schon versucht, die crypt-Dateisysteme zu mounten, obwohl das Passwort noch gar nicht eingegeben wurde.

Ich habe das Problem jetzt für mich gelöst, in dem ich die luks-Partition jetzt nicht direkt mounte, sondern sie als LVM physical volume verwende. Die LVM-Init-Skripte sind ausgereifter. Dort wird dann gewartet, bis man das Passwort für cryptsetup eingegeben hat, bevor LVM versucht, dass PV zu verwenden und dann das Logical Volume zu mounten.

Da die Probleme mit dem crypt-fstab bei libpam-mount beim Nicht-sequentiellen Booten schon seit Squeeze bestanden (Abhilfe damals mit "echo 'CONCURRENCY=none' >> /etc/default/rcS") habe ich da jetzt keine Lust mehr zu gehabt zu warten bis das endlich mal gefixt ist und habe noch mal den LVM-Layer dazwischen geschoben, damit es einfach funktioniert.

Bonus-Frage: Wie kann man es hinkriegen, dass ewig auf die Passwort-Eingabe bei cryptsetup gewartet wird? Derzeit wird wohl nur 90 s oderso gewartet, danach geht das System in den "Emergency Mode" und reagiert nicht mehr.

[NAB]

Systemd aus Jessie ist veraltet, das kann das noch nicht. Ein aktuelleres Systemd sollte demnächst in Testing einziehen:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=765015

Alternativen: sysvinit verwenden oder plymouth verwenden.

[Sigi44]

Bonus-Frage: Wie kann man es hinkriegen, dass ewig auf die Passwort-Eingabe bei cryptsetup gewartet wird? Derzeit wird wohl nur 90 s oderso gewartet, danach geht das System in den "Emergency Mode" und reagiert nicht mehr.

So bekommt man es hin, dass beim Hochfahren zehn Minuten auf die Eingabe des korrekten Passwortes gewartet wird (zwei Versuche der Eingabe), und bei Ablauf der Auszeit oder zweimaliger falscher Eingabe des Passwortes ohne Murren weiter gebootet wird:

/etc/crypttab

Code: Alles auswählen

data            UUID=467114ab-111b-4115-9811-e8911f1aec0f       none            luks,x-systemd.device-timeout=11min,timeout=10min,tries=2

/etc/fstab
Hier bei den Mount-Optionen für UUID=467114ab-111b-4115-9811-e8911f1aec0f
"nofail" zufügen!