Loops trying to mount NTFS partition after failure

Bug #480564 reported by Gabor Kelemen
46
This bug affects 9 people
Affects Status Importance Assigned to Milestone
mountall (Ubuntu)
Fix Released
Medium
Scott James Remnant (Canonical)

Bug Description

Binary package hint: mountall

I have a windows xp in dual boot, which I used to hibernate. The partition is set to be mounted automatically, but mountall fails to do this at boot, because it contains a hibernated Windows. After failing, it tries again and again, but fails too, as the Windows is still hibernated :).

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

possible dup of bug 479096

Revision history for this message
Gabor Kelemen (kelemeng) wrote :

I just straced the mountall process, like you asked in the other bug.

I also tried to run mountall manually:

$ sudo mountall
fsck from util-linux-ng 2.16
swapon: /dev/disk/by-uuid/674eab72-89bf-4fb6-b4f5-903f5e54f960: swapon failed: Az eszköz vagy erőforrás foglalt
mountall: swapon /dev/disk/by-uuid/674eab72-89bf-4fb6-b4f5-903f5e54f960 [15565] terminated with status 255
mountall: Problem activating swap: /dev/disk/by-uuid/674eab72-89bf-4fb6-b4f5-903f5e54f960
fsck: fsck.ntfs: not found
fsck: Error 2 while executing fsck.ntfs for /dev/sda3
Windows is hibernated, refused to mount.
Failed to mount '/dev/sda3': A művelet nem engedélyezett
The NTFS partition is hibernated. Please resume and shutdown Windows
properly, or mount the volume read-only with the 'ro' mount option, or
mount the volume read-write with the 'remove_hiberfile' mount option.
For example type on the command line:

            mount -t ntfs-3g -o remove_hiberfile /dev/sda3 /media/hdb3

mountall: mount /media/hdb3 [15581] terminated with status 14
mountall: Filesystem could not be mounted: /media/hdb3
^C

The interesting thing is that this get written only once, while at booting, in an endless loop... so maybe the initscript calling mountall is the culprit?

The fstab line for the ntfs partition:
# /dev/hdb3
UUID=96EC35D8EC35B2FB /media/hdb3 ntfs defaults,umask=007,gid=46 0 1

HTH

Revision history for this message
William Grant (wgrant) wrote :

I also see this behaviour with a hibernated Windows partition. Scott, do you need any other data?

Revision history for this message
markusj (markusj) wrote :

Same here, booting Karmic with a hibernated WinXP results in high cpu-loads and harddisk I/O caused by devkit-disks-daemon and gvfs-gdu-volume-monitor.
Killing mountall brings this tortoure to an end.
The in #2 mentioned error message does not only appear while booting, manually invoking mountall leads to the same endless output.

Revision history for this message
Kensey (ubuntu-orion-com) wrote :

Would it be possible for mountall to detect (from the return code or output of mount) that it's dealing with a hibernated Windows partition and just ignore it till the next boot?

More generally (and perhaps more easily implemented), it would be nice to have a way to proactively tell mountall that it should try to mount a partition once only at boot and then just ignore it afterward whether it succeeds or fails.

João Pinto (joaopinto)
Changed in mountall (Ubuntu):
status: New → Confirmed
Changed in mountall (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

There's an strace in bug #479096 showing the continued attempt to mount the NTFS partition; this strange behaviour seems limited to NTFS, something is making it try again over and over again.

(Assumedly mount.ntfs opens the block device for writing, which triggers a udev change event for it)

summary: - Fails to mount hibernated windows partition, and falls into endless loop
+ Loops trying to mount NTFS partition after failure
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Yes, the strace shows us getting a uevent, and that triggering the re-attempt to mount it. Not sure how to filter these out, we need to react to change events for software raid

Revision history for this message
Damiön la Bagh (kat-amsterdam) wrote : Re: [Bug 480564] Re: Loops trying to mount NTFS partition after failure

If you need any more tests performed let me know as I left the machine in
it's current error state and am running LTSP (from another server) on it
until otherwise notified.

2009/12/13 Scott James Remnant <email address hidden>

> Yes, the strace shows us getting a uevent, and that triggering the re-
> attempt to mount it. Not sure how to filter these out, we need to react
> to change events for software raid
>
> --
> Loops trying to mount NTFS partition after failure
> https://bugs.launchpad.net/bugs/480564
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “mountall” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: mountall
>
> I have a windows xp in dual boot, which I used to hibernate. The partition
> is set to be mounted automatically, but mountall fails to do this at boot,
> because it contains a hibernated Windows. After failing, it tries again and
> again, but fails too, as the Windows is still hibernated :).
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/480564/+subscribe
>

--
Met vriendelijke groet,
Damiön la Bagh
Amsterdam, Nederland
==
Look for special offers on www.airfrance.com or www.klm.com

Changed in mountall (Ubuntu):
status: Triaged → Fix Committed
assignee: nobody → Scott James Remnant (scott)
milestone: none → lucid-alpha-2
Revision history for this message
Sonny (aadityabhatia) wrote :

In my case, the failure to mount the ntfs partition was only because the mount point was missing. `service udev stop; sleep 2; service udev start` stopped the continuous logging in /var/log/syslog and /var/log/daemon.log, but I was able to re-trigger it by `mount -a`. Looking at /etc/fstab and checking which partitions weren't mounted, I was able to narrow it down to the ntfs partition. `mount /dev/sdaX /media/drv0` revealed that the target mount point directory was missing.

Note: `service udev restart` didn't stop the log messages, so I had to run `service udev stop; sleep 2; service udev start`

Looks like it's been fixed in Lucid. A meaningful error message somewhere, like "mount failed for XXX reason", would be a plus.

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

This bug was fixed in the package mountall - 2.0

---------------
mountall (2.0) lucid; urgency=low

  [ Scott James Remnant ]
  * "mount" event changed to "mounting", to make it clear it happens
    before the filesystem is mounted. Added "mounted" event which
    happens afterwards.
  * Dropped the internal hooks, these are now better handled by Upstart
    jobs on the "mounted" event.
  * Dropped the call to restorecon for tmpfs filesystems, this can also be
    handled by an Upstart job supplied by SELinux now.
    - mounted-dev.conf replaces /dev hook, uses MAKEDEV to make devices.
    - mounted-varrun.conf replaces /var/run hook
    - mounted-tmp.conf replaces /tmp hook.
      + Hook will be run for any /tmp mountpoint. LP: #478392.
      + Switching back to using "find" fixes $TMPTIME to be in days again,
        rathern than hours. LP: #482602
  * Try and make mountpoints, though we only care about failure if the
    mountpoint is marked "optional" since otherwise the filesystem might
    make the mountpoint or something.
  * Rather than hiding the built-in mountpoints inside the code, put them
    in a new /lib/init/fstab file; that way users can copy the lines into
    /etc/fstab if they wish to override them in some interesting way.
  * Now supports multiple filesystem types listed in fstab, the whole
    comma-separated list is passed to mount and then /proc/self/mountinfo
    is reparsed to find out what mount actually did.
    * /dev will be mounted as a devtmpfs filesystem if supported by the
      kernel (which then does not need to run the /dev hook script).
  * Filesystem checks may be forced by adding force-fsck to the kernel
    command-line.
  * Exit gracefully with an error on failed system calls, don't infinite
    loop over them. LP: #469985.
  * Use plymouth for all user communication, replacing existing usplash and
    console code;
    * When plymouth is running, rather than exiting on failures, prompt the
      user as to whether to fix the problem (if possible), ignore the problem,
      ignore the mountpoint or drop to a maintenance shell. LP: #489474.
    * If plymouth is not running for whatever reason, the fallback action
      is always to start the recovery shell.
  * Adjust the set of filesystems that we wait for by default: LP: #484234.
    * Wait for all local filesystems, except those marked with the
      "nobootwait" option.
    * Wait for remote filesystems mounted as, or under, /usr or /var, and
      those marked with the "bootwait" option.
  * Always try network mount points, since we allow them to fail silently;
    SIGUSR1 now simply retries them once more. LP: #470776.
  * Don't retry devices repeatedly. LP: #480564.
  * Added manual pages for the events emitted by this tool.

  [ Johan Kiviniemi ]
  * Start all fsck instances in parallel, but set their priorities so that
    thrashing is avoided. LP: #491389.
 -- Scott James Remnant <email address hidden> Mon, 21 Dec 2009 23:09:23 +0000

Changed in mountall (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Andy Brody (abrody) wrote :

Will a fix be applied to Karmic? Is there some other workaround? I don't like having to killall mountall on every boot.

Revision history for this message
Jan Koritak (jenda-pudr) wrote :

I have installed mountall 2.5 from lucid to my karmic and the problem is still occuring

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.