Unable to mount NTFS partition during system boot while having a separate /usr partition

Bug #1132392 reported by Peter Bašista
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ntfs-3g (Ubuntu)
Fix Released
High
Dimitri John Ledkov

Bug Description

I am using the beta version of 64 bit Ubuntu 13.04 with the latest updates as of today (mountall 2.47).

A few weeks ago, my Ubuntu started to experience mount issues during every boot (Press S to skip mounting ...). The problem is that mountall is unable to mount my NTFS partition during system boot. I don't know why is this happening, but I know that it was definitely possible earlier.

The issue is caused by the fact that I have a separate /usr partition. This partition is higher in /etc/fstab than my NTFS partition, so it should get mounted with a higher priority and preferably earlier. From what I have been able to find out, the boot order is correct and /usr partition gets mounted before NTFS partition, just like it should.

However, mountall somehow tries to mount the NTFS partition "without being aware" that /usr partition has already been mounted. The thing is that despite /usr is already mounted (or already being in the process of mounting, I don't know), I always get this error message that mount.ntfs-3g can not find the shared library libntfs-3g.so.84, which is obviously located in /usr/lib/x86_64-linux-gnu/libntfs-3g.so.84. So, there is definitely some race condition or something else, which causes mountall not to realize that /usr is already mounted.

Maybe it is because mountall does some mounting parallelism and doesn't wait until /usr is mounted. But even if I set fs_passno of my /usr partition to 1, my NTFS partition still refuses to mount with the above mentioned error. If it makes any difference, my /usr partition and the NTFS partition in question are located on different physical drives.

So, I think it would be nice if mountall could be able to determine which mount points must be available and mounted before executing any particular mount command. This could be, in my opinion, easily determined using ldd on a fully running system. Once this information is available, it could be stored in some mountall-specific configuration file which would determine partial mount ordering of the mount points which are currently present in /etc/fstab. I suppose it sould be as easy as that.

Revision history for this message
Steve Langasek (vorlon) wrote :

Nothing so complicated. This is simply a regression in ntfs-3g, which shouldn't have its library in /usr/lib - it should be in /lib.

affects: mountall (Ubuntu) → ntfs-3g (Ubuntu)
Changed in ntfs-3g (Ubuntu):
assignee: nobody → Dmitrijs Ledkovs (xnox)
status: New → Triaged
importance: Undecided → High
Revision history for this message
Peter Bašista (pbasista) wrote :

Okay, thank you for changing the affected package. To complete the information already given, I am using ntfs-3g 1:2013.1.13-1+0ubuntu1.

As you have suggested, a simple and quick workaround would be to copy libntfs-3g.so.84 from /usr/lib/ to /lib. I can confirm that this makes mounting NTFS partitions during boot working again. However, when the package ntfs-3g updates in the future, one would need to copy the new version of this library to /lib again. This not only makes the maintenance of this package uncomfortable, but as the copying step can easily be forgotten, it could result in a system which can not boot without user interaction. Therefore, I see why you have marked the importance of resolving this bug as high.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ntfs-3g - 1:2013.1.13-1+0ubuntu2

---------------
ntfs-3g (1:2013.1.13-1+0ubuntu2) raring; urgency=low

  * Make sure ntfs-3g library is installed in /lib. (LP: #1132392)
 -- Dmitrijs Ledkovs <email address hidden> Mon, 25 Feb 2013 11:25:52 +0000

Changed in ntfs-3g (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Peter Bašista (pbasista) wrote :

Now that's what I call fast and to the point bug fixing! Thank you Dmitrijs!

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.