vfat filesystems should not be fscked

Didn't we disable fscking of fat filesystems some time ago for just this reason?

This appears to be fixed now. Please reopen if this is not the case.

Scott, there are some reports that this has regressed. Would you have a look?

I can find no evidence of any attempt to prevent FAT filesystems from being checked on boot.

Also from investigation, there's no way to exclude FAT filesystems from the boot check. The filesystem list is inclusive, so to disable FAT, we have to list the filesystem types we do want to check and omit FAT from that list.

That is just too error-prone to consider.

Will revisit for edgy+1 when we do fsck-on-block-device-add rather than "fsck -a"

I originally installed Ubuntu and then upgraded to Breezy via update
manager. In my original install, my fat drivers were marked 0 0 (ie. don't
check) in fstab and I didn't modify them. Some also said on IRC that they
thought this was fixed before (I forget the handle, sorry).

On 10/4/06, Scott James Remnant <email address hidden> wrote:
>
> I can find no evidence of any attempt to prevent FAT filesystems from
> being checked on boot.
>
> Also from investigation, there's no way to exclude FAT filesystems from
> the boot check. The filesystem list is inclusive, so to disable FAT, we
> have to list the filesystem types we do want to check and omit FAT from
> that list.
>
> That is just too error-prone to consider.
>
> Will revisit for edgy+1 when we do fsck-on-block-device-add rather than
> "fsck -a"
>
> ** Changed in: Ubuntu
> Sourcepackagename: None => sysvinit
> Importance: Undecided => Wishlist
> Status: Unconfirmed => Confirmed
>
> --
> vfat filesystems checked by fsck
> https://launchpad.net/bugs/48806
>

--

Firefox (www.getfirefox.com) -- A browser you can trust

I forgot to also mention that upgrading via the update manager did not
modify my fstab either, so the issue must be how fstab is generated in
breezy's installer?

On 10/4/06, Cody Somerville <email address hidden> wrote:
>
> I originally installed Ubuntu and then upgraded to Breezy via update
> manager. In my original install, my fat drivers were marked 0 0 (ie. don't
> check) in fstab and I didn't modify them. Some also said on IRC that they
> thought this was fixed before (I forget the handle, sorry).
>
> On 10/4/06, Scott James Remnant <email address hidden> wrote:
> >
> > I can find no evidence of any attempt to prevent FAT filesystems from
> > being checked on boot.
> >
> > Also from investigation, there's no way to exclude FAT filesystems from
> > the boot check. The filesystem list is inclusive, so to disable FAT, we
> >
> > have to list the filesystem types we do want to check and omit FAT from
> > that list.
> >
> > That is just too error-prone to consider.
> >
> > Will revisit for edgy+1 when we do fsck-on-block-device-add rather than
> > "fsck -a"
> >
> > ** Changed in: Ubuntu
> > Sourcepackagename: None => sysvinit
> > Importance: Undecided => Wishlist
> > Status: Unconfirmed => Confirmed
> >
> > --
> > vfat filesystems checked by fsck
> > https://launchpad.net/bugs/48806
> >
>
>
>
> --
>
>
> Firefox (www.getfirefox.com) -- A browser you can trust

--

Firefox (www.getfirefox.com) -- A browser you can trust

This almost stopped me installing Edgy today. I had to manually kill 'fschk' for my FAT32 partition from terminal window. I can also not boot without getting a hang on this part of the boot process. I am not a 'normal user' I got 20+ years computer experience so I think this is a real problem for 'humans' migrating from different version fo Windows. They will not succeed, It is like the fence in Mexico on the border to the US. I am surprised it is only on the wishlist.

The only way to fix the problem by users is:
1. Boot Knoppix Live CD and manually edit Ubuntu/Kubuntu the /etc/fstab
file.
For each FAT entry in fstab, replace '1' in column 6 with a '0'

2. Save the modified fstab*

Then Kubuntu/Ubuntu no longer checks FAT32 partions and does not destroy
them!
____________________________________
An easy fix by the developers is to create a sed script that replaces '1' in
col 6 of fstab with a '0' for all FAT entries in the fstab. They should have
also provided a patch for the affected versions of Ubuntu/Kubuntu (6.10 and
6.11 since most users do not know how to edit fstab manually!

I am surprised that the developers still has not fixed the bug.

_________________________________________________________________
Get today's hot entertainment gossip
http://movies.msn.com/movies/hotgossip?icid=T002MSN03A07001

The attached one-line sed script can be used either to fix fstab generated
by Ubuntu/Kubuntu installer or it can be distributed as a patch for the
affected Ubuntu/Kubuntu versions that turn on the fsck check for fat/msdos
partitions. For example, for versions 6.06 and 6.10.
Note: I have not tested version 6.11.

# PURPOSE: Turn off the fsck test for vfat and msdos partitions in fstab
# INVOCATION: sed -i.bak -f fix-fstab.sed.txt /etc/fstab
# Note: You must run this script as an administrator!
# SCRIPT: fix-fstab.sed.txt
/^\/dev\/hda.*[ \t]\(vfat\|msdos\)[ \t]/s/^\(\([^ \t][^ \t]*[ \t][
\t]*\)\{5\}\)1/\10/

# ALTERNATIVE SCRIPT: A simpler but less safe version of the above script
#/^\/dev\/hda.*[ \t]\(vfat\|msdos\)[ \t]/s/1[ \t]*$/0/

_________________________________________________________________
Stay up-to-date with your friends through the Windows Live Spaces friends
list.
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mk

Hi, thank you for your bug report.

We've just been trying to reproduce this bug, but couldn't. Is there anything you can tell us about your computer that might give more information. For example:

* Was a specific file, or group of files, involved?
* What names did affected files have?
* Were they all in the same directory, what was the name of that directory?
* How big was the partition that contained the files?
* Which language was the file system?
* Was the file of a particular size?
* Was the file a Windows .lnk file?
* What other symptoms did you notice?

We realise that we're asking lots of questions, but the bug you reported has potentially been identified as being part of a problem tucked away in the internal workings of the operating system and if that is the case, it may affect many users.

Thanks,
Stefan and Onno

Why is this wishlist? This is a serious problem for those who have a FAT32 partition. Especially if it corrupts the filesystem! "Luckily", for me it just hangs.

Kevin, can you please provide us some more information - you report "it just hangs", because we cannot reproduce this problem.

The original report discussed the truncating of a file on a FAT32 file system. This bug was likely caused by an integer overflow, which was fixed in Bug #63831, which also appears to be the same as Bug #47215.

In addition, dosfscheck had a bug that caused a rename of over 10000 files to fail, as reported in Bug #68153.

The original report went on to suggest a work-around by not checking the disk at all, by altering the fstab and scripts were supplied to implement that.

Of course this is not an actual fix of the problem.

The request Stefan and I made, for more information was legitimate. The truncation of a file can be explained by bug #63831, in which case this is a duplicate bug, or it might be caused by another problem, in which case this needs more information.

The wish list status I cannot personally explain, but I suspect it relates to the nature of changing fstab, which in my opinion should not happen anyway, other than as a work-around.

The owner of this bug might have a different opinion and I do not speak for them. All I know is that Stefan and I have been working on the other bugs.

There are several bugs, not just one.
1. When fschk checks FAT/FAT32 partititions, it tries to fix non-existant
errors. I claims that many files are cross-linked and fixes them by
truncating them. Thus, it destroys the correct files!!!
2. There is no EASY way for the user to stop/disable this check!!! Other
versions of Linux (for example, SUSE do not check FAT32 partitions). Thus
checking should be OPTIONAL, only if requested by the user. fschk should be
testing ONLY Linux partitions, not destroying other partitions!

Was a specific file, or group of files, involved? No, many files are
destroyed.
>* What names did affected files have? Various
>* Were they all in the same directory, what was the name of that directory?
>No.
>* How big was the partition that contained the files?
     In all FAT32 partitions.
>* Which language was the file system? XP Pro SP1, English
>* Was the file of a particular size? No
>* Was the file a Windows .lnk file? No
>* What other symptoms did you notice? This check cannot be disabled unless
>the USER modifies fstab before the first boot after the installation.
>Please read my first message...

>From: Onno Benschop <email address hidden>
>Reply-To: Bug 48806 <email address hidden>
>To: <email address hidden>
>Subject: [Bug 48806] Re: vfat filesystems checked by fsck
>Date: Sun, 17 Dec 2006 23:28:47 -0000
>
>Hi, thank you for your bug report.
>
>We've just been trying to reproduce this bug, but couldn't. Is there
>anything you can tell us about your computer that might give more
>information. For example:
>
>* Was a specific file, or group of files, involved?
>* What names did affected files have?
>* Were they all in the same directory, what was the name of that directory?
>* How big was the partition that contained the files?
>* Which language was the file system?
>* Was the file of a particular size?
>* Was the file a Windows .lnk file?
>* What other symptoms did you notice?
>
>We realise that we're asking lots of questions, but the bug you reported
>has potentially been identified as being part of a problem tucked away
>in the internal workings of the operating system and if that is the
>case, it may affect many users.
>
>Thanks,
>Stefan and Onno
>
>--
>vfat filesystems checked by fsck
>https://launchpad.net/bugs/48806

_________________________________________________________________
Get live scores and news about your team: Add the Live.com Football Page
www.live.com/?addtemplate=football&icid=T001MSN30A0701

Thank you for your reply.

I read from your message a high level of frustration. I understand that frustration related to the loss of your data. I'm sorry for your inconvenience.

I'm trying to gather more information regarding your report to be able to fix the problem you describe.

The challenge we have in attempting to fix the problem you are experiencing is that we need to be able to reproduce it. We are not able to do that with the information you've provided.

Can you please attach the output of:
 dosfsck -v -n <partition>

And also give some information about the files, dosfsck wants to fix (e.g. length, filename, whether these files are indeed broken)?

Can you also test, if the version in Feisty will result in the same output? (In case you don't have Feisty installed, please tell us which Ubuntu version/arch you are using, and we can make a .deb for testing purposes, at least for amd64/i386).

Finally, there is no need to send me separate emails, I am subscribed to this bug as are several other volunteers.

kevina@kevina-labtop:~$ sudo dosfsck -v -n /dev/hda3
dosfsck 2.11 (12 Mar 2005)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSWIN4.1"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
     16384 bytes per cluster
        32 reserved sectors
First FAT starts at byte 16384 (sector 32)
         2 FATs, 32 bit entries
   6426624 bytes per FAT (= 12552 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 12869632 (sector 25136)
   1606216 data clusters (26316242944 bytes)
63 sectors/track, 255 heads
 104872320 hidden sectors
  51424065 sectors total
/CONQUEROR_OF_SHAMBALLA.I00
  File size is 0 bytes, cluster chain length is > 0 bytes.
  Truncating file to 0 bytes.

And then it hangs taking up 100% of the CPU. So it did indeed corrupt that file by truncating it!

You really shouldn't be running fsck on non-native Linux partitions!

I should add that you really shouldn't attempt to correct errors on a filesystem with out first asking the user, for this very reason.

Kevin, thank you for your update. What information can you provide about the file /CONQUEROR_OF_SHAMBALLA.I00?

For example:
* What kind of file is it, a game file, a disk image, a backup, etc.?
* How big is it?
* Does this file cause an issue if it's on another FAT volume?
* What size is the FAT volume it's on? (How many files in that directory, how many total files, etc.)

The background to my probing is that so far we have only found issues that are specific to problematic files - and at this time, only those that are of a specific 4Gb length. That is not to say these are the only issues we're facing, but we have to start somewhere.

I won't comment on your second response, because that is not for me to say, other than to re-iterate, I'm here attempting to fix problems with dosfschk application at the moment, not how it is used within Ubuntu.

Some background may assist you, by way of advising you that after preliminary conversations with others I'm in the process of formulating a question to ubuntu-devel about dealing with dirty (FAT) file systems and I expect to include a comment about prompting for fixes as well.

The file is part of the DVD backup. I don't know it's original size but it was part 1 of 2 so it is likely close to 4Gb. If you could tell me how to get it back I could tell you the exact size.

BTW: I did not get a email when you added a comment so it is a good thing I thought to check this bug.

Hi Kevin,

thanks for the info. your case looks like a duplicate of bug #62831, which is fixed in feisty now.
dosfsck -n won't change anything on the partition, so only the test run shouldn't have deleted your file, however the normal boot sequence might have, in case you didn't disable file checking in /etc/fstab. You might be able to get it back with a run of win32's scandisk (probably renamed then).

The duplicate bug #55121 still suggests that there might be more wrong in dosfstools, I'll look into this.

P.S.: I didn't get bug emails as well, was due to a bug in launchpad, which is fixed now.

Cheers,
    Stefan.

Several additional errors in the fstab table generated by Kubuntu 6.06

1. The fsck option is set not only for fat/fat32 partitions, but also for
NTFS partitions as well!

2a. When a user tries to access a blank (empty) DOS floppy disk formatted by
Windows 98, Kubuntu tries to mount it. However, since there is no mount
entry in fstab for fd0, even after 5 minutes of spinning the floppy disk,
the progress is 0 percent!
2b. Moreover, AFTER this futile mount attempt, every time the user log in to
Kubuntu, the following warning is displayed:
"The process for the media protocol died unexpectedly."

The fix for both 2a and 2b is to include an ad hoc entry in fstab for
DOS/Linux floppy disks:
/dev/fd0 /media/fd0 auto rw,user,noauto,umask=007,gid=46 0

Note that fstab generated by Kubunutu 6.06 does not have any entry for fd0!

_________________________________________________________________
Mortgage rates as low as 4.625% - Refinance $150,000 loan for $579 a month.
Intro*Terms
https://www2.nextag.com/goto.jsp?product=100000035&url=%2fst.jsp&tm=y&search=mortgage_text_links_88_h27f6&disc=y&vers=743&s=4056&p=5117

I'll add this to my list, seeing that I'm working on dosfstools.

Onno Benschop, please be aware that the bug was filed against sysvinit, instead of dosfstools. There is no point for Ubuntu to check FAT32 partitions in the first place, especially when dosfsck is buggy.

I am affected by the dosfsck bug #62831 as well. The file got truncated by dosfsck is (4G-1) in size. Dapper LTS hangs when running dosfsck on the FAT32 partition with the big file. Edgy does't halt, but truncates the file size to 0. Running "chkdsk <drive>: /f" in Windows can recover the big file.

Please set the sixth field of the entries for vfat/ntfs partitions to 0 by default in /etc/fstab.

hi all,
         I installed ubuntu 7.04 on a friend's laptop. He is also having some similar issue. In his case however it gives something to do with offset & backup thing. It happens all & every time. I don't have access to the laptop at the present but will do the dosfsck -v -n thing tomorrow & report back .

Hi,

I've got a 100 GB vfat partition and the boot process is seriously slowed down by dosfsck checking this partition. Luckily it does not seem to fix anything, but it slows down the boot process by at least 30 seconds...

I'll just disable the checking in /etc/fstab because I know how to do that. But for less experienced users I think the decision to check vfat partitions should be reconsidered.

Regards,
 Mika

I am also having this issue with Ubuntu 8.10. Ubuntu auto fsck'd my DOS partition and corrupted files even though that partition is not listed in fstab. I consider this to be an extremely severe bug, as it can do a lot of damage to a fat32 filesystem.

If you don't want filesystems checked, put "0" in the fsck pass column of /etc/fstab

Scott:

The Issue here is that Ubuntu installer, at least use too, set this field to "1" by default, when it really should be 0 because running running fsck has proven to be dangerous on a vfat file system. Yes it can be changed after Ubuntu in installed, but by that time it can be too late, since in all likely hood the the file-system was already checked and the damage done. The only way to prevent this is to -- after Ubuntu in installed -- manually edit fstab _before_ Ubuntu boots for the first time.

If the Ubuntu installer still sets this to "1" by default can you please keep this bug open, or a least provide a better justification, rather that just stating the obvious and marking the bug as invalid.

Let's open a task for the Ubuntu Installer then :-)

Is this still an issue for you? What Ubuntu version do you use? Thank you for telling us!

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]