cipher schriebWie ich sehe kam heute der Kernel 5.1.5 ins repo.
$ modprobe -vv trusted
modprobe: INFO: custom logging function 0x55a3fe326d00 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 'trusted': Bad address
modprobe: INFO: context 0x55a3ffbb6440 released
Was mir noch einfallen würde:
Ist zu diesem Zeitpunkt denn das Modul tpm auch/schon geladen?
Denn die Abhängigkeiten der Kernelmodule ist so (ich bin hier noch bei Kernel 5.1.2, daß sollte aber egal sein):
ecryptfs braucht encrypted-keys
encrypted-keys braucht trusted
trusted braucht tpm
tpm braucht rng-core
(Das kann man mit modinfo modulnamen sehen).
D.h. du müßtest mal prüfen nach einem frischen Boot und einem Versuch mit:
modprobe -vv ecryptfs
ob nach dem Fehlschlag trotzdem die Module rng-core und tpm geladen sind (lsmod). Am besten nach dem versuch auch mal eine Ausgabe von lsmod posten.
Den einzigen Hinweis, daß die Probleme ggf. schon früher als mit dem trusted-Modul anfangen ist im dmesg-Output der Hinweis, das irgendwas mit TPM abgestellt wäre:
[ 5.418991] tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78)
[ 5.450608] tpm tpm0: TPM is disabled/deactivated (0x6)
Ob diese Meldungen mit den Hauptproblem was zu tun haben, da bin ich mir unsicher.
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/Random_number_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.