Hi,
One of the most often reported ntfs-3g problems is when automount fails
during boot. Several tools and many people are trying to edit fstab,
incorrectly, ignoring the fact what fstab(5) says:
The order of records in fstab is important because fsck(8),
mount(8), and umount(8) sequentially iterate through fstab doing
their thing.
In the past the right record order could be figured out easily by just
checking out fstab (if one knew what to look for) but considering the
fastly increasing number of user space file systems and their usage, with
their path, library, etc dependencies, it's getting trickier and is a black
magic for most users because they simply expect drives to be mounted
independently of their order in fstab.
One typical, wrongly edited fstab example is:
/dev/hda2 / ext3 defaults 1 1
/dev/hda1 /mnt/windows ntfs-3g defaults 0 0
/dev/hda3 /usr ext3 defaults 0 0
The events:
mount -> /sbin/mount.ntfs-3g ->
-> resolves to <path1>/ntfs-3g via a symlink ->
-> ntfs-3g requires at least <path2>/libfuse*
If <path1> and <path2> aren't mounted yet (almost always under /usr or
/usr/local) then ntfs-3g mount fails.
There are many potential solutions. For example installing everything on
the root file system which may be needed for successful mount. But this
is not always feasible or practical since we could end up putting almost
everything on the root file system in the end.
Another idea is an improved mount strategy:
do {
try to mount all unmounted entries
} while (not all mounted && at least one new was successfully mounted)
This would take care about the dependencies and mount as many file systems
as possible.
What do you think?
Regards,
Szaka
-
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
