☰

Modul vfat kann nicht geladen werden (ich habe die offensichtlichen Lösungen versucht)

tag-icon • tag-icon debian filesystems kernel kernel-modules vfat
Modul vfat kann nicht geladen werden (ich habe die offensichtlichen Lösungen versucht)

Das Modul vfat wird beim Booten nicht geladen und versucht, das Problem mit einem zu erzwingen, der modprobe vfatden Fehler erzeugt

modprobe: ERROR: could not insert 'vfat': Unknown symbol in module, or unknown parameter (see dmesg)

mit den dmesg-Zeilen

[  663.227894] fat: Unknown symbol __bread_gfp (err 0)
[  663.227924] fat: Unknown symbol __getblk_gfp (err 0)

Außerdem werden beim Systemstart zwei [FAILED]-Meldungen angezeigt, die mir empfehlen, auszuführen. systemctl status systemd-modules-load.serviceDas Ergebnis davon ist:

● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static)
   Active: failed (Result: exit-code) since Fri 2016-02-12 12:55:11 EST; 18min ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
 Main PID: 502 (code=exited, status=1/FAILURE)

Feb 12 12:55:11 aleph systemd-modules-load[502]: Failed to insert 'fuse': No such file or directory
Feb 12 12:55:11 aleph systemd[1]: systemd-modules-load.service: main process exited, code=exited, status=1/FAILURE
Feb 12 12:55:11 aleph systemd[1]: Failed to start Load Kernel Modules.
Feb 12 12:55:11 aleph systemd[1]: Unit systemd-modules-load.service entered failed state.

Ich verwende im Wesentlichen ein Vanilla-Debian-Jessie und habe an meinem Kernel nichts manuell optimiert uname -a.

Linux aleph 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux

Und modinfo fat vfat:

filename:       /lib/modules/3.16.0-4-amd64/kernel/fs/fat/fat.ko
license:        GPL
depends:        
intree:         Y
vermagic:       3.16.0-4-amd64 SMP mod_unload modversions 
filename:       /lib/modules/3.16.0-4-amd64/kernel/fs/fat/vfat.ko
author:         Gordon Chaffee
description:    VFAT filesystem support
license:        GPL
alias:          fs-vfat
depends:        fat
intree:         Y
vermagic:       3.16.0-4-amd64 SMP mod_unload modversions

Alles, was ich bei Google-Suchen zu den Einzelheiten des Fehlers gelesen habe, deutet darauf hin, dass das Problem hier eine Nichtübereinstimmung zwischen den Versionen des laufenden Kernels und den von kmod ausgewählten Modulen ist. Zu diesem Zweck habe ich die beiden offensichtlichen Schritte unternommen, die inhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808380Undvfat wird in Debian nicht erkanntzur Behebung des Problems: Zuerst habe ich versucht, neu zu starten, dann habe ich apt-get install --reinstall linux-image-3.16.0-4-amd64eine Neuinstallation erzwungen und danach neu gestartet. debsums linux-image-3.16.0-4-amd64zeigt auch an, dass mein aktueller Kernel in Ordnung sein sollte. Das Problem besteht jedoch weiterhin.

Ich könnte das wahrscheinlich beheben, indem ich meinen eigenen Kernel und meine eigenen Module kompiliere, aber ich würde es wirklich nur als letzten Ausweg betrachten, über die Debian-Binärdateien hinauszugehen.

Antwort1

OK, das Problem stellte sich als das übliche heraus (d. h. falscher Kernel), mit einer kleinen Besonderheit: Aus irgendeinem Grund, der zum Zeitpunkt, als ich es tat, zweifellos Sinn machte, hatte ich grub-pc als Debian-Paket installiert, aber LILO (nicht als Paket installiert) als meinen eigentlichen Bootloader laufen, sodass Kernel-Installationen (und Neuinstallationen und dergleichen) Grub munter aktualisierten, was keinen Einfluss darauf hatte, dass das Kernel-Image tatsächlich beim Booten geladen wurde. Es gibt immer noch einbekanntFehler, dass ein bestimmtes Debian-Kernel-/Modul-Update die Versionsnummer nicht erhöhte, was die Versionsauswahl von kmod durcheinander bringt (und zu meinem Eindruck beitrug, dass ich keine Kernel-/Modul-Nichtübereinstimmung hatte, da lsmodund unamemir dieselbe Versionsnummer gaben), aber dieser Fehler lässt sich normalerweise leicht beheben, indem man einen Neustart durchführt, um den richtigen Kernel zu laden – aber nicht in diesem Fall, wo der Bootloader noch den alten Kernel hatte.

Antwort2

Verwenden Sie Aptitude, um installierte Pakete, die mit „linux-headers-*“ beginnen, mit Paketen zu vergleichen, die mit „linux-image*“ beginnen.

aptitude search linux-image

Und

aptitude search linux-headers

Stellen Sie sicher, dass beide für den von Ihnen verwendeten Kernel installiert sind uname -a

verwandte Informationen