Bug 742805

Summary: Boot failure when mounting NTFS partition during boot
Product: [Fedora] Fedora Reporter: Philip Sherman <p.sherman>
Component: ntfs-3gAssignee: Tom "spot" Callaway <tcallawa>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 14CC: jean-pierre.andre, lukas+fedora, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 16:24:08 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Philip Sherman 2011-10-02 21:34:32 UTC
Description of problem:
fsck fails when checking NTFS partition during boot. System drops into single user mode to repair file systems. Only indication of failure is the word "[Failed]", appearing on a blank line.

Windows chkdsk states that there are no problems on the drive.

Version-Release number of selected component (if applicable):
ntfs-3g-2011.4.12-5.fc14.x86_64
ntfsprogs-2011.4.12-5.fc14.x86_64 (newly installed with ntfs-3g upgrade)

How reproducible:
Fails on every boot. 

Steps to Reproduce:
1. Add NTFS partition to fstab, with sixth parameter set to 2. (This forces an fsck check of the drive.)
2. Boot the system
  
Actual results:
System drops into single user mode to repair file systems

Expected results:
Normal boot to GUI login screen

Additional info:
Problem can be bypassed by setting the sixth parameter in the fstab entry to 0, bypassing the fsck at boot time.

The NTFS partition has been mounting during boot since F14 was installed in April,2011. No problems have been encountered until the most recent update to ntfs-3g.


fstab entries:
# This one boots ok
/dev/sda7 /home/astro  ntfs  defaults,uid=500,gid=100 0 0 

#  This one fails
/dev/sda7 /home/astro  ntfs  defaults,uid=500,gid=100 0 2

Comment 1 Tom "spot" Callaway 2011-10-03 21:22:05 UTC
The last update contained a fix to make the ntfsck binary have a symlink to fsck.ntfs, which is why it started trying to fsck any NTFS filesystems configured to be fscked in /etc/fstab.

I think the real issue here is that ntfsck is failing. Can you manually boot into single user mode (append the number 1 to the boot string) and try to run:

/bin/ntfsck /dev/sda7

Single user is the simplest way to ensure that you're not trying to fsck a mounted filesystem, but if you feel comfortable that you can unmount this partition before attempting to run ntfsck, you can do that from a normal boot instead.

Either way, just let me know what happens.

Comment 2 Jean-Pierre André 2011-10-06 10:19:43 UTC
> I think the real issue here is that ntfsck is failing.

And it must be failing because the development of ntfsck has been interrupted years ago before anything useful was developed. This cannot have been possible with earlier versions. If you need a real check, you have to use chkdsk from another OS.

Comment 3 Tom "spot" Callaway 2011-10-06 16:30:45 UTC
(In reply to comment #2)
> > I think the real issue here is that ntfsck is failing.
> 
> And it must be failing because the development of ntfsck has been interrupted
> years ago before anything useful was developed. This cannot have been possible
> with earlier versions. If you need a real check, you have to use chkdsk from
> another OS.

It might not be a bad idea to just drop the ntfsck code from ntfs-3g entirely if there are no plans to make it work.

Comment 4 Jean-Pierre André 2011-10-06 17:59:53 UTC
> It might not be a bad idea to just drop the ntfsck code
> from ntfs-3g entirely if there are no plans to make it work.

I suggest configure'ing without the option --enable-extras, so that unfinished/unsupported tools are not included in the binary rpms.

Comment 5 Tom "spot" Callaway 2011-10-06 18:44:48 UTC
(In reply to comment #4)
> > It might not be a bad idea to just drop the ntfsck code
> > from ntfs-3g entirely if there are no plans to make it work.
> 
> I suggest configure'ing without the option --enable-extras, so that
> unfinished/unsupported tools are not included in the binary rpms.

Unfortunately, all that will do is solicit bug reports to add --enable-extras to the configure line, on the grounds that "Ubuntu does it" or "Debian does it".

There comes a time where you, as the upstream, has to put on your big boy shoes and say "this code doesn't work right" and either fix it or nuke it. :)

Comment 6 Philip Sherman 2011-10-07 15:37:09 UTC
I ran ntfsck against an unmounted ntfs partition and, as expected, it failed. Results follow:
[root@plsT410 ~]# ntfsck /dev/sda5; echo return code $?
Unsupported: replay_log()
Unsupported: check_volume()
Checking 20480 MFT records.
Unsupported cases found.
return code 1

I believe the return code 1 caused the [FAILED] notice when it was executed during the boot process. The real problem here is that, unlike other fsck programs, there was no message stating what was being checked when the failure occurred. This made it an analysis job to figure out what failed. This,of course,is done from the boot failure recovery environment an area that is unfamiliar to many users.

My recommendation:
Remove the symlink to fsck.ntfs that was added in the last update. There's no sense executing a program during boot that will always fail and give a return code 1, stopping the boot process.

Comment 7 Fedora End Of Life 2012-08-16 16:24:10 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping