vfat partition fscked on every boot

Bug #125730 reported by Ivan Savcic
This bug report is a duplicate of:  Bug #48806: vfat filesystems should not be fscked. Edit Remove
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: base-installer

vfat partition, which was automatically detected during the installation of Ubuntu 7.04 from the alternate CD, has fs_passno == 1 (sixth field) in /etc/fstab, which leads to it being fscked on every boot.

That field should be 0 for all fat/vfat partitions.

Ivan Savcic (isavcic)
description: updated
Revision history for this message
xteejx (xteejx-deactivatedaccount) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Feisty is no longer supported, can you try with the latest Ubuntu release? Thanks in advance.

Changed in base-installer (Ubuntu):
status: New → Incomplete
Revision history for this message
xteejx (xteejx-deactivatedaccount) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in base-installer (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
Ivan Savcic (isavcic) wrote :

Still happens, even with Ubuntu 9.10!

vfat partition was selected during installation to be mounted on /windows. fsck on boot couldn't check it, causing mounting to "contain errors", thus mounting root partition read-only... This scenario is even worse than previous, which was reported 2.5 years ago.

Changed in base-installer (Ubuntu):
status: Invalid → New
Revision history for this message
Anzenketh (anzenketh) wrote :

Thank you for taking time to report this issue.

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we cannot work on this bug because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.

We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures

What version of the installation are you doing. Are you installing from a live CD? Are you installing to coexist with windows?

Anzenketh (anzenketh)
Changed in base-installer (Ubuntu):
status: New → Incomplete
Revision history for this message
Ivan Savcic (isavcic) wrote :

Dear Anzenketh,

Thank you for replying to the bug report. Please read the first post. It gives you the insight what is wrong, now, as well as 2.5 years ago.

To quote fstab(5) man page:

"The sixth field, (fs_passno), is used by the fsck(8) program to determine the order in which filesystem checks are done at reboot time. The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked."

Why does vfat partition have "1" in that sixth field, given by Ubuntu installer, when obvious values for that field are either "0" or "2"? GNU/Linux fsck tools seem to fail on any vfat errors, so maybe "0" would be in order there, would it not? Because it gets checked and fails to be fixed, whole system stops booting right then and there, because root partition is to be remounted read-only on any errors encountered.

I'm installing from the 9.10 LiveCD and yes, I'm installing to coexist with Windows (which is already installed); I know that there are better choices than vfat if you go 100% Windows-free.

Revision history for this message
Anzenketh (anzenketh) wrote :

I apologize for the misguided reply I must have been asleep when I read that. Thanks for clarifying though it gave me a eye into the issue at hand.

How did you go about setting up for Linux to read your windows partition?
What steps did you take?
Please be as detailed as possible.

I am assuming you have not done a fresh install and only did a apt-get dist-upgrade on this system is that correct?

 I have done a clean install of Ubuntu 9.10 and it can read my NTFS partitions just fine and fsck does not run. However my NTFS partitions do not mount on boot due to they are not in fstab it is in mtab. Having my NTFS partition in fstab is something I would have to setup myself on a install of Ubuntu 9.10

My conclusion of this issue is not a bug due to default install behavior on dealing with NTFS for Ubuntu has changed. The reason why you are still having a issue is your fstab was never changed from your initial install of ubuntu 7.04 which if I remember did automount so could have this issue.

Please reply with the questions above so I can take the appropriate action needed to resolve this bug report.

Revision history for this message
Ivan Savcic (isavcic) wrote :

It was a fresh install on a different machine than before.

When setting up partitions during the installation, I chose to use the preexisting FAT32 Windows partition as vfat, to be mounted on /windows. Installer put it in fstab, with "1" in the sixth field, causing it to be fscked (with the same priority?) as root partition. If fsck finds errors on vfat partition, Ubuntu will remount root read-only and stop booting.

Revision history for this message
Anzenketh (anzenketh) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 48806, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Please continue to report any other bugs you may find.

affects: base-installer (Ubuntu) → ubiquity (Ubuntu)
Changed in ubiquity (Ubuntu):
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.