Hide Forgot
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
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.
> 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.
(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.
> 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.
(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. :)
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.
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