Falsches Geli-Passwort mit neuem Kernel (9.0 RC2)

Sickboy

Müßiggänger
Moin,

ich habe unter 9.0 RC2 einen neuen Kernel gebaut. Leider sagt mir Geli jetzt beim Booten, dass das Passwort für meine verschlüsselten Partitionen falsch sei. Wenn ich aber in den Single-User-Modus boote und die Partitionen manuell mit Geli attache, klappt alles:
Code:
# mount -u /
# mount -a -t ufs
# geli attach -k /root/ada0p7.key /dev/ada0p7
# mount /dev/ufs/homecrypto /home

Weiß jemand von euch, woran das liegen könnte?
 
Das hatte ich auch letztens Mal. Ich habe danach aber mehrmals neuinstallieren müssen und nun tritt das Problem nicht mehr auf. Ich weiß nicht genau woran das liegt, kann aber nochmal checken ob ich an irgenwelchen Schrauben gedreht habe im aktuellen Setup.
 
Könnte auch an der Tastatur liegen, hab das selbe Problem hier.
Mit einer über USB angeschlossenen Tastatur geht es wunderbar, aber sobald ich über PS/2 versuche mein Passwort einzugeben muss ich den Hammer benutzen. ;)

Ein Hinzufügen von kern.geom.eli.visible_passphrase=2 in der /boot/loader.conf macht dir sichtbar, ob die Tastenanschläge angenommen werden.

https://forums.freebsd.org/showthread.php?t=1358
 
Vielleicht wurde ja etwas geforkt und ein anderer Prozess hat stdin. Was sagt denn CTRL+T? Was passiert wenn du CTRL+D drückst und danach noch mal eine Eingabe probierst? Oder als letztes Mittel CTRL+C.
 
Noch mal zur Klarstellung: Wann hat er raus, bzw. wann fragt er nach dem Passwort? Vor dem Root-Mount (weiße Schrift) oder nach dem Root-Mount (graue Schrift) Denn irgendwie geht's hier gerade ein wenig durcheinander. :)
 
Eingabe zeigt nichts an, auch keine Sternchen. Eingeben kann ich aber anscheinend etwas, weil die Enter-Taste während der Eingabe ja funktioniert.

@Yamagi: Schrift bei der Passwortabfrage ist grau. Die kommt auch nach "Trying to mount root from ufs:/dev/ufs/root [rw] ...".
Wie gesagt, wenn ich dreimal das falsche Passwort eingeben bzw. Strg+C drücke, komme ich in den SU-Modus und kann per Hand mounten.
 
Mir ist erst jetzt aufgefallen, dass GELI sagt:
Code:
Enter passprase:
geli: Provider ad0p7 is invalid.

Hat das, mal ganz dumm gefragt, was zu bedeuten?
 
Welche Version hast du denn vor 9.0-RC2 verwendet? Mit FreeBSD 9 ist AHCI standardmässig aktiviert und SATA-Geräte heissen damit adaX und nicht mehr adX. Die Fehlermeldung legt nahe, dass da etwas nicht mehr stimmt. Soweit ich weiss, sollte allerdings die alten Namen auch noch gültig sein. Ein Indiz dafür ist eine Meldung à la:
Code:
ada0: Previously was known as ad0

mousaka
 
Hatte vorher 8.2 am Laufen. AHCI wird ja in der /etc/rc.conf geladen. Wenn ich im SU-Modus nach "gpart show ada0" schaue, werden die Partitionen auch angezeigt. Mit dem GENERIC-Kernel von 9.0 RC2 hatte ich die Probleme nicht. In der Kernconf hab ich aber nur RAID, Firewire und ein paar Ethernet/WLAN-Karten auskommentiert.
 
Dies legt nahe, dass du etwas zu viel in den der Kernel-Konfiguration auskommentiert hast.:grumble: Oder hast du kern.cam.ada.legacy_aliases=0 gesetzt?

Wenn ich es richtig sehe gibt es zu deinem Prlobem den (offenen) PR 160409.

Irgendjemand kann dir sicher sagen wie du geli dazubringst ada0 anstelle von ad0 zu verwenden. Ich leider nicht. ;)

mousaka

PS: ahci muss nicht mehr explizit geladen werden.
 
Dies legt nahe, dass du etwas zu viel in den der Kernel-Konfiguration auskommentiert hast.:grumble: Oder hast du kern.cam.ada.legacy_aliases=0 gesetzt?
Wird wohl so sein, auch wenn ich da keine Verbindung zu GELI erkennen kann. legacy_aliases=0 hab ich nicht gesetzt.

Irgendjemand kann dir sicher sagen wie du geli dazubringst ada0 anstelle von ad0 zu verwenden. Ich leider nicht. ;)
Np, ich werd nachher noch mal den Kernel backen.

PS: ahci muss nicht mehr explizit geladen werden.
Danke für die Info.
 
Das hatte ich bei meinem Laptop auch vom Wechsel auf 8.2 nach 9.0beta-irgendwas. Nach den Anpassungen in /boot/loader.conf und /etc/rc.conf sowie /etc/fstab war aber alles gut. Allerdings hatte das System bei mir gar keine Platten mehr gefunden ;).
 
Ich hatte *genau dieselben* Probleme wie Sickboy, ich hatte keine custom kernel und keine besonderen Variablen gesetzt, einfach über die Skriptmethode auf gpt installiert. Ich kann es gerade nicht überprüfen, ob ich durch setzen von Variablen (habe da mit diversen timeouts rumgespielt) das gelöst habe oder durch Neuinstallation.
 
das hat zwar nur indirekt mit der Sache zu tun, aber es erstaunte mich nach dem Update von 8.2RELEASE auf die 9.0RC2 ein gewisses Durcheinander in den Benennungen der SATA-Platte zu sehen. Es schien mir wild durcheinander mal ada0 und dann wieder das alte, bisher benutzte ad4 zu erscheinen.
Ein Blick in /dev zeigte dann, dass hier von ad4 nach ada0 Links gelegt worden waren, so dass beide Namen nun quasi identisch benutzt werden können.
Also, nur um das klar zu sagen: ich habe das nicht gemacht ;-)
Das ging ganz automatisch so.
 
@pit234a
Das "Durcheinander" ist Absicht, um den Umstieg auf ahci zu vereinfachen. Sauber ist wie makenoob geschrieben hat, alle Einträge den neuen Gegebenheiten anzupassen. Ein sauber konfiguriertes 9.0 sollte auch mit kern.cam.ada.legacy_aliases=0 funktionieren. Alles andere sind Übergangslösungen, die einem das Leben erleichtern, aber eben auch für ein "Durcheinander" sorgen können.

mousaka
 
Hi,
das hört sich alles nach mit und ohne AHCI Support bärig an. Setz mal in der /boot/loader.conf en ahci_load="YES" bärig oifach und gugg obs besser wird. [sollte nicht nötig sei bei dem 9er - könnte vielleicht helfen - Versuch ist es wert]

(ja, des gibt dann adaX)

Gruß Bummibär
 
Hi,
das hört sich alles nach mit und ohne AHCI Support bärig an. Setz mal in der /boot/loader.conf en ahci_load="YES" bärig oifach und gugg obs besser wird. [sollte nicht nötig sei bei dem 9er - könnte vielleicht helfen - Versuch ist es wert]

(ja, des gibt dann adaX)

Gruß Bummibär
Hatte ich die ganze Zeit drin.

Nun hab ich den GENERIC-Kernel noch mal kompiliert (weil ich nicht dran gedacht habe, ihn zu sichern), aber mit dem funktioniert es auch nicht mehr. Ich glaub, es ist fast das beste, wenn ich /home sichere und komplett neuinstalliere. *narf*
 
Hi,

Lösung beim Bär:

Verdacht des Bären wenn mer Ctrl. D macht dann seh ich die Eingabe und es tut immer noch ned. Sieht so aus als hätte wohl jemand meine Tastatur oder deren Eingabe entführt.
Folgendes funktioniert: 3x falsch eingeben oder oifach gleich Enter drücken - danach /bin/sh und dort einfach /sbin/geli attach -k /key /dev/ada0p3 eingeben und Passphrase neijagen und bingo es tut - exit und das wars - es bootet weiter.

Teste mal aus ob nach 3x falsch mit Enter und in /bin/sh dann manuell fix attach machen es bei Dir auch geht.

Gruß Bär
 
Zurück
Oben