Volume was not properly unmounted …

Here is the fix for this annoying message.

Code: Select all

# dmesg | grep corrupt
[   21.280705] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.


Code: Select all

# umount /boot
# git clone http://daniel-baumann.ch/git/software/dosfstools.git

# cd dosfstools

# make
cc -O2 -fomit-frame-pointer -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Wextra -Wno-sign-compare -Wno-missing-field-initializers -Wmissing-prototypes -Wstrict-prototypes -g   -c -o fatlabel.o src/fatlabel.c
.
.
.
cc   mkfs.fat.o   -o mkfs.fat
# ./fsck.fat -V /dev/mmcblk0p1
fsck.fat 3.0.24 (2013-11-23)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Starting check/repair pass.
Starting verification pass.
Leaving filesystem unchanged.
/dev/mmcblk0p1: 14 files, 2383/7161 clusters

./fsck.fat -a /dev/mmcblk0p1

#mount /boot


I’ve tried to use dosfstools taken from apt-get, but still can’t remove this bug.
It seems the dosfstools package from apt-get (3.0.13-1) seems older than git files (3.0.24).
so the only solution just like @Richard-TX said, have to take the git then recompile.
Voila, the bug gone.

Exact same scenario for me. Using apt-get dosfstools did not change the corrupt notification during boot. Per this thread:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=61879

Used this resulting in no change to the /boot corrupt message:

Code: Select all

sudo fsck.vfat -w -r -l -a -v -t /dev/mmcblk0p5

So instead followed Richard’s guidance to git clone and build the source and use fsck.fat. Walla! No more corrupt message during boot.

In the event the reader does not understand what they read in Richard’s comments. It took me (noob) a bit of playing around to understand what I needed to do. I am only listing the steps without the feedback.

The first time ./fsck.fat is ran, it should report «dirty bit» is set. Choose number 1. When the command is ran the second time, it will show the bit as clean.

Also, I was not running as a root user so I used «sudo» for each command.

Hopefully it will help. I know Richard’s work has helped me.

Thanks and best regards!
Fred

Code: Select all

   sudo umount /boot
sudo git clone http://daniel-baumann.ch/git/software/dosfstools.git
sudo cd dosfstools
sudo make
sudo ./fsck.fat -V /dev/mmcblk0p1

sudo ./fsck.fat -a /dev/mmcblk0p1
sudo mount /boot


I got this:

Code: Select all

sudo ./fsck.fat -V /dev/mmcblk0p1
fsck.fat 3.0.25 (2014-01-17)
0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
? 1
Starting check/repair pass.
FATs differ but appear to be intact. Use which FAT ?
1) Use first FAT
2) Use second FAT
?

Which one should I choose?

sharix: That’s a tricky one. One of the File Allocation Tables is wrong, but you can’t tell which. You’ll just have to make a guess, I suppose.

i do not understand, why the official repository still contains an not working many years old outdated version of dosfstools.
isn’t it possible to update that version in the repository? it is not understandable why every body who tries to fix the dirty bit, first has to run in to a not working solution, struggle around what’s wrong, and has to search in the internet, to find the right working solution…
for what is the repository there, when it is not keeped up to date?!?!

I’ve just seen this message appear (I’d done a simple sudo halt followed by system card backup)!

Code: Select all

[   18.356472] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

All the above looks a bit scary. And when I run fsck as asked .. it warns of the perils of an unmounted file system!! Is this a real filesystem problem? Do I need to fix it? Is it as easy as and unmount of /boot, fsck, and remount (presumably all managed by the debian kernel)?

Dougie, to the rescue again! I chose the desktop option (easier, better understood) and I had properly ejected it after my backup (was read only anyway?)

But checkdisk finds no errors. Though (bizarrely) I get a pop up offering to fix same errors when I plug it in So I’m presently reinstalling my February image. Don’t think I’ll lose much beyond updates as I’ve been attending to «other hobby» since then.

It work for me:

Code: Select all

sudo umount /boot
sudo git clone http://daniel-baumann.ch/git/software/dosfstools.git
sudo cd dosfstools
sudo make
sudo make install
sudo ./fsck.fat -V /dev/mmcblk0p1
sudo ./fsck.fat -a /dev/mmcblk0p1
sudo mount /boot


from: http://lusorobotica.com/index.php?topic=7158.0

In the line: ./fsck.fat -V /dev/mmcblk0p1
I typed the number 1 and I pressed enter

Good luck!

Like most other Pi’ers, I was able to solve the problem with Richard-TX’s post (The very first one)
So, installing with «sudo apt-get install dosfstools» didn’t work.

And like NT4boy (First one above this post) said, try to identify the disc which gives the error. Most probably it is not p1. Mine was not P1 either, it was P5 instead. Try what he says and hopefully you’ll solve this annoying error message.

croston wrote:I’ve built Raspbian Jessie (clean image install, not an upgrade) and confirm that it has been fixed in the next version of Raspbian.

And for those who don’t want to go the full dist upgrade way to Jessie I have posted here how to install only one package from Jessie using the Debian pinning system. Easy and gentle to your dependencies. Another advantage of using that method is that dosfstools will be automatically updated just like any other package from wheezy.

ripat wrote:The dosfstools v. 3.0.16-2 from the Jessie repo is working fine and successfully removes the dirty bit. If you don’t want to make a full dist-upgrade, you can use the handy Debian preference pinning system and pick any package from Jessie without breaking your system. Here is how to do:

Just wanted to add my thanks for this post. This fixed my problem and was much easier to complete than other solutions offered. Thanks so much

-Liam