I have my /usr on a different partition, thus on startup fsck.ntfs doesn't work since libntfs.so is in /usr/lib.
ntfs isnt critical to the booting of any system, so i guess we could move all utils to /usr
(In reply to comment #1) > ntfs isnt critical to the booting of any system, so i guess we could move all > utils to /usr > fsck.ntfs breaks the boot process, so it isn't exactly non-critical. A better solution would be to link fsck statically, if at all possible.
the boot process breaks when you have an invalid fstab. if you had a valid fstab, then your system would boot fine. i.e. your system failing to boot is PEBKAC.
Created attachment 207540 [details] /etc/fstab (In reply to comment #3) > the boot process breaks when you have an invalid fstab. if you had a valid > fstab, then your system would boot fine. i.e. your system failing to boot is > PEBKAC. > In the hope that it helps, here's my fstab, but I can't seem to spot the problem with it. fsck.ntfs still complains about the missing libntfs, and prompts for "root password to enter maintenance mode or ctrl-d to continue", thereby breaking an unattended boot process. A temporary workaround has been to #"USE=minimal" emerge ntfsprogs which apparently prevents fsck.ntfs from being built
if you read fstab(5), you'll see that using "2" in the passno means "check this filesystem". you should be using "0" like it says to avoid checking the disk.
(In reply to comment #5) > if you read fstab(5), you'll see that using "2" in the passno means "check this > filesystem". you should be using "0" like it says to avoid checking the disk. > This is exactly what this bug report is about. The fstab is set up to check the partitions, thus I'm expecting the fsck to pass, or act in the case of a /filesystem/ error. The check fails because ntfsck relies on a library that may reside on another partition that may not have been mounted yet. This is somewhat counterintuitive for a filesystem tool. Since ntfsprogs-2.0.0 the fsck part fails, with the initial introduction of ntfsck. This may be a problem with how the ntfsprogs developers handle it, but as long as they don't change their tools' behaviour, for me it is the integration into Gentoo that fails, hence a bug.
i didnt say there wasnt a bug -- that's why this is still open. read comment #3 again.
ntfsprogs is dead. switch to ntfs3g[ntfsprogs].