cannot mount usb stick, unknown filesystem 'vfat'
 

Hey folks,

I am trying to mount a usb stick with a fat32 fs (formatted in windows). When I try to do that however I get the message:
The same happened when I use:
dmesg | tail outputs:
A search gave several results stating I should reboot, but that did not help, unfortunately.

The output from fdisk -l is:

Hi

the request to reboot refers mainly to people who just installed another kernel. I assume you have not installed another kernel.

Can you check that module for vfat exists first or is built in by looking at your current kernel config found in /boot/config<kernel-version>
and mine is
# DOS/FAT/NT Filesystems

CONFIG_VFAT_FS=y

2) if yours is a m then try running a modprobe with root powers first
3) what is your distro and there appears to be a bug related to Debian kernels
https://labs.riseup.net/code/issues/10928

Hey,
Thanks for the reply. I indeed have CONFIG_VFAT_FS=m. So I tried running modprobe:
And dmesg gives once again:
3.
I'm running Debian 8.3

This is interesting because I once couldn't mount a FAT stick on Debian either. I might have to re-test it sometime.

Do you remember how you fixed it?

Also it might be worth noting that I for a fact have been able to mount usb's before on this install.

I don't know if I did fix it. After all, who wants compatibility with Microsoft technologies anyway? :)

What kernels do you have installed, though? It probably happened after a kernel upgrade.

Actually I do, even though in an ideal world, everyone uses Linux, Windows has several advantages due the shear amount of people running it.

Linux debian-name 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) x86_64 GNU/Linux

Don't recall upgrading recently, but then again, last time I mounted a usb has been some time as well.

Is that your only kernel? If it is Jessie, I would think so, if you migrated from Wheezy, I wouldn't be sure of it.

As far as I can see it's indeed my only kernel. I did do a fresh install around half a year ago iirc. So I'd presume I indeed started with Jessie

I just tested it, and a newly created (under Linux) vfat partition on my USB stick is working fine. This is my only kernel upgrade I've done on this install:
linux-image-3.16.0-4-amd64:amd64 (3.16.7-ckt11-1+deb8u3, 3.16.7-ckt20-1+deb8u3)
That was on the 25th of January I upgraded that. Have you done an upgrade since then and not rebooted?

Nope, rebooted before posting here, and a fresh reboot this morning. Not helping.

hmm I wonder if this old bug has relevance?
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=708965

Basically it claims that the bootloader has not truly updated and booted the new kernel....ignoring the fact you appear to claim you have only one?
altho you said only kernel upgrade.

one way to check would be just run a kernel version command
secondly the poster did a manual bootloader command assuming grub with root powers
changing sda to what ever mbr you are using

altho I am reluctant to suggest re-embed grub in mbr by doing it we at least eliminate any bootloader issues.

Let me know your thoughts if this does not appeal to you

oh found another entry
http://unix.stackexchange.com/questi...-obvious-fixes

here the poster thought he was using grub but was using lilo so update kernel was not going thru bootloader process.

There appears to be a trend here?

As far as the old bug goes, the dmesg log seems to be different.
uname gave the following result, so I'm still guissing just 1 kernel, as expected.
I also updated grub as you suggested, and after doing that, which gave me some errors regarding the null disk, although I dont think that's relevant:
I couldn't get the mount command to work. Still the same error and dmseg

EDIT:
The trend indeed seems to be kernel issues. Regarding bootloader, I'm fairly sure grub is being used, after all, that's what it sais on bootup at the boot selection. Also checked for errors or failed messages like the person in the post had, but I couldn't find any that I can imagine relating to this problem.
Not sure what the danger of re-embedding grub is, If it could help, i'm willing to try it though.

Are we sure about this?

sdi means you have attempted to use a MBR of the ninth drive unless I am mistaken?
how many drives do you have....not partitions but actual drives available at boot up please

as root might help. Most people either dual boot with windows on first drive and Linux on second or linux on first drive
so I was expecting sda or sdb

I do indeed have 9 drives:
-5 actual hard drives that form a raid6 data array
-4 usb drives that run in a raid1 config to run os. (planning to change this to actual drives somewhere in the future). although at the moment it seems like one of those 4 is out, will try to fix it when at home.
-the 1 usb drive im trying to mount. sdh at the moment

for some reason I decided it was a good idea to try and install grub on the usb trying to mount... so no I'm not sure about this. I do recall having some challenges installing grub in such a way that my 4 usb raid1 could boot even with only 1 usb present. So grub should be installed in all 4 I think. This construction however, does sound like the problem could be here.

the output from blkid is:
EDIT:
I am starting to suspect that somehow the data raid might be screwing stuff up, especially as that raid is migrated from an earlier system and might indeed be cousing some sort of bootloader kernel conflict. Will try to disconnect the raid and see if it solves it later today.