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

Bug #37768 reported by E-B on 2006-04-02
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released
gparted (Baltix)
gparted (Ubuntu)
Colin Watson
Declined for Gutsy by Henrik Nilsen Omma
Martin Pitt
Martin Pitt
Colin Watson
hal (Ubuntu)
Martin Pitt
Declined for Gutsy by Henrik Nilsen Omma
Martin Pitt
Martin Pitt

Bug Description

A really annoying think is that Gnome (I think hal) is mouting the partition when I working on them.
For excamle:
I wanted to elarge a excisting Partition on my extern USB drive (sda1 (100Gb) to sda1 (120Gb)). I remove sda2 and do all in GParted. But First I unmount the 2 Partition with umount.
While GParted was working Gnome suddenly mount the 2 partitions.. And GParted failed...

E-B (ebelt9hf) wrote :

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

Andrea Garbarini (garba) wrote :

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...

Uphaar Agrawalla (uphaar) wrote :


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

Changed in gparted:
assignee: nobody → desktop-bugs
status: Unconfirmed → Needs Info
Andrew Jorgensen (ajorg) wrote :

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).

Changed in gparted:
status: Needs Info → Confirmed
Andrew Jorgensen (ajorg) wrote :

Upstream bug was marked as a duplicate.

Changed in gparted:
status: Unknown → In Progress
Changed in gparted:
status: In Progress → Fix Released
Daniel Holbach (dholbach) wrote :

Bug was fixed upstream in CVS.

Changed in gparted:
status: Confirmed → Fix Committed
Andrew Jorgensen (ajorg) wrote :

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

Daniel Holbach (dholbach) wrote :

Colin: what is your feeling about this?

Robert Nasiadek (robzon) wrote :

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

Simon Miller (goonjm) wrote :

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.

Mantas Kriaučiūnas (mantas) wrote :

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 ( ):
* automountdisabling should work ok now

Mantas Kriaučiūnas (mantas) wrote :

Btw, you should patch upstream solution of this bug, because it's sort of "dirty hack" (look at 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 ;)).

ubu-for (ubu-for) wrote :

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

Sam Liddicott (sam-liddicott) wrote :

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.


Andrew Jorgensen (ajorg) wrote :

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.

Changed in gparted:
assignee: desktop-bugs → nobody

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

Ian Hinder (ian-hinder) wrote :

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?

Bump (bump55) wrote :

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

Ian Hinder (ian-hinder) wrote :

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.

Bump (bump55) wrote :

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

Ian Hinder (ian-hinder) wrote :

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.

Ben Wilber (benwilber) wrote :

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 to people experiencing this problem. The quick fix is to
disable automounting when using GParted.

Ben Wilber (benwilber) wrote :

I'm on Feisty

Sfjfudnfj (safjlw) wrote :

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.

Andrew Jorgensen (ajorg) wrote :

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).

Chuck Leduc (celeduc) wrote :

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.

Changed in gparted:
status: Fix Committed → Incomplete
Robert North (russetrob) wrote :

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.

yoda2031 (yoda2031-hotmail) wrote :

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:-

killall gnome-volume-manager
gksu /usr/bin/gpart

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
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.

Eugene (varnav) wrote :

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

Changed in gparted:
status: Incomplete → Triaged

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

Martin Pitt (pitti) wrote :

This should have been fixed yesterday:

 hal ( 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)

Changed in gparted:
assignee: nobody → pitti
status: Triaged → Fix Released
Simon Ruggier (simon80) wrote :

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.

Brian Murray (brian-murray) wrote :

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.

Changed in gparted:
status: Fix Released → Confirmed
Henrik Nilsen Omma (henrik) wrote :

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: .

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: and .

Changed in gparted:
importance: Undecided → Medium
status: New → Confirmed
era (era) wrote :

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.

era (era) wrote :

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

Changed in gparted:
status: Confirmed → Fix Released
Changed in gparted:
status: Fix Released → Confirmed
Sam Liddicott (sam-liddicott) wrote :

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.

era (era) wrote :

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.

era (era) wrote :

I obviously meant Hardy again (-:

Mario Limonciello (superm1) wrote :

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

Martin Pitt (pitti) wrote :

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

Changed in gparted:
status: Confirmed → Fix Released
Ezra Morris (ezramorris) wrote :

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
  Installed: 0.3.5-1ubuntu3
  Candidate: 0.3.5-1ubuntu3
  Version table:
 *** 0.3.5-1ubuntu3 0
        500 hardy/main Packages
        100 /var/lib/dpkg/status

$ lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04

Colin Watson (cjwatson) wrote :

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.)

Changed in hal:
status: New → Invalid
Changed in gparted:
importance: Undecided → Medium
status: New → Confirmed
Colin Watson (cjwatson) wrote :

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

Changed in gparted:
status: Confirmed → Fix Released
Martin Pitt (pitti) wrote :

Relevant upstream commits:

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.

Martin Pitt (pitti) on 2008-10-13
Changed in gparted:
assignee: nobody → pitti
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

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

Steve Langasek (vorlon) wrote :

Accepted into hardy-proposed, please test and give feedback here. Please see for documentation how to enable and use -proposed. Thank you in advance!

Changed in gparted:
status: In Progress → Fix Committed
Steve Beattie (sbeattie) wrote :

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: = true (bool)

Marking verification-failed

Martin Pitt (pitti) on 2008-11-11
Changed in gparted:
status: Fix Committed → In Progress
Id2ndR (id2ndr) wrote :

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.

Luke Schlather (luke2760) wrote :

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...

Martin Pitt (pitti) wrote :

Reopening for Jaunty then.

Changed in gparted:
assignee: nobody → pitti
status: Fix Released → Confirmed

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

One thing I didn't see mentioned (except may be in 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.

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...

Martin Pitt (pitti) on 2009-01-26
Changed in gparted:
status: Fix Released → Confirmed
status: In Progress → Confirmed
status: Confirmed → In Progress

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 ;-)


Curtis Gedak (gedakc) wrote :

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

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


Many thanks to Jonas Pedersen for finding this spelling mistake.

The bug is fixed in the GParted 0.4.3 release.

Martin Pitt (pitti) wrote :

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

Changed in gparted:
assignee: nobody → pitti
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

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.

Martin Pitt (pitti) wrote :

For intrepid I uploaded Jonas' patch in bug 327833:

I just added the bug number.

Martin Pitt (pitti) wrote :

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

Changed in gparted:
assignee: pitti → kamion
status: Confirmed → Fix Committed
status: In Progress → Fix Committed
Jonas Pedersen (jonasped) wrote :

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.

Curtis Gedak (gedakc) wrote :


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.

Curtis Gedak
Maintainer of GParted

Alain Kalker (miki4242) wrote :

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

Steve Beattie (sbeattie) wrote :

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.

Martin Pitt (pitti) wrote :

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.

Steve Langasek (vorlon) wrote :

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

Steve Beattie (sbeattie) wrote :

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.

Launchpad Janitor (janitor) wrote :

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, 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

Changed in gparted:
status: In Progress → Fix Released
Steve Beattie (sbeattie) wrote :

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.

Steve Beattie (sbeattie) wrote :

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

Steve Beattie (sbeattie) wrote :

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

Launchpad Janitor (janitor) wrote :

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

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

  * Fix type 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

Changed in gparted (Ubuntu Intrepid):
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

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.

Steve Beattie (sbeattie) wrote :

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.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

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

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

  * debian/ Fix typo in the interface name, so
    that the fix actually works.

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

  * Add debian/ 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 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

Changed in gparted (Ubuntu Hardy):
status: Fix Committed → Fix Released
Changed in gparted:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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