3

The module vfat doesn't load on boot, and attempts to force the issue with a modprobe vfat produce the error

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

with the dmesg lines

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

There are also two [FAILED] messages at boot-time advising me to run systemctl status systemd-modules-load.service; the result of doing so is:

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

I am running a basically vanilla Debian Jessie and haven't hand-tweaked anything about my kernel. uname -a returns

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

and 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 

Everything I've read from Google searches on the specifics of the error suggests that the problem here is a mismatch between the versions of the running kernel and the modules selected by kmod. To that end I've taken the two obvious steps suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808380 and vfat not recognized in debian for fixing that problem: first, I tried rebooting, and then I used apt-get install --reinstall linux-image-3.16.0-4-amd64 to force a reinstall and rebooted after. debsums linux-image-3.16.0-4-amd64 also indicates that my current kernel should be OK. The problem persists, however.

I could probably fix this by compiling my own kernel and modules, but I'd really consider going outside of the debian binaries a bit of a last resort.

  • try doing a sudo depmod -a and then loading vfat again – Rui F Ribeiro Feb 12 '16 at 18:28
  • Would you provide the output of uname -r? – Rui F Ribeiro Feb 12 '16 at 18:31
  • sudo depmod -a produced no output, didn't affect the result of a sudo modprobe vfat described above. uname -r returns 3.16.0-4-amd64. – Jake Wildstrom Feb 12 '16 at 18:33
  • have you tried to reboot? – Rui F Ribeiro Feb 12 '16 at 18:40
  • If you mean a reboot since running depmod -a, yup, just tried and the situation remains unchanged. – Jake Wildstrom Feb 12 '16 at 18:49
1

OK, the problem turned out to be the usual (i.e., wrong kernel), with a slight wrinkle: for some reason which no doubt made sense at the time I did it, I had grub-pc installed as a debian package, but had LILO (not installed as a package) running as my actual bootloader, so kernel installs (and reinstalls, and suchlike) cheerfully updated grub, which had no effect on the kernel image actually being loaded on boot time. There's still a known bug that a specific Debian kernel/module update didn't increment the version number which throws kmod's version selection off (and contributed towards my impression that I had no kernel/module mismatch, since lsmod and uname were giving me the same version number), but that bug's normally easily fixed by rebooting to load the right kernel---but not in this instance, where the bootloader still had the old kernel.

0

Use aptitude to compare installed packages starting with linux-headers-* with packages starting with linux-image*.

aptitude search linux-image

and

aptitude search linux-headers

Make sure both are installed for the kernel you're running uname -a

  • As mentioned in the post, I have (and have confirmed the integrity of) the installed package linux-image-3.16.0-4-amd64; linux-headers-3.16.0-4-amd64 was not installed, so I've gone ahead and installed it, although it's not clear to me how that will help --- isn't it relevant chiefly to building a kernel or kernel modules from source? – Jake Wildstrom Feb 13 '16 at 21:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.