gnome-volume-manager mounting Partition, while working with GParted

I am running the newest Version of Gnome, with Gparted GParted 0.1 from the Dapper Repositories...

yep this program needs to cope with hal... for example, it won't even start when a cd is being written to because it will instist on probing my cd writer...

Hi,

Can you check and confirm if this behaviour is still there with the final release of Dapper?

I can confirm this behavior. It's not hal, it's gnome-volume-manager that's mounting the partitions. This is probably caused by gparted calling an IOCTL to re-read the partition table before it tries to make the change. That part, at least, is good behavior but gparted needs to have some way to either lock the device it's working on so that g-v-m can't have it mounted or perhaps notify g-v-m that it's making changes so that g-v-m knows not to try.

This is definitely a bug, I'd even call it a serious one. It will be present whenever attempting to manipulate a partition table on a removable device.

A possible workaround is to kill gnome-volume-manager (in my case I had to go into gnome-session-properties to kill it).

Upstream bug was marked as a duplicate.

Bug was fixed upstream in CVS.

Daniel, will edgy be updated to gparted-0.3 or will this fix be brought back as a patch?

Colin: what is your feeling about this?

This is REALLY annoying, I can't do pretty much anything because of that. :/ It makes gparted useless here...

Just experienced this in Edgy - Gparted, can confirm it makes things a bit of a pain.

Robert: If you're having problems (as i was) working with a USB disk, just change the setting in "System > Preferences > Removable Drives and Media" so that the box for "Mount removable drives when hotplugged" is un-checked.

Maybe thats not your issue, but might help some other poor sould ;)

I don't know if this is exactly the same problem, but when running gparted on the feisty herd 3, it mounted the disks as it's working on them too. Also, unmounting through the gparted interface simply leads to gnome remounting them.

It seems, that bug #86851 is a duplicate of this bug and this bug can by fixed simply to upgrading to new gparted 0.3.x upstream version (look at bug #81185 ), released on 2006-09-04, look at the release notes (http://sourceforge.net/project/shownotes.php?release_id=444805&group_id=115843 ):
[..]
Bugfixes:
* automountdisabling should work ok now

Btw, you should patch upstream solution of this bug, because it's sort of "dirty hack" (look at http://bugzilla.gnome.org/show_bug.cgi?id=324220#c38 for more info):

 Comment #36 from A. Murat Eren (points: 0)
2007-02-19 11:30 UTC [reply]

I'd like to add some extra information. [When Gparted starts it creates]
/usr/share/hal/fdi/policy/gparted-disable-automount.fdi file, [which] causes some problems as you suspected before. Sometimes it remains there even GParted is not running anymore. Because of this file, HAL doesn't automount USB devices properly.

There are similar bug reports in both Fedora's and Pardus's bug tracking systems (I know there is a FIXME in the code, I just wanted to imply that it really needs to be fixed ;)).

I can confirm the bug for the Feisty Beta, too.

I've just been cursing gparted to hell.
HAL magic is automounting the first partition before even the other partitions are written or even the file system has been made on the first partition.

It makes gparted singularly useless in feisty right now.

Sam

This really is a serious issue. The temporary fix upstream isn't a very good one (though I would have liked to have the new upstream version in Feisty anyway).

Does anyone have a good enough understanding of HAL / gnome-volume-manager, etc. to propose a better solution? AFAIK upstream hasn't come up with anything. The right solution may require something to be added to g-v-m to register a program as suppression mounts or something like that.

This problem is present in feisty fawn 7.04 official release. This should be solved for next official update.

I can confirm that the bug is present in Fesity Fawn 7.04 official release. I was running gparted off the installer live cd in order to repartition my system, and every so often, the partitions would be mounted, causing the repartitioning step to fail. Note that these are not 'removable' drives; these are IDE hard disk partitions!

This bug has been marked as Fix Committed, but the comments suggest that the fix is not a good one, and it certainly has not appeared in Feisty. Can someone change the bug status back?

It is supposed to be solved in the nightly built isos then.

So in your message of 2007-04-22 you were saying that it *had* been solved, not that it *needed* to be solved, in the next official update? If so I misunderstood.

I really mean that it should be solved, not that I am going to solve it. You misinterpreted my words.

Ok - I understand now.

This bug was marked as 'Fix committed' on 12-Sep-2006, but the problem is still present in Feisty. I think the bug status should be changed back.

Some more on this bug...just another account of it:
gnome-volume-manager tries to mount partitions currently being formatted by GParted causing GParted to quit formatting and give an error.

Steps to reproduce:

1) Insert USB drive/thumbdrive (presumably any partition will work, whether internal or external)
2) Watch it mount in Nautilus (if gnome-volume-manager set to automount drives)
 then right-click it in the Places menu and select "Unmount"
3) Open GParted and select that disk/partition.
4) Delete current partition(s) then create a new partition and begin the format.

If gnome-volume-manager is set to automount by selecting "Mount removable drives when hot-plugged"
 it will try to mount the new partition while GParted is still trying to create it, causing
 GParted to quit and give an error:

"GParted 0.2.5

Delete /dev/sdb1 (fat32, 1.91 GiB) from /dev/sdb ( SUCCES )

========================================

Create Primary Partition #1 (fat32, 1.91 GiB) on /dev/sdb ( ERROR )

create empty partition ( SUCCES )

path: /dev/sdb1
start: 34
end: 4000184
size: 1.91 GiB
set partitiontype ( SUCCES )
create new fat32 filesystem ( ERROR )

mkdosfs -F32 -v /dev/sdb1

mkdosfs 2.11 (12 Mar 2005)
mkdosfs: /dev/sdb1 contains a mounted file system.

========================================"

This is important because gnome-volume-manager's default action is to automount removable drives.
I have offered advice many times on Ubuntuforums.org to people experiencing this problem. The quick fix is to
disable automounting when using GParted.

I'm on Feisty

For those who are struggling with this in feisty, a way around this bug is the following:

1) Go to System -> Preferences -> Removable Drives and Media
2) Disable "Mount removable media when hot-plugged" and "Mount removable media when inserted". (I also disable the option "Browse removable media when inserted", but this should not be necessary.)
3) Close
4) Start Gparted: System -> Administration -> GNOME Partition Editor

When you have finished, you can enable the options in step 2)

The issue is not just with removable media. It does the same with all partitions on internal drives as well. I also thing gparted has something to do with it, and not hal. the problem does not occus with fdisk, or even parted. I am unable to use gparted for _any_ partitioning whatsoever. The best i can do is to see what my partition table looks like in the forms of coloured rectangles rather than a list of partitions and cylinders.

THe problem is serious - it makes the Gnome Partiion Manager useless and makes it hell to fiddle with your partitions, which is kindof a day-to-day issue for people who keep reinstalling their operating systems for the fun of it.

Unless I'm mistaken the bug is caused by gparted telling the kernel to re-read the partition tables so that it knows that's it's resizing what it says it's resizing. If it's true that parted doesn't do that by itself then you've got an excellent argument against gparted doing that and I'd highly recommend suggesting it upstream. You can see, though, why it might be a good idea to make sure the tables haven't changed underneath you, but on the other hand if you're editing partition tables with two different programs at the same time you've got bigger problems.

The solution I'd like to see to this would be a d-bus interface for gparted to tell gnome-volume-manager to not mount partitions on the drive it's editing (or re-reading).

This has not been resolved, as it still exists in Feisty (I'm soaking in it) and upstream (according to comments by others). It makes gparted unusable for anything that requires unmounting drives unless you know to kill gnome-volume-manager.

I too have been hit by this bug, in feisty.
I have a whole page of gparted bugs, which I saw during attempts to manage my partitions.
I believe the root cause of most (possibly all) of these bugs is the partition re-mounts.
I believe this bug can cause data loss when mounts occur between sub-tasks in the gparted schedule.

Will try installing the latest upstream gparted.

Maybe this should be classified as critical, and the fix be released in a feisty update?

Finally, to clarify..... I find that in this situation, almost all my drives get mounted, not just the removable ones.

The removable drive fix works. Let me explain what's happening.

Gparted unmounts a file system. The program used to auto-mount removable drives detects an unmounted filesystem, and mounts it. It doesn't matter if it's removable or not, if you c an unmount it, it counts as removable to the program used to auto-detect removable drives. How else does it tell if it's removable, you think there's a hand inside your linux box that feels for removable and non-removable drives? Of course not. It's "removable" if it's unmountable.

Once again, turning off auto-mount removable media WORKS. This is a temp fix, yes, but to be fair it's only an inconvenience to use this fix, it doesn't break anything else.

The bug still persists in the official Feisty.I just wrote a shell script to kill gnome-volume-manager and then start gparted.

$sudo mv /usr/bin/gparted /usr/bin/gpart
$sudo gedit /usr/bin/gparted
Add the following lines:-

#!/bin/sh
killall gnome-volume-manager
gksu /usr/bin/gpart
/usr/bin/gnome-volume-manager
exit

Save the file.
$sudo chmod a+x /usr/bin/gparted

Now open /usr/share/applications/gparted.desktop with gedit or nano (as root)
find the line which says
exec=gksu gparted
   and change this to
exec=gparted
save the file.

This script kills gnome-volume-manager and then starts gparted.On closing gparted , it runs gnome-volume-manager , so that the CDs and USB drives will be automounted.

I'm also suffering from this bug in Feisty; gparted is trying to delete /dev/sda1, re-create it, and then format it to ext3. /dev/sda is a SATA IDE drive, not removable or hotplugable in any way. mke2fs says "/dev/sda1 is mounted; will not make a filesystem here!". Funny that, given gparted happily deleted and re-created the partition successfully. :-)

I'll try the System -> Preferences -> Removable Drives and Media workaround above, but an `apt-get update' temporary fix would be good to stop this foxing others.

Same here. Actually, things are strange, as the partition is mounted and it appears as "unmounted" into gparted.

Here's a screenshot of the result.

I think , the volumes are mounted after Gparted "refreshes" its view of the disk table.So it fails to see that they are mounted.I'm not sure about the technical aspect in this regard though.

I confirm this bug is present in current version (pre-release) of Gutsy Gibbon (7.10)

I confirm this bug is still present in Gutsy Gibbon Herd 5 (running from the Live CD)

This should have been fixed yesterday:

 hal (0.5.9.1-1ubuntu8) gutsy; urgency=low
 .
   * debian/preferences.fdi: Disable automounting for fixed disks. On session
     startup it is not done anyway (since that disables the gnome-mount UI
     which would ask for authentication) and it leads to confusion when
     restarting hal while a session is running. (LP: #138537)

I can also confirm this on the Gutsy Gibbon Tribe 5 LiveCD. I'm also getting crashes during rescans, but I don't have a stack trace yet.

Simon - this bug report wasn't about crashes with gparted but rather hal automounting partitions which interfered with people's ability to use gparted. If you are experiencing crashes please try to reproduce them with the Beta version of Gutsy, which came out yesterday, and submit a new bug report. Thanks in advance!

Indeed, to be clear, when I said I could confirm this, I meant I could
confirm the mounting bug. I would have filed a separate bug for the
crashing, but I didn't have a useful stack trace.

Seems like the solution here would be to teach gparted to disable auto-mounting on startup and set the state back to what it was on close.

This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined. According the the SRU policy, the fix should already be deployed and tested in the current development version before an update to the stable releases will be considered. With 7.10 now released, that policy applies to this bug. See: https://wiki.ubuntu.com/StableReleaseUpdates .

The bug is not being closed as work will continue on fixing it for the next release, Hardy Heron (8.04). To help improve the state of this bug see: https://wiki.ubuntu.com/Bugs/HowToTriage and https://wiki.ubuntu.com/DebuggingProcedures .

Just for the record, another victim here, Gutsy live CD (actually on a persistent USB stick), wasted six hours and two USB sticks yesterday because of this. )-:

I would seriously suggest removing Gparted from the stable distribution if this cannot be fixed for Hoar^H^H^Hardy.

Oh, and also, tangentially, I too get crashes when things don't work out the way Gparted thought they would.

This occurs in Hardy beta even when using sfdisk.

There needs to be a kernel level lock so that ALL clients know not to act on the re-read partition table until AFTER the file systems have been created.

My scripts re-partition the disk and then fail to create the file systems because the vestages of old file systems get mounted by gnome-volume-manager and any other stinky over excited client.

Let me repeat my suggestion to remove gparted from Hoary rather than ship it with this bug still in place. For all intents and purposes, gparted is useless unless you know the less-than-obvious workaround.

I obviously meant Hardy again (-:

The best solution here is probably to lock it via a hal lock like how Ubiquity does things.

Mario, indeed. That's exactly what upstream just committed yesterday.

This is potentially very serious. I needed to do the following:
- Delete a logical partiton.
- Move a different logical partition.
- Resize the extended partition that they were in.
- Create a new primary partition.
However, somewhere in the middle, all the partitions mounted, resulting in the moved logical partition becoming unreadable.

Still an issue! Looks like it's fixed in Intrepid, any possibility for a backport?

$ apt-cache policy gparted
gparted:
  Installed: 0.3.5-1ubuntu3
  Candidate: 0.3.5-1ubuntu3
  Version table:
 *** 0.3.5-1ubuntu3 0
        500 http://se.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status

$ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04

Nominating for Hardy. I think the potential for interference with partitioning in progress justifies an update.

(This is only for gparted/hardy; marking the hal/hardy task that Launchpad also gave me as invalid.)

As was already mentioned, this bug was fixed upstream in gparted 0.3.7 (and better in 0.3.8), which is in Intrepid.

Relevant upstream commits:
  http://svn.gnome.org/viewvc/gparted?view=revision&revision=826
  http://svn.gnome.org/viewvc/gparted?view=revision&revision=846
  http://svn.gnome.org/viewvc/gparted?view=revision&revision=849
  http://svn.gnome.org/viewvc/gparted?view=revision&revision=874

The first one is very intrusive, though, and for an SRU it'd be easier to ship the wrapper script in debian/ and let the packaging handle the renaming of the binary.

Uploaded with attached debdiff, works for me. Now waiting for Steve Langasek or Colin to approve.

Accepted into hardy-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I am able to reproduce the problem with gparted 0.3.5-1ubuntu3 from hardy; however, I still see the problem when using gparted 0.3.5-1ubuntu4 from hardy-proposed (after a reboot, to ensure that hal and udev were in sane states).

Specifically, the way I am reproducing this is with a USB thumb drive that has two existing partitions that look like so (according to fdisk):

Disk /dev/sdd: 2079 MB, 2079850496 bytes
255 heads, 63 sectors/track, 252 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xc3072e18

   Device Boot Start End Blocks Id System
/dev/sdd1 1 114 915673+ b W95 FAT32
/dev/sdd2 132 186 441787+ 83 Linux

(The oddball layout is due to experiementation with resizing /dev/sdd2.) The first partition is formatted as a fat32 partition, and the second is an ext3 partition. If I then tell gparted to resize the first partition, move the 2nd partition to the end of the device, and create a 3rd partition in between the two, after the resize operation completes, nautilus detects the two existing partitions and mounts them, preventing the fsck of the existing ext3 partition from running.

I've attached lshal output while running gparted; it does look like the lock is getting set based on the line:
  info.named_locks.Global.org.freedeskdesktop.Hal.Device.Storage.locked = true (bool)

Marking verification-failed

I just used gparted to reduce the size of a partition on an external usb drive on Intrepid up to date and the partition was mounted during the processus.
In some cases, gparted fail to modify the partition because of this and I had to stop hal daemon to work with gparted.

This just happened to me on intrepid. It looks like it wrote the tables alright, but it still tried to automount before the drive finished formatting, and I got a completely incomprehensible 'could not mount volume' error message that referenced org.freedesktop.Hal...

This bug is once again present in jaunty...

Reopening for Jaunty then.

Having the bug in Intrepid as well, with a USB disk.

One thing I didn't see mentioned (except may be in https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/37768/comments/44) is that the partitioned as mounted by Gnome is still using the *old* partition table, and that even if I unmount it and mount it again with gnome. (I didn't push my luck trying to power off and on again my USB disk, though...)

I find it all the more peculiar that it is suspected, as I understand it, that this spurious mounting is due to gparted asking the kernel to reload the partition table. So I really wonder why Gnome would keep using the old partition informations in that case (bad cache handling?).

However, this bug proved useful: I could backup some data before the partition was actually lost :-P

NB: I checked with fdisk and cfdisk that the partition table was indeed updated. Only Gnome seemed to use the old partition table. I didn't try the "mount" command in a shell.

I saw that this bug is marked as fixed on gparted's bug tracker.
 http://bugzilla.gnome.org/show_bug.cgi?id=324220

I had a look and try to figure out how the fix was supposed to work. It uses hal-lock to prevent HAL to mount the volume gparted is working on, but obviously, it fails to do so...

I am not *at all* a specialist of HAL, but shouldn't hal-lock lock org.freedeskdesktop.Hal.Device.Volume in addition to or instead of org.freedeskdesktop.Hal.Device.Storage? It seems that the mount/unmount functionality are part of the former...

Indeed I am not a specialist of HAL.
According to Curtis Gedak quoting HAL specifications [1], what gparted does with hal-lock should be sufficient.
According to Deji Akingunola [2], the problem would be another program (gnome-mount ?) not honnouring these specifications.

So may be this is not gparted's fault.
Again, just passing the info: I am still no HAL specialist -- but there comments make sense ;-)

[1] http://bugzilla.gnome.org/show_bug.cgi?id=324220#c58
[2] http://bugzilla.gnome.org/show_bug.cgi?id=324220#c59

My bad. I had a mistake in the spelling of the lock name used by hal-lock.

In gparted.in file the lock taken by hal-lock is wrong. The lock taken is
"org.freedeskdesktop.Hal.Device.Storage" while it should be
"org.freedesktop.Hal.Device.Storage".

See http://bugzilla.gnome.org/show_bug.cgi?id=571347

Many thanks to Jonas Pedersen for finding this spelling mistake.

The bug is fixed in the GParted 0.4.3 release.

0.4.3 will be uploaded soon, through bug 305280. This will fix this bug for Jaunty.

This debdiff goes on top of the already attached hardy debdiff; in other words, it's the debdiff against 0.3.5-1ubuntu4 which is already sitting in hardy-proposed, but failed verification due to this typo.

For intrepid I uploaded Jonas' patch in bug 327833:

  http://launchpadlibrarian.net/22532498/gparted_0.3.8-1ubuntu2_to_gparted_0.3.8-1ubuntu3.debdiff

I just added the bug number.

Assigning the Jaunty task to Colin, since he wants to do the sponsoring of 0.4.3 to Jaunty.

gedakc: thanks for the credits, but they should really go to miki who reported bug #327833. He discovered the typo. I just created the patch and forwarded it upstream.

Miki,

Thank you for finding this spelling mistake.

I had given credit to Jonas Pedersen for finding this bug, but Jonas has indicated that you are the true discoverer of the spelling mistake.

Sincerely,
Curtis Gedak
Maintainer of GParted

You're welcome :-)

I hope that, with gparted now using hal-lock, the problems that many people were having with it will be a thing of the past.

Kind regards,
Alain Kalker

I can confirm that, via manual editing, the patch in bug 327833 does address the issue for gparted on hardy. Martin, when can we expect SRU uploads for intrepid and hardy? If nothing else, please pull the existing packages from the -proposed archives. Thanks.

Steve, fixed packages have been waiting in the SRU queue for a week already, but since I uploaded them, I can't process them myself. I'll ping slangasek/cjwatson again.

New versions of gparted have been accepted into hardy-proposed and intrepid-proposed, please test.

I've verified that the package in hardy-proposed, 0.3.5-1ubuntu5 (i386) behaves correctly, altering and resizing partitions without the desktop remounting them. It looks like the amd64 builds are behind in the build queue, once those are available, I'll test the intrepid package.

This bug was fixed in the package gparted - 0.4.3-0ubuntu1

---------------
gparted (0.4.3-0ubuntu1) jaunty; urgency=low

  [ Surfaz Gemon Meme, Colin Watson ]
  * New upstream release (LP: #305280)
    + Added support for ext4 file system (LP: #137872)
      - Support for ext4 is built into version 2.6.28 of the Linux kernel
      - e2fsprogs version 1.41.0 or higher required
    + Fixed bug in german translation (LP: #45449)
    + Fixed 'fails to recognize newly created swap partition'
      (LP: #137700, #114713)
    + Reduced file system information disk reads to improve performance
      (LP: #311470)
    + Fixed typo of "freedeskdesktop" in hal-lock name (LP: #37768)

  * debian/patches
    + dropped 05_GParted_Core.cc.diff, merged upstream
    + refreshed 10_dev_mapper.patch to be applied correctly
    + refreshed 01_fix-desktop.patch to be applied correctly

  * debian/control
    + Added intltool to Build-Depends

  * debian/rules
    + Added --with-help-dir= to build help manual in /usr/share/gnome/help

  * debian/watch
    + Fixed debian-watch-file-should-use-sf-redirector lintian warning.

 -- Surfaz Gemon Meme <email address hidden> Tue, 24 Feb 2009 13:16:44 +0000

I've verified that the version on intrepid-proposed, 0.3.8-1ubuntu3, lets alteration and resizing operations complete. However, while doing this, I did have a hal error pop up while doing so, presumably because it was attempting to mount one of the volumes and failed to do so due to gparted holding the lock. Attached is a screenshot of the ever-so-useful error message dialog (along with the gparted's windows). This seemed to be reproducable when deleting multiple partitions, I couldn't get it to trigger solely on add and resize events.

The updated gparted is able to complete these operations, which it didn't do before the update, so I'm inclined to believe the intrepid version should be released, despite the unpleasant dialogs.

Here's the verbose hald.log from a gparted session that caused the dialog to appear.

And here's a typical gparted detailed transcript from an editing session that caused the error dialog to appear.

This bug was fixed in the package gparted - 0.3.8-1ubuntu3

---------------
gparted (0.3.8-1ubuntu3) intrepid-proposed; urgency=low

  * Fix type in gparted.in.
    Changed org.freedeskdesktop.Hal.Device.Storage to
    org.freedesktop.Hal.Device.Storage (LP: #37768)

 -- Jonas Pedersen <email address hidden> Thu, 12 Feb 2009 19:15:07 +0000

Steve, thanks for testing. I copied intrepid to -updates now, since it improves the situation. It looks ugly, but at least it stops screwing partitions.

Doh, because of the intrepid issue, I didn't tag this as verification-done, but the verification has already been performed for hardy, so it can be released. Marking verification-done to make it visible on the SRU webpages. Thanks.

This bug was fixed in the package gparted - 0.3.5-1ubuntu5

---------------
gparted (0.3.5-1ubuntu5) hardy-proposed; urgency=low

  * debian/gparted.hal-lock-wrapper.sh: Fix typo in the interface name, so
    that the fix actually works.

gparted (0.3.5-1ubuntu4) hardy-proposed; urgency=low

  * Add debian/gparted.hal-lock-wrapper.sh: Run real gparted under hal-lock if
    it is available, to prevent auto-mounting of freshly created partitions.
    Backported from 0.3.8.
  * debian/rules: Install real gparted under /usr/bin/gparted.real, and put
    above wrapper script into /usr/bin/gparted instead. This roughly resembles
    http://svn.gnome.org/viewvc/gparted?view=revision&revision=826 but avoids
    changing the upstream build system for an SRU.
  * LP: #37768

 -- Martin Pitt <email address hidden> Thu, 12 Feb 2009 19:02:38 +0000