モジュールvfatは起動時にロードされず、modprobe vfat
で問題を強制しようとするとエラーが発生します
modprobe: ERROR: could not insert 'vfat': Unknown symbol in module, or unknown parameter (see dmesg)
dmesgラインで
[ 663.227894] fat: Unknown symbol __bread_gfp (err 0)
[ 663.227924] fat: Unknown symbol __getblk_gfp (err 0)
起動時にsystemctl status systemd-modules-load.service
を実行するようにアドバイスする2つの[FAILED]メッセージもあります。そうすることの結果は次のとおりです:
● 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.
私は基本的にVanillaDebian Jessieを実行していて、カーネルについて何も手作業で調整していません。 uname -a
は
Linux aleph 3.16.0-4-AMD64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux
および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
エラーの詳細についてGoogle検索から読んだすべてのことは、ここでの問題は、実行中のカーネルのバージョンとkmodによって選択されたモジュールとの間の不一致であることを示唆しています。そのために、 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=80838 と vfatはで認識されません)で提案されている2つの明らかな手順を実行しましたdebian その問題を修正するために:最初に再起動を試み、次にapt-get install --reinstall linux-image-3.16.0-4-AMD64
を使用して強制的に再インストールし、その後再起動しました。 debsums linux-image-3.16.0-4-AMD64
は、現在のカーネルに問題がないことも示しています。ただし、問題は解決しません。
自分のカーネルとモジュールをコンパイルすることでこれを修正できるかもしれませんが、Debianバイナリの外に出るのは少し最後の手段だと思います。
OK、問題は通常の(つまり、間違ったカーネル)で、わずかなしわがありました。何らかの理由で、私がそれを行ったときに間違いなく理にかなっていたので、grub-pcをdebianパッケージとしてインストールしましたが、 LILO(パッケージとしてインストールされていない)は実際のブートローダーとして実行されているため、カーネルは元気に更新されたgrubをインストール(および再インストールなど)しますが、ブート時に実際にロードされるカーネルイメージには影響しませんでした。特定のDebianカーネル/モジュールの更新がバージョン番号をインクリメントせず、kmodのバージョン選択がオフになるという既知バグがまだあります(そして、lsmod
以来、カーネル/モジュールの不一致がなかったという私の印象に貢献しましたとuname
は同じバージョン番号を教えてくれました)が、そのバグは通常、再起動して正しいカーネルをロードすることで簡単に修正できます---しかし、ブートローダーがまだ古いカーネルを持っていたこの例ではそうではありません。
Aptitudeを使用して、linux-headers- *で始まるインストール済みパッケージとlinux-image *で始まるパッケージを比較します。
aptitude search linux-image
そして
aptitude search linux-headers
実行しているカーネルに両方がインストールされていることを確認してくださいuname -a