Du bist nicht angemeldet.

#26 30.05.2019 13:31:26

cipher
Mitglied

Re: ecryptfs Home Verzeichnis fehler

TBone schrieb:

@cipher Funktioniert es mit dem lts kernel?

Nie Probiert. Was muss ich da tun?

Offline

#27 30.05.2019 13:52:35

cipher
Mitglied

Re: ecryptfs Home Verzeichnis fehler

GerBra schrieb:

Zwei andere Dinge, die aber mit o.A. zu tun haben könnten:
//Edit: bitte beide Dinge unten(a und b) getrennt voneinander ausprobieren, sonst kann man nicht sagen was nun geholfen hätte.

a) Nutzt du das Intel-Microcode-Update Paket, ist also das Paket intel-ucode bei dir installiert und auch im Bootmanager aktiviert?
https://wiki.archlinux.org/index.php/Microcode
Wenn nein, dann würde ich das mal tun.

b) In deiner dmesg-Ausgabe sieht man an den Zeiten eine große "Lücke" zwischen den Kernelmeldungen bis hin das der
Random-Number/Entropie-Kernelteil schließlich einsatzbereit wäre:

[    7.590280] Bluetooth: BNEP socket layer initialized
[   12.564143] audit: type=1131 audit(1559057961.084:28): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   13.739108] random: crng init done
[   13.739119] random: 7 urandom warning(s) missed due to ratelimiting

Das *könnte* ein Hinweis darauf sein, das bestimmte Funktionen im Zusammenspiel von Hardware und Kernel ebenfalls nicht ordnungsgemäß initialisiert worden sind, und schlußendlich beim Versuch das Modul trusted zu laden eben zu jener "bad address"-Meldung führen. Festplattenverschlüsselung ist hochgradig von einem funktionierendem Komplex bei Zufallszahlengenerierung und Entropie abhängig.
Dagegen kannst du zweierlei Dinge tun:
1. Wenn deine CPU es unterstützt, also wenn

lscpu |grep rdrand

eine Ausgabe ergibt, dann kannst du

random.trust_cpu=on

zu deinen Kernelparametern hinzufügen und damit booten und testen.
2. Oder du installierst und aktivierst dir das Paket haveged
https://wiki.archlinux.org/index.php/Haveged
Beides ermöglicht dem Kernel/System im frühzeitigen Stadium schon genug "zufällige Ereignisse" zu verwerten, um daraus wirklich "zufällige Zahlen/Werte" zu generieren. Siehe auch:
https://wiki.archlinux.org/index.php/Ra … _generator
Das sollte zu einem die o.a. "Lücke" im dmesg-Ausgabe verkleinern, also auch zu einem schnelleren Boot führen. Und behebt ggf. (meine Hoffnung) auch, das eben die notwendigen Module für encryptfs geladen werden könnten.

a) Das Paket intel-ucode ist bei mir nicht installiert

b) $ lscpu | grep rdrand ergibt keine Ausgabe. Wird also nicht unterstützt.
Habe das Paket haveget installiert, aktiviert und gestartet.
Leider kommt immer noch 'Bad address'

Offline

#28 30.05.2019 14:40:34

cipher
Mitglied

Re: ecryptfs Home Verzeichnis fehler

@TBone
War gar nicht so schwer. ;-)
Danke für den Tip. Ich kannte den arch LTS-Kernel nicht. Mit dem LTS-Kernel funktioniert alles wieder. Ist keine Dauerlösung aber ich komme wieder an meine Dateien ran ohne Live-CD.


@ all
Mit dem LTS Kernel läuft alles wieder wie gewohnt.

Das Modul 'trusted' lässt sich laden
Das Modul 'ecryptfs' lässt sich laden
Mein Home-Verzeichnis ist wieder da.
Als Interimslösung eine gute Lösung, aber mir wäre wichtig herauszufinden wo es beim aktuellen Kernel klemmt. Irgendwann wird der LTS-Kernel ja auch mal auf ein neues Major-Release angehoben, und dann geht es eventuell von vorne los.

Wenn noch jemand eine Idee hat bitte melden.

Offline

#29 30.05.2019 18:33:11

k.osmo
Mitglied

Re: ecryptfs Home Verzeichnis fehler

Offline

#30 31.05.2019 09:00:59

GerBra
Mitglied

Re: ecryptfs Home Verzeichnis fehler

cipher schrieb:

@ all
Mit dem LTS Kernel läuft alles wieder wie gewohnt.

Wenn ich den von TBone geposteten Bugreport anschaue kann ich das zumindest nicht reproduzieren.
Bei mir (immer noch Kernel 5.1.2, aber wie der Bugreporter initial auch) lädt das/die Module ohne Fehler:

# modprobe -vv ecryptfs
modprobe: INFO: custom logging function 0x55fec105dd00 registered
insmod /lib/modules/5.1.2-arch1-1-ARCH/kernel/drivers/char/tpm/tpm.ko.xz 
insmod /lib/modules/5.1.2-arch1-1-ARCH/kernel/security/keys/trusted.ko.xz 
insmod /lib/modules/5.1.2-arch1-1-ARCH/kernel/security/keys/encrypted-keys/encrypted-keys.ko.xz 
insmod /lib/modules/5.1.2-arch1-1-ARCH/kernel/fs/ecryptfs/ecryptfs.ko.xz 
modprobe: INFO: context 0x55fec18fa3e0 released

dmesg ist: [ 9131.072576] Key type encrypted registered

# modprobe -vvr ecryptfs
modprobe: INFO: custom logging function 0x56455b604d00 registered
rmmod ecryptfs
rmmod encrypted_keys
rmmod trusted
rmmod tpm
modprobe: INFO: context 0x56455bee33e0 released

Du verwendest eine Intel-CPU, ich hier eine AMD. Könnte das ein Hinweis sein? Evtl. können ja andere Intel-User auch mal prüfen, ob sie diese Fehlermeldung ebenfalls erhalten.
Aus dem Bugreport (und dem darin erwähnten Thread) geht ja leider nicht hervor welche CPU die Leute verwenden.
Zumindest einer konnte das Problem durch Aktivierung von irgendwas im BIOS bzgl. TPM ja lösen.

Zu den Ergebnissen der anderen von mir vorgeschlagenen Maßnahmen:
a) hat haveged denn wenigstens bzgl. Bootzeit/dmesg-Lücke etwas bewirkt?
b) Das microcode-Paket: Da habe ich das Gefühl, daß zumindest Nutzer von moderneren Intel-CPUs davon profitieren bzw. an Sicherheit/Stabilität gewinnen, es also aktiviert haben sollten. Würde ich nochmal drüber nachdenken, wenn auch ggf. nicht unmittelbar im Zusammenhang mit deinem Problem.

Offline

#31 31.05.2019 09:20:14

frostschutz
Mitglied

Re: ecryptfs Home Verzeichnis fehler

GerBra schrieb:

Bei mir (immer noch Kernel 5.1.2, aber wie der Bugreporter initial auch) lädt das/die Module ohne Fehler:

Nurmalso, bei Kernel 5.1.x gabs fiese Datenverluste mit SSD und TRIM (auf LVM/LUKS), ditto bei RAID6 (bei Resync).

https://bbs.archlinux.org/viewtopic.php?id=246569
https://bugs.archlinux.org/task/62693
https://www.spinics.net/lists/raid/msg62645.html

@ all
Mit dem LTS Kernel läuft alles wieder wie gewohnt.

Andere Kernelversion (linux-lts o.ä.) ist immer einen Versuch wert, manchmal ist einfach der Wurm drin...

Beitrag geändert von frostschutz (31.05.2019 09:22:38)

Offline

#32 31.05.2019 14:18:05

cipher
Mitglied

Re: ecryptfs Home Verzeichnis fehler

Was ich dazu noch sagen kann.
Auf meinem anderen Notebook - ebenfalls ein Thinkpad - läuft ecryptfs mit aktuellem Kernel ohne Probleme. Von daher ist es auch für mich nicht nachvollziehbar woher das Problem kommt.

Die Installationen der beiden Notebooks sind weitgehend indentisch. Auf beiden wird das Home-Verzeichnis mit ecryptfs verschlüsselt, und bei beiden wird beim Anmelden automatisch entschlüsselt. Bei dem einen klemmt es seit ein paar Tagen, bei dem anderen keine Probleme.

Auf beiden ist eine Intel-CPU drin.

@GerBra

a) Ich habe eine SSD drin. Die Bootzeit ist nicht merklich gestiegen, würde aber behaupten das das kurze Stocken beim Bootvorgang verschwunden ist. Ist anhand der kurzen Bootzeit schwer zu beurteilen.

b) Hatte mich auch schon gefragt was es mit dem intel-ucode auf sich hat. Kannst du mir auf die Sprünge helfen was es damit auf sich hat. Da mein englisch 'bescheiden' ist verstehe ich den Hintergrund nicht.

Bei haveged konnte ich mit dem Befehl 'cat /proc/sys/kernel/random/entropy_avail' eine Verdoppelung des Entropy-Wertes erreichen. Der laut wiki nicht unter 1000 liegen sollte, was bei mir ohne das Paket der Fall war (ca 800). Jetzt liegt er bei 1600. Von daher schonmal eine Verbesserung. Egal ob die Bootzeit schneller ist oder nicht lasse ich das Paket installiert. Danke für den Tip.

Beitrag geändert von cipher (31.05.2019 14:19:37)

Offline

#33 31.05.2019 14:40:19

Photor
Mitglied

Re: ecryptfs Home Verzeichnis fehler

frostschutz schrieb:

Nurmalso, bei Kernel 5.1.x gabs fiese Datenverluste mit SSD und TRIM (auf LVM/LUKS), ditto bei RAID6 (bei Resync).

Frage nebenbei: hab mich jetzt ca 1 Woche nicht getraut, den Lappie hoch zu fahren (eigentlich hatte ich einfach keine Zeit). Aber ist der Bug gefixt. Ich habe ein verschlüsseltes Filesystem mit LUKS auf Samsung-SSD. Also sozusagen der Worst Case. Daher würde ich natürlich gerne den Rechner hochfahren, sofort das „discard“ raus nehmen (falls gesetzt - ich weiß es nicht mehr genau) und updaten. Da wäre es gut, wenn der Bug gefixt wäre und mit dem Update die Lösung auf den Rechner fließen würde
.
Momentan bete ich, dass noch kein Datenverlust passiert ist (die wichtigen Daten sind im Backup) - aber nervig wäre ein Neu-Aufsetzen des Systems schon.

Ciao,
Photor

Offline

#34 31.05.2019 14:44:55

efreak4u
Mitglied

Re: ecryptfs Home Verzeichnis fehler

@cipher: Die Intel µ-Code-Updates schliessen unter anderem auch die Sicherheitsluecken (z.B. Meltdown, Spectre und Zombieload), die in den letzten Jahren bei Intel-CPUs der Core-i-Serie aufgetreten sind. Desweiteren bringt das Update Code-Optimierungen ein.

Offline

#35 31.05.2019 15:07:34

cipher
Mitglied

Re: ecryptfs Home Verzeichnis fehler

efreak4u schrieb:

@cipher: Die Intel µ-Code-Updates schliessen unter anderem auch die Sicherheitsluecken (z.B. Meltdown, Spectre und Zombieload), die in den letzten Jahren bei Intel-CPUs der Core-i-Serie aufgetreten sind. Desweiteren bringt das Update Code-Optimierungen ein.

Danke für die Info.
Wenn ich das richtig verfolgt habe, hat Intel für die älteren CPUs sowieso nix mehr gepacht. Oder liege ich da falsch?

Ich habe eine Core i5-2520M

Offline

#36 31.05.2019 15:21:17

GerBra
Mitglied

Re: ecryptfs Home Verzeichnis fehler

cipher schrieb:

@GerBra

a) Ich habe eine SSD drin. Die Bootzeit ist nicht merklich gestiegen, würde aber behaupten das das kurze Stocken beim Bootvorgang verschwunden ist. Ist anhand der kurzen Bootzeit schwer zu beurteilen.

Im dmesg oder journalctl -b Ausgabe sollte das ersichtlich sein. In deinem weiter oben geposteten dmesg war ja eine ~5 Sekunden lange "Lücke" zwischen durchgängigen Bootmeldungen und eben der Meldung "random: crng init done". Diese Lücke sollte jetzt nicht mehr vorhanden sein. Ohne das daß Random-System komplett initialisiert ist ist oftmals keine (grafische) Anmeldung möglich oder der Bootvorgang stockt/hängt - daß muß dich in deinem Setup jetzt nicht betreffen, aber "meßbar" sollte es sein.
Z.B. auch durch:
systemd-analyze
bzw.
systemd-analyze blame
mit und ohne den haveged.

cipher schrieb:

b) Hatte mich auch schon gefragt was es mit dem intel-ucode auf sich hat. Kannst du mir auf die Sprünge helfen was es damit auf sich hat. Da mein englisch 'bescheiden' ist verstehe ich den Hintergrund nicht.

Es gibt auch im Wiki hier einen Beitrag zu:
https://wiki.archlinux.de/title/Microcode
Allgemein:
https://de.wikipedia.org/wiki/Mikrocode
Diese Codeteile bügeln halt diverse "Fehler" bei Hard- und Software im wesentlichen für die CPUs aus. Teils zusammen mit etwaigen BIOS/EFI-Updates/Versionen, teils auch ohne bzw. nach dem Laden der BIOS-Firmware/Codes. In etwa daß, was bekannte Auto- oder Flugzeug-Hersteller auch "anbieten" um (oftmals hausgemachte) auszubügeln.

Z.B.: eine CPU rechnet immer 2+5=6, da ein Register nicht mit Strom versorgt wird. Dieser Fehler kann nun möglicherweise per Software/Code behoben werden durch solche "Flickereien", ergo an Millionen Geräten muß keine CPU getauscht werden. Und schon ergibt 2+5 wieder richtigerweise 9.... (sagt mein PC-Taschenrechner)... <g>

Die Unterschiede zwischen deinen Thinkpads: das könnten natürlich unterschiedliche Hardware/BIOS-Versionen oder auch BIOS/EFI-Einstellungen sein - evtl. mal vergleichen (gerade CPU-Einstellungen). Ansonsten abwarten, was beim Bugreport rauskommt, dich da evtl. einklinken als "Betroffener". Die Wahrscheinlichkeit für einen Kernel-Fehler ist IMHO größer als daß evtl. dieses Verhalten gewollt ist bzw. eine Änderung am Usergerät erfordern würde.

@TBone

TBone schrieb:

Danke, danke smile

[god@universe ~/walhalla]# sed s/TBone/k\.osmo/g gesamte_Forenbeiträge_seit_1970-1-1

So, daß hast du jetzt davon... Sechs Zylinder sticht! ;-)
//Edit: Ich mag dich halt, deswegen schustere ich dir gerne fremde Forenbeiträge zu...

Beitrag geändert von GerBra (31.05.2019 15:36:14)

Offline

#37 31.05.2019 15:52:32

frostschutz
Mitglied

Re: ecryptfs Home Verzeichnis fehler

Photor schrieb:
frostschutz schrieb:

Nurmalso, bei Kernel 5.1.x gabs fiese Datenverluste mit SSD und TRIM (auf LVM/LUKS), ditto bei RAID6 (bei Resync).

Frage nebenbei: hab mich jetzt ca 1 Woche nicht getraut, den Lappie hoch zu fahren (eigentlich hatte ich einfach keine Zeit).

Nimm eine LiveCD, da kannst du alles mounten (ohne allow discard), chrooten, updaten (mindestens auf 5.1.5 oder eben linux-lts) und danach wieder richtig booten.

Also das gleiche was man machen würde wenn der Kernel sonst irgendwie auf Grund läuft.

Beitrag geändert von frostschutz (31.05.2019 15:53:06)

Offline

#38 31.05.2019 16:01:38

cipher
Mitglied

Re: ecryptfs Home Verzeichnis fehler

@ GerBra

$ system-analyze (ohne haveged)

Startup finished in 4.574s (kernel) + 2.645s (userspace) = 7.220s 
graphical.target reached after 1.678s in userspace

$ system-analyze (mit haveged)

Startup finished in 4.980s (kernel) + 2.635s (userspace) = 7.616s 
graphical.target reached after 1.752s in userspace

Das mit den Intel Microcode schaue ich mir in den Tagen mal an.

Beitrag geändert von cipher (31.05.2019 16:03:56)

Offline

#39 31.05.2019 16:23:33

cipher
Mitglied

Re: ecryptfs Home Verzeichnis fehler

Update:

Ich hatte die Woche das Thema TPM komplett vernachlässigt, da ich im Bios den Notebooks seit Jahren nicht mehr war. Wozu auch, lief ja alles. GerBra hatte mich ja darauf hingewiesen.

Habe nun (um dies auch auszuschließen)  die Einstellungen der beiden Notebooks verglichen (das eine mit Fehler, das andere ohne Fehler)

Habe im Reiter 'Security' einen Eintrag 'Security Chip'.

Bei dem Notebook mit Fehler steht der Eintrag auf 'Inactive'
Bei dem Notebook ohne Fehler steht der Eintrag auf 'Disabled'.

Also habe ich den Eintrag auch dort auf 'Disabled' gestellt, und siehe da es funktioniert wieder mit dem aktuellen Kernel. Auch der Fehler in 'dmesg' bezüglich TPM ist weg. Wieso das jetzt die ganzen Jahre funktioniert hat kann ich nicht sagen.

Ich bin mir sicher das ich schon eine Ewigkeit nicht mehr im Bios war und somit den Wert auch nicht verändert habe. Einzige Erklärung wäre, das mit dem Kernelupdate (5.0.13 > 5.1.3) die Funktionalität des TPM-Chips vielleicht geändert wurde.

@GerBra
Sorry, wegen TPM disabled

Beitrag geändert von cipher (31.05.2019 16:26:24)

Offline

#40 31.05.2019 18:09:54

GerBra(offline)
Gast

Re: ecryptfs Home Verzeichnis fehler

cipher schrieb:

Habe nun (um dies auch auszuschließen)  die Einstellungen der beiden Notebooks verglichen (das eine mit Fehler, das andere ohne Fehler)

Habe im Reiter 'Security' einen Eintrag 'Security Chip'.

Bei dem Notebook mit Fehler steht der Eintrag auf 'Inactive'
Bei dem Notebook ohne Fehler steht der Eintrag auf 'Disabled'.

Also habe ich den Eintrag auch dort auf 'Disabled' gestellt, und siehe da es funktioniert wieder mit dem aktuellen Kernel. Auch der Fehler in 'dmesg' bezüglich TPM ist weg. Wieso das jetzt die ganzen Jahre funktioniert hat kann ich nicht sagen.

Das klingt jetzt für mich etwas "unlogisch", allerdings bin ich mit - neueren - Notebooks nicht sehr bewandert.
"Security Chip" klingt ja erstmal nach was Gutem ;-)
Zwischen disabled und inactive sehe ich jetzt nicht den großen Unterschied, außer das bei "abgestellt" evtl. der Kernel kein Device dafür verwenden will (das Ganze ggf. über "Software" regelt), und eben bei "inaktiv" ein Device erkannt wird aber wg. inaktiv dann falsch initialisiert wird. Irgend sowas halt zwischen Hard- oder Software-seitige Nutzung von "Sicherheits/Zufall"-Funktionen.

Einen signifikanten Unterschied hätte ich jetzt eher zwischen "Disabled/Inactive" und "Activ" vermutet... Gibt es auch aktiv als Einstellung, und wenn ja: was "tut das machen..." ? ;-)

Trotzdem würde ich den Bugreport mal im Auge behalten, händisches Umkonfigurieren im BIOS ist ja zwischen Kernelverisionen eher ggf. dann nötig wenn die vormals aktive Einstellung (grob) faslch gewesen wäre bzw. anders als eine Art Defaulteinstellung.

Schwere Geburt...

#41 01.06.2019 12:43:50

cipher
Mitglied

Re: ecryptfs Home Verzeichnis fehler

@GerBra

Laut Bios steht da.

Active: Security chip ist functional.
Inactive: Security chip is visible, but is not functional.
Disabled: Security chip is hidden and is not functional.

Wenn ich das richtig deute bedeutet das, inactive ist er fürs Betriebssystem sichtbar aber deaktiviert (Das würde die TPM disabled Meldung in dmesg erklären). Disabled bedeutet der Chip ist nicht sichtbar und auch deaktiviert. Da der TPM Chip immer wieder in der Kritik steht wollte ich den lieber deaktiviert lassen.

Siehe hier https://de.wikipedia.org/wiki/Trusted_P … ule#Kritik.

Einziges Problem das ich habe, warum ging es die letzten Jahre mit inactive?
Hat 'ecryptfs' bzw das 'trusted' Modul den TPM bis zu Kernel 5.1.x nicht genutzt?

Beitrag geändert von cipher (01.06.2019 12:46:13)

Offline

#42 01.06.2019 18:05:54

Photor
Mitglied

Re: ecryptfs Home Verzeichnis fehler

frostschutz schrieb:

Nimm eine LiveCD, da kannst du alles mounten (ohne allow discard), chrooten, updaten (mindestens auf 5.1.5 oder eben linux-lts) und danach wieder richtig booten.

Also das gleiche was man machen würde wenn der Kernel sonst irgendwie auf Grund läuft.

Stimmt. Einen Stick mit nem Live-System hab ich noch liegen. Ich hoffe halt, dass es noch nicht zum Datenverlust gekommen ist.
Der 5.1.5-Kernel ist den Repos, so dass ein „pacman -Syu“ reicht, oder?
Mich wundert, dass der - doch nicht ganz unerhebliche -  Bug so relativ lautlos behandelt wurde; ich hab‘s nur relativ nebenbei erfahren.

Ciao,
Photor

Offline

#43 04.06.2019 18:02:45

Photor
Mitglied

Re: ecryptfs Home Verzeichnis fehler

Moin,

Kurze Rückmeldung: instaliert war 5.1.4. Hab dann erstmal den fstrim.timer gestoppt und disabled und die „discard“-Option  aus der /etc/fatab entfernt. Nach dem heutigen Update ist jetzt Kernel 5.1.6 installiert. Ich hoffe, das ist jetzt erstmal sicher - oder?

PS: bislang keinen Datenverlust festgestellt - werde aber weiter beobachten.

Ciao,
Photor

Offline

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums