gparted brings up devicekit-disks authentication when scanning

Hi, I have a similar problem with karmic 64bit. it mounts the partitions that I want to mount, but it asks for the password[didn't happen in 9.04], and despite successfully mounting them, it says that it wasn't able to mount them, as it's not authorised to do so. Please let me know if you need further information. I am willing to help/retest.

cheers,
/mihai

Hi Mihai,

This did not happen in 9.04 because in Jaunty, devicekit-disks was not yet in use. This is a new bug in karmic.

In fact, if we were still using HAL in karmic instead of devicekit-disks, this problem would not arise in gparted.

Reassigned this bug to devicekit-disks. Please confirm.

I'm starting to wonder: maybe devicekit-disks doesn't support the HAL "automount-locking" mechanism? That could really break several similar programs...

This is twofold:

 - ./gparted.in needs to wrap the actual binary into "devkit-disks --inhibit", similar to the hal-lock stuff (hal will go away soon).

DK-Disks's Inhibit() method got broken recently, this was fixed in http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/commit/?id=e672ccb6917772f2e7f0f4294eb2828193eaa89f .

This bug was fixed in the package devicekit-disks - 007-1ubuntu1

---------------
devicekit-disks (007-1ubuntu1) karmic; urgency=low

  * Upload current Debian git head to pick up recent bug fixes.
  * debian/rules: Enable quilt patch system. Add quilt build dependency.
  * Add 01-mkfs-tempdir.patch: Daemon does not create /var/run/DeviceKit-disks/,
    so mkfs jobs fail. Just create the directory in /tmp, this is what /tmp is
    for, after all. (See https://bugs.freedesktop.org/show_bug.cgi?id=24265)
  * Add 00git-fix-inhibit.patch: Actually make Inhibit() work again. Taken
    from upstream git head. (LP: #428133)
  * Add 02-unlock-CD-trays-after-mounting.patch: Unlike in the hal world, we
    do not have a daemon polling CD drives for eject button presses. In order
    to make hardware tray eject buttons work, unlock the tray after
    mounting a CD. This is pretty much equivalent to yanking out USB sticks,
    which we already handle reasonably (detecting disappeared device,
    force-unmounting). (https://bugs.freedesktop.org/show_bug.cgi?id=24052,
    LP: #397734)
  * Add 03-fix-subsystem-check-for-firewire.patch: Firewire subsystem is
    called "ieee1394" in current Linux. Now check for both "ieee1394" and
    "firewire". This fixes firewire drives to not be considered system
    internal any more. (https://bugs.freedesktop.org/show_bug.cgi?id=24351,
    LP: #442604)
  * Add 04-mount-vfat-with-shortname-mixed-by-default.patch: The previous
    default, shortname=lower, breaks all-uppercase file names ("touch
    FOO" creates "foo"), thus breaks rsync, and Windows compatibility. The
    default was changed in the Linux kernel for 2.6.32 as well.
    (https://bugs.freedesktop.org/show_bug.cgi?id=24129, LP: #428174)
  * Add 05-dont-remove-NULL-values-from-hash-tables.patch: In device_remove(),
    device_file, object_path, or dev are sometimes NULL. Do not attempt to
    remove NULL from the hash tables, since this crashes. This is mainly a
    robustification patch, it does not really fix the underlying
    state bookkeeping. (http://bugs.freedesktop.org/show_bug.cgi?id=24264,
    LP: #414407)

 -- Martin Pitt <email address hidden> Fri, 09 Oct 2009 09:55:41 +0200

Thank you Martin for the tip on devkit-disk --inhibit, and thank you Jan for bringing this to my attention.

Support for devicekit-disks has been added to the upstream gparted repository for inclusion in the next release of GParted.

The relevant git repository commit can be viewed at the following link:
http://git.gnome.org/cgit/gparted/commit/?id=b1667d4f6dac1c1a0da0d6aed528ebdd48c02de4

Regards,
Curtis Gedak

gedakc,

thanks for fixing that. However, any chance that you can fix the patch to not do an either/or, but do both? All the distros are currently in a transition period where hal can't be entirely disabled yet, but dk-disks is already being used, thus you actually need to both.

It's not truly critical since e. g. GNOME in Ubuntu won't actually react to disk change events in hal any more, but it migh still be safer.

Perhaps something like this structure:

COMMAND="gparted.real"
if (hal_lock available)
   COMMAND="hal-lock ... $COMMAND"
if (dk-disks available)
  COMMAND="devkit-disks inhibit ... $COMMAND"

$COMMAND

?

Martin,

I can rework the logic so that if both dk-disks and hal-lock are available then both will be used.

The challenge with the proposed method is that the --run "COMMAND $*" portion of hal-lock requires that the command plus arguments must be within quotes. Otherwise the arguments are not passed to the command. Specifically the quotes are lost on the second parsing after the dk-disks available check.

Do you know how to work around this problem?

Otherwise does the following seem OK with you?

if (dk-disks available AND hal_lock available)
   devkit-disks --inhibit ... hal-lock ... --run "gpartedbin $*"
elif (dk-disks available)
   devkit-disks inhibit ... gpartedbin $*
elif (hal_lock available)
   hal-lock ... --run "gpartedbin $*"
else
  gpartedbin $*
fi

Martin,

The logic for starting up the gparted executable has been changed to use both dk-disks and hal-lock if both are available.

The relevant git repository commit can be viewed at the following link:
http://git.gnome.org/cgit/gparted/commit/?id=d9b892a73f2f078ae6314c4925b438e43fe4392e

I tried karmic's gparted, and was not actually able to replicate the erroneous automount when creating a new partition. It appears in gnome's computer place, but does not get automounted.

So I close the karmic task of this for now. Does anyone actually get a broken behaviour in karmic?

For lucid, the bug is fixed in upstream git and will make it into the next upstream release.

This is fixed in 0.4.8, which I just synced into lucid.

I also tested karmic's version with an internal partition (previously tested an external one). I don't get the policykit dialogs, since the new internal partition is properly marked with "should_automount=0"

I don't get the dialogs anymore but interestingly enough, now when I unmount a partition in gnome (external usb in my case), followed by opening gparted, gparted does not show the device which had that partition. The device has to be mounted in grnome to be viewable in gparted. pitti, if this is an unrelated side effect and you would like me to open another bug, let me know.

komputes [2009-11-21 8:37 -0000]:
> I don't get the dialogs anymore but interestingly enough, now when I
> unmount a partition in gnome (external usb in my case), followed by
> opening gparted, gparted does not show the device which had that
> partition.

That will happen if the device got ejected, not just unmounted. E. g.
if you use the eject symbol in the nautilus bookmark folder, or
right-click and "Eject" (which is the same). If you right click ->
umount, the device should stay available.

If you really just unmounted the device, that'd be a bug; please
report it.

Thanks, Martin

Martin,

It would appear that the devkit-disks command has been renamed to udisks on December 1st, 2009.
See:
http://www.freedesktop.org/wiki/Software/DeviceKit-disks

See also:
https://bugzilla.gnome.org/show_bug.cgi?id=324220#c64