Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

Photor
04.06.2019 18:02:45

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

Photor
01.06.2019 18:05:54
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

cipher
01.06.2019 12:43:50

@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?

GerBra(offline)
31.05.2019 18:09:54
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...

cipher
31.05.2019 16:23:33

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

cipher
31.05.2019 16:01:38

@ 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.

frostschutz
31.05.2019 15:52:32
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.

GerBra
31.05.2019 15:21:17
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...

cipher
31.05.2019 15:07:34
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

efreak4u
31.05.2019 14:44:55

@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.

Photor
31.05.2019 14:40:19
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

cipher
31.05.2019 14:18:05

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.

TBone
31.05.2019 12:15:31
GerBra schrieb:

Wenn ich den von TBone geposteten Bugreport anschaue kann ich das zumindest nicht reproduzieren.

Danke, danke smile

frostschutz
31.05.2019 09:20:14
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...

GerBra
31.05.2019 09:00:59
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.

Fußzeile des Forums

Powered by FluxBB