GNOME Bugzilla – Bug 541372
Rereading partition table from a USB-drive causes ubuntu to automount the partitions being processed
Last modified: 2008-11-19 22:07:13 UTC
Please describe the problem: When changing partition size or moving partitions in Ubuntu on a USB-storage, rereading partition table causes Ubuntu to automount the partitions being processed. This may cause data loss or problems in gparted like failing a step of file system checking (and thus the whole task list), because the partition is mounted. Steps to reproduce: 1. Connect an USB-drive to Ubuntu system (tested in 8.04) 2. Move/resize some partition 3. Partitions from the forementioned disk get mounted during the process. Actual results: Partitions from disk being modified get mounted and process fails for example when fscking. Expected results: To temporarily disable automounting for that drive/patition (if possible) and reenable it again when finished. Does this happen every time? Yes. Other information:
Thank you for reporting this bug MAcks. In GParted 0.3.7, hal-lock was implemented to prevent gnome automounting of partitions. See bug #324220 If upgrading GParted to 0.3.7+ does not correct the problem, please feel free to re-open this bug. *** This bug has been marked as a duplicate of 324220 ***
I just experienced a variation of this problem using gparted 0.3.8-1ubuntu2. I am reporting it here instead of in bug #324220 as it seems it may be specifically related to Ubuntu's implementation of HAL. I'm running Intrepid with 0.5.11-4ubuntu3. I had a 10GB NTFS partition, and a 900GB ext3 partition on an external USB2 drive. I deleted the 10G partition (in fdisk), and then told gparted to move the 900G partition to the start of the disk and resize to full capacity. Suddenly, after "moving partition to the left", a Nautilus window popped up displaying the contents of my *old* NTFS partition (that was supposed to have been erased). I assume it was still able to read the directory structure since the old partition started at the same place as the new one. I wasn't sure what to do, as I obviously wanted to avoid any data loss, but I figured it was safest to just unmount the partition immediately which is what I did. I noticed that hal-lock is actually running, it just was ignored: hal-lock --interface org.freedeskdesktop.Hal.Device.Storage --exclusive --run /usr/sbin/gpartedbin /dev/sdb Unfortunately the move failed as I am now getting USB I/O errors, but I don't believe this is related to the automounting problem. Now I need to focus on recovering this data, but let me know if there is any more information I can give you.
Hi Ryan, Perhaps you could to open this bug with Ubuntu? I believe GParted is doing the right thing by acquiring an exclusive lock on the storage media. Unfortunately it appears that the automounter in Ubuntu is ignoring this lock. From reading the HAL documentation it appears that all programs need to follow the locking mechanism, otherwise it won't work (as you discovered). See the following URL for the following quote: http://people.freedesktop.org/~david/hal-spec/hal-spec.html#locking <<<begin-quote>>> GUIDELINES Locking is only useful if applications requiring exclusive access actually use the locking primitives to cooperate with other applications <<<end-quote?>>> I don't think there is anything more I can do with the GParted code regarding this problem.