#26 30.05.2019 13:27:29

TBone
Mitglied

Re: ecryptfs Home Verzeichnis fehler

@cipher Funktioniert es mit dem lts kernel?

Offline

#27 30.05.2019 13:30:03

cipher
Mitglied

Re: ecryptfs Home Verzeichnis fehler

@GerBra

Wenn ich das Notebook hochfahre (ohne X), melde mich an der Konsole an. Laufen schon tpm und rng_core.

$lsmod | grep -e crypt -e tpm

crypto_simd            16384  1 aesni_intel
cryptd                 28672  3 crypto_simd,ghash_clmulni_intel,aesni_intel
tpm_tis                16384  0
tpm_tis_core           24576  1 tpm_tis
tpm                    73728  2 tpm_tis,tpm_tis_core
rng_core               16384  1 tpm
crypto_user            16384  0

Dann der Versuch das Modul zu laden.

$ modprobe -vv ecryptfs

modprobe: INFO: custom logging function 0x562519ef6d00 registered
insmod /lib/modules/5.1.5-arch1-2-ARCH/kernel/security/keys/trusted.ko.xz
modprobe: INFO: Failed to insert module '/lib/modules/5.1.5-arch1-2-ARCH/kernel/security/keys/trusted.ko.xz': Bad address
modprobe: ERROR: could not insert 'ecryptfs': Bad address
modprobe: INFO: context 0x56251ae8d440 released

Die Ausgabe von lsmod nach dem Versuch, zeigt keinen Unterschied. Hier die komplette Ausgabe von lsmod

$ lsmod

Module                  Size  Used by
nls_iso8859_1          16384  1
nls_cp437              20480  1
vfat                   20480  1
fat                    86016  1 vfat
uas                    28672  0
usb_storage            77824  2 uas
bnep                   28672  2
cdc_mbim               20480  0
cdc_ncm                40960  1 cdc_mbim
cdc_wdm                28672  1 cdc_mbim
usbnet                 49152  2 cdc_mbim,cdc_ncm
cdc_acm                40960  0
mii                    16384  1 usbnet
btusb                  57344  0
btrtl                  20480  1 btusb
btbcm                  16384  1 btusb
btintel                28672  1 btusb
bluetooth             659456  22 btrtl,btintel,btbcm,bnep,btusb
ecdh_generic           24576  1 bluetooth
joydev                 28672  0
mousedev               24576  0
xt_state               16384  0
xt_conntrack           16384  1
intel_rapl             28672  0
nf_conntrack          159744  2 xt_conntrack,xt_state
nf_defrag_ipv6         24576  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
libcrc32c              16384  1 nf_conntrack
iptable_filter         16384  1
x86_pkg_temp_thermal    20480  0
intel_powerclamp       20480  0
coretemp               20480  0
kvm_intel             311296  0
kvm                   741376  1 kvm_intel
arc4                   16384  2
iwldvm                274432  0
irqbypass              16384  1 kvm
mac80211              958464  1 iwldvm
crct10dif_pclmul       16384  1
crc32_pclmul           16384  0
ghash_clmulni_intel    16384  0
iwlwifi               368640  1 iwldvm
mei_wdt                16384  0
mei_hdcp               24576  0
wmi_bmof               16384  0
iTCO_wdt               16384  0
iTCO_vendor_support    16384  1 iTCO_wdt
snd_hda_codec_hdmi     69632  1
aesni_intel           372736  0
snd_hda_codec_conexant    20480  1
snd_hda_codec_generic    90112  1 snd_hda_codec_conexant
aes_x86_64             20480  1 aesni_intel
crypto_simd            16384  1 aesni_intel
cryptd                 28672  3 crypto_simd,ghash_clmulni_intel,aesni_intel
glue_helper            16384  1 aesni_intel
intel_cstate           16384  0
snd_hda_intel          49152  0
cfg80211              811008  3 iwldvm,iwlwifi,mac80211
snd_hda_codec         155648  4 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel
intel_uncore          135168  0
snd_hda_core          102400  5 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_hwdep              16384  1 snd_hda_codec
intel_rapl_perf        16384  0
snd_pcm               135168  4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
psmouse               176128  0
thinkpad_acpi         110592  0
mei_me                 45056  2
snd_timer              40960  1 snd_pcm
i2c_i801               36864  0
input_leds             16384  0
tpm_tis                16384  0
e1000e                286720  0
nvram                  16384  1 thinkpad_acpi
tpm_tis_core           24576  1 tpm_tis
ledtrig_audio          16384  3 snd_hda_codec_generic,snd_hda_codec_conexant,thinkpad_acpi
mei                   118784  5 mei_wdt,mei_hdcp,mei_me
wmi                    32768  1 wmi_bmof
tpm                    73728  2 tpm_tis,tpm_tis_core
ac                     16384  0
snd                   102400  9 snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,thinkpad_acpi,snd_pcm
rfkill                 28672  6 bluetooth,thinkpad_acpi,cfg80211
soundcore              16384  1 snd
battery                24576  1 thinkpad_acpi
lpc_ich                28672  0
rng_core               16384  1 tpm
evdev                  20480  18
mac_hid                16384  0
pcc_cpufreq            20480  0
tp_smapi               36864  0
thinkpad_ec            16384  1 tp_smapi
sg                     40960  0
crypto_user            16384  0
ip_tables              32768  1 iptable_filter
x_tables               49152  4 xt_conntrack,iptable_filter,xt_state,ip_tables
ext4                  749568  2
crc32c_generic         16384  0
crc16                  16384  2 bluetooth,ext4
mbcache                16384  1 ext4
jbd2                  131072  1 ext4
sd_mod                 57344  5
ahci                   40960  2
libahci                40960  1 ahci
serio_raw              20480  0
atkbd                  36864  0
libps2                 20480  2 atkbd,psmouse
libata                274432  2 libahci,ahci
sdhci_pci              49152  0
crc32c_intel           24576  3
cqhci                  32768  1 sdhci_pci
scsi_mod              249856  5 sd_mod,usb_storage,uas,libata,sg
sdhci                  65536  1 sdhci_pci
ehci_pci               20480  0
mmc_core              176128  3 sdhci,cqhci,sdhci_pci
ehci_hcd               98304  1 ehci_pci
i8042                  32768  0
serio                  28672  7 serio_raw,atkbd,psmouse,i8042
i915                 2162688  2
intel_gtt              24576  1 i915
i2c_algo_bit           16384  1 i915
drm_kms_helper        212992  1 i915
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
fb_sys_fops            16384  1 drm_kms_helper
drm                   495616  3 drm_kms_helper,i915
agpgart                53248  2 intel_gtt,drm

Offline

#28 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

#29 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

#30 30.05.2019 13:53:53

TBone
Mitglied

Re: ecryptfs Home Verzeichnis fehler

cipher schrieb:

Nie Probiert. Was muss ich da tun?

Das schaffst du ohne meine Hilfe smile

Offline

#31 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

#32 30.05.2019 18:33:11

k.osmo
Mitglied

Re: ecryptfs Home Verzeichnis fehler

Offline

#33 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

#34 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)

Online

#35 31.05.2019 12:15:31

TBone
Mitglied

Re: ecryptfs Home Verzeichnis fehler

GerBra schrieb:

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

Danke, danke smile

Offline

#36 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

#37 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

#38 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

#39 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

#40 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

#41 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)

Online

#42 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

#43 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

#44 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...

#45 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

#46 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

#47 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