When using gparted com.canonical.Unity.Devices blacklist is set back to Default of []

[Doug McMahon]

Test Case:
blacklist one or more internal volumes in Unity (r. click on launcher icon > Unlock from Launcher
confirm the volume(s) are now in the com.canonical.Unity.Devices blacklist
Start gparted, drive(s) will be added to the launcher, blacklist will be reset back to []

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: gparted 0.12.1-1
ProcVersionSignature: Ubuntu 3.5.0-16.25-generic 3.5.4
Uname: Linux 3.5.0-16-generic x86_64
ApportVersion: 2.6.1-0ubuntu1
Architecture: amd64
Date: Tue Oct 2 18:10:31 2012
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20120926)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gparted
UpgradeStatus: No upgrade log present (probably fresh install)

[Phillip Susi (psusi)]

This isn't a bug in gparted as it does not know or care about Unity's blacklist.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ernie 07 (ernestboyd)]

This annoying and cluster-producing BUG is NOT present in 12.04

If the powers that be deem this changed functionality important, so be it, as long as they also provide a way to configure Gparted in such a manner as to disable this new behavior.

[Ernie 07 (ernestboyd)]

Will this BUG be fixed before 13.04 or should I AVOID 12.10 and continue to use 12.04?

[Ernie 07 (ernestboyd)]

This bug STILL occurs in 64 bit 1210 (Quantal) with kernel 3.5.0-21-generic

[jaohsbapuabsd (jaohsbapuabsd-deactivatedaccount)]

Another confirmation for quantal amd64 with kernel 3.5.0-21-generic, with gnome-tweak-tool installed, plus xubuntu-desktop and lubuntu-desktop installed alongside. Can right click>unlock from launcher, and disable 'show mounted drives' in gnome-tweak-tool, but all mounted drives return when running gparted. Haven't been able to find a more permanent solution as yet, will advise if I do. Using gparted version 0.12.1-1

[Ernie 07 (ernestboyd)]

This bug STILL occurs in 64 bit 1304 (Raring) with kernel 3.8.0-0-generic.
Downloaded and tested today 2013-01_14

[Andrea Azzarone (azzar1)]

For what I see the problem is in GParted that removes (remove != unmount) all the volumes.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Phillip Susi (psusi)]

Andrea, the problem is not in gparted. I'm not sure exactly what unity is seeing from udisks, and whether udisks is doing the right thing, but the bug is either in udisks not telling unity the right thing, or in unity removing the blacklist when it shouldn't.

[Ernie 07 (ernestboyd)]

Another data point. 12.10 and 13.04 exhibit the SAME behavior when initially started.

This bug STILL occurs in 64 bit 1304 (Raring) with kernel 3.8.0-2-generic.
Downloaded and tested today 2013-01_27

[Ernie 07 (ernestboyd)]

This bug also occurs in 64 bit 1304 (Raring) with kernel 3.8.0-3-generic.
Tested Friday 2013-02_01

[Ernie 07 (ernestboyd)]

This bug also occurs in 64 bit 1304 (Raring) with kernel 3.8.0-6-generic.
Tested Friday 2013-02_16

[Doug McMahon (mc3man)]

There are also other instances where the blacklist is reverted, nothing to do with gparted.
Right now have 2 out of 3 previously blacklisted drives showing in the launcher
9haven't yet found the trigger, if any thing specific
(seen on both raring & quantal

[Ernie 07 (ernestboyd)]

Assume a desktop system with multiple hard drives where each hard drive contains several ext4 partitions.
Mounting a single one of those partitions under 12.04 will result in ONLY the icon for the newly mounted partition to be temporarily added to the launcher icons. When that partition is unmounted, the icon will go away. Launching gparted will NOT cause an icon for one or more partitions to be added to the launcher. When gparted is used to unmount a partition, that partition's icon will be removed. Correct behavior.

Change the environment to a LiveCD or an installed version of 12.10 or
13.04 and things change drastically. Launching gparted will cause ALL
partitions on the drive containing the currently running OS to be locked
to the launcher. However, the swap partition and the partition
containing the currently running OS will not be included.

1. Gracefully shutting down gparted will NOT cause the unwanted icons to be removed.
2. Restarting the OS will NOT cause the unwanted icons to be removed.

In defense of gparted, this appears to be the default behavior for a
LiveCD and for an initial start following a fresh install. Fixing this
problem will kill two birds with one stone.

https://launchpadlibrarian.net/136890856/Gparted%20v0.12.1_13.04_Failure_2013-04-10%2011%3A52%3A06.png

[Ernie 07 (ernestboyd)]

This bug also occurs in 64-bit 1304 (Raring) 3.8.0-18-generic #28-Ubuntu SMP Thu Apr 11 19:38:55 UTC 2013

When Gparted is executed, does it run any of the same code that Raring does when Raring is initially started?

[Ernie 07 (ernestboyd)]

When either 12.10 or 13.04 gets launched after installation, ALL partitions on the drive containing the OS except the OS partition and the swap partition get locked to the launcher and will stay that way following a reboot. If all locked partitions on that drive are individually unlocked, they will stay that way following a reboot.

Apparently, the code that provokes this annoying clutter-producing behavior is executed ONCE during initial startup.
My guess is that this code is also executed each time gparted runs.

So, how do I tell gparted to IGNORE this first-pass code?

[Phillip Susi (psusi)]

That's how Unity works Ernie. It shows you your drives until you tell it not to. This bug is about it forgetting you asked it not to.

[Ernie 07 (ernestboyd)]

Phillip,

Thanks for clarifying that the Unity behavior in 1166996 is by design. Since it changed significantly from 12.04 the design change was interpreted as a bug.

As for 1060484 and 1167002, Gparted exhibits similar behavior which is a real pain.

[Ernie 07 (ernestboyd)]

Using 64-bit RELEASED 13.04 Desktop, Gparted still locks almost ALL partitions that exist on the same drive as the OS to the launcher. The swap partition and the partition containing the running OS do not get locked to the launcher.

[Ernie 07 (ernestboyd)]

In addition to 12.10 and 13.04, this bug also manifests in 64-bit 1310
3.9.0-0-generic #4-Ubuntu SMP Thu May 2 21:43:59 UTC 2013

How can I disable this behavior?

[Ernie 07 (ernestboyd)]

Except for dependency upon Nvidia drivers, I would be quite satisfied with 12,04.
I really would like to put Nvidia drivers in the trash where they belong.

The list of 13.xx BUGs preventing the switch from 12.04 is getting shorter.
Please shorten the list by fixing this BUG promptly. Thanks.

[Ernie 07 (ernestboyd)]

In addition to 12.10 and 13.04, this bug also manifests in 64-bit 1310

3.8.0-22-generic #33-Ubuntu SMP Thu May 16 15:17:14 UTC 2013

How can I disable this behavior?

[Ernie 07 (ernestboyd)]

This CLUTTER-BUG still exists in 13.04 Gparted 0.12.1 and 13.10dev Gparted 0.14.1

Locking every partition on the disk containing the currently running OS except for the swap partition results in CLUTTER. Please provide a way for this unwanted behavior to be disabled.

[Phillip Susi (psusi)]

The bug is still open; you don't need to comment every week or two to make that clear. Doing so only adds clutter.

[Phillip Susi (psusi)]

So I figured out why this is happening. It seems that gparted syncs the partition table on startup, just to make sure that it can. To do this, libparted removes all existing partitions, and then re-adds them. It seems that unity decides to un-blacklist a drive if you unplug it and plug it back in.

[Ernie 07 (ernestboyd)]

Hi Phillip,

Would it make sense for libparted to re-blacklist the partitions that were blacklisted before Unity un-blacklisted them?

[Phillip Susi (psusi)]

No, since libparted has no idea what unity is or where it stores its blacklist, nor should it. I think Unity should not be un-blacklisting the drive just because you yank it and reinsert, but I'm working on patching libparted to avoid removing and re-adding partitions that haven't changed, so it should work around this as far as gparted is concerned.

[Phillip Susi (psusi)]

Well now I can't seem to reproduce the problem under 13.04, can you?

[Ernie 07 (ernestboyd)]

Yes,
 I can reproduce 100% of the time using either 1304 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 or
1310 3.9.0-6-generic #13-Ubuntu SMP Fri Jun 14 15:47:09 UTC 2013 builds. Although it is probably not significant, each OS was installed in a free logical partition.

[Phillip Susi (psusi)]

Just to make sure, you unlock the drive from the launcher, fire up gparted, and it reappears?

[Doug McMahon (mc3man)]

The same behavior is still seen in 13.04 & 13.10. The blacklist will be reset to [] after running gparted.
(If one has any 'orphaned' blacklist entries then it won't be reset to [] though after opening gparted the result will still be the same, persistent icon(s) returned to launcher.

And comment 15 still holds true though not related to gparted

[Ernie 07 (ernestboyd)]

In either OS, I just unlock the partitions from the launcher, fire up gparted, and they reappears. ALL partitions on the hard drive that contains the OS being run except that OS and the swap. Partitions on other disks do not show up.

Grub2 lives on /dev/sda but none of the sda partitions get locked to the launcher because the OS that I am running exists on /dev/sdb. The same locking behavior existed when the only hard drive was /dev/sda.

[Curtis Gedak (gedakc)]

The script that invokes GParted uses hal-lock, udisks, devkit-disks, and most recently systemctl to exclusively lock or otherwise prevent automounting on disk devices.

The history of these tools being installed by default in Ubuntu appears to be:

- Uses HAL (Hardware Abstraction Layer) at least from 10.04 to 10.10
- Uses udisks from 11.04 to 12.04
- Uses udsisk2 from 12.10 to

Note that udisks2 does not appear to provide a facility to exclusively lock the device or otherwise prevent automounting.

Note also that Fedora starting with version 15 uses systemd to perform this task. However systemd is installed by default in Ubuntu.

Is there some other way to acquire an exclusive device lock or otherwise prevent automounting in Ubuntu 12.10+?

If so then that might be a way to prevent this blacklist problem from occuring.

[Curtis Gedak (gedakc)]

Oops, sentence referring to fedora should read:

Hovever systemd is NOT installed by default in Ubuntu.

See https://en.wikipedia.org/wiki/Systemd

[Dimitri John Ledkov (xnox)]

On 18 June 2013 17:43, Curtis Gedak <email address hidden> wrote:
> The script that invokes GParted uses hal-lock, udisks, devkit-disks, and
> most recently systemctl to exclusively lock or otherwise prevent
> automounting on disk devices.
>
> The history of these tools being installed by default in Ubuntu appears
> to be:
>
> - Uses HAL (Hardware Abstraction Layer) at least from 10.04 to 10.10
> - Uses udisks from 11.04 to 12.04
> - Uses udsisk2 from 12.10 to
>
> Note that udisks2 does not appear to provide a facility to exclusively
> lock the device or otherwise prevent automounting.
>

Actually it does.
/usr/lib/udisks2/udisks2-inhibit

wrapper script was added in the package to inhibit udisks2. Originally
upon request from ubiquity installer & usb-creator.

Regards,

Dmitrijs.

[Phillip Susi (psusi)]

The actual mounting or not mounting isn't related to this issue. Simply having the device (re)appear causes Unity to show it, even though it is not mounted until you try to open it, thus inhibiting udisks doesn't help.

[Curtis Gedak (gedakc)]

Dmitrijs,

Thank you for pointing out the udisks2-inhibit command.

Phillip,

Have you tested using udisks2-inhibit to see if it helps?

For example:

   sudo /usr/lib/udisks2/udisks2-inhibit /usr/sbin/gpartedbin

[Phillip Susi (psusi)]

No, and for some reason I am currently unable to reproduce the problem with gparted, but I'm pretty sure it has been around since before udisks2 as I have always been bit by this when building parted, whose test suite creates a lot of temporary devices/filesystems to use for testing, and udisks --inhibit didn't keep them from annoyingly flashing up on the Unity bar.

[Doug McMahon (mc3man)]

The only difference between disks & gparted is the syncing/refreshing occurs when gparted is opened, disk's only does so once some action (partitioning) has occurred.
At the end of the day unity will clear the blacklist if any partitioning takes place so 'solving' this has limited benefit anyway.
(let you open gparted, look around, rename without clearing list

If ubuntu still allowed 3 options (all, none, individual- 'only when mounted') for locking to the launcher maybe this wouldn't be happening but that was/is another bug that's unlikely to be 'fixed'

[Doug McMahon (mc3man)]

For reference - Bug 1053704

[Curtis Gedak (gedakc)]

> The only difference between disks & gparted is the syncing/refreshing occurs when
> gparted is opened, disk's only does so once some action (partitioning) has occurred.

When gparted starts up, it makes a call to the libparted library function ped_disk_commit_to_os(). This checks to see if the kernel can reread the partition table. If not, then gparted disables the "resize/move" menu option. The line of code that performs this check can be viewed at the following link:

https://git.gnome.org/browse/gparted/tree/src/GParted_Core.cc#n310

The by-product of calling ped_disk_commit_to_os() is that libparted removes and re-adds the partitions. This remove/re-add partition action appears to cause the blacklist to be cleared.

To get around this unwanted by-product, one of the following would help:

A) Use some other "non-partition-changing" method to test if the kernel can reread the partition table

or

B) Use some other method to prevent the blacklist from being cleared.

[Curtis Gedak (gedakc)]

or

C) Remove this check, and let resize/move operations fail later.
    Note that based on Doug's comment #41, it appears that the blacklist will be cleared whenever the partition table is actually changed.

[Phillip Susi (psusi)]

Can you run sudo apt-add-repository ppa:psusi/ppa, then apt-get update and apt-get upgrade and see if that fixes it?

[Doug McMahon (mc3man)]

On 06/18/2013 09:05 PM, Phillip Susi wrote:
> Can you run sudo apt-add-repository ppa:psusi/ppa, then apt-get update
> and apt-get upgrade and see if that fixes it?
>
As far as, do partitions show up in the launcher?, no, the ppa
package(s) fix that & the blacklist remains as is.
Though the gparted app itself isn't something acceptable for use, all
partitioning actions produce warnings & apparent errors that aren't
cleared up until a restart.

[Phillip Susi (psusi)]

Oops, I've uploaded a fixed version now, please update and try again.

[Doug McMahon (mc3man)]

On 06/19/2013 12:43 PM, Phillip Susi wrote:
> Oops, I've uploaded a fixed version now, please update and try again.
>
Now that's much better. No launcjer blacklist nonsesnse & app works
correctly with no warnings, reported errors, ect.

[Launchpad Janitor (janitor)]

This bug was fixed in the package parted - 2.3-14

---------------
parted (2.3-14) unstable; urgency=low

  * Merge fix-head-size-assertion.patch from Ubuntu: change an
    assert so it correctly recovers instead of aborting the program
    (closes: #620273).
  * Merge dm_p_separator.patch from Ubuntu: parted would add a
    'p' between the base device name and the partition number for
    all device-mapper devices instead of only if the base name
    ended in a digit.
  * Merge remove-dev_t-dep.patch from Ubuntu: parted was making
    bad assumptions about the meaning of the values of dev_t,
    causing it to fail to detect in-use partitions on all dmraid
    disks, and regular disk partitions > #16.
  * Merge skip-floppy.patch from Ubuntu: add floppies to the list
    of ignored devices since they can not be partitioned anyhow,
    and often people have no floppy though their bios thinks they do,
    and touching it causes hangs.
  * Merge gptsync.patch from Ubuntu: On Intel Mac systems, write a
    synced MBR rather than a protective MBR.
  * Merge loop-partitions.patch from Ubuntu: backport some changes
    to allow the use of partitions on loop devices. This also
    allows more than 16 partitions.
  * Merge dmraid.patch from Ubuntu: Don't probe dmraid partition
    devices. Also set UUID of newly created dmraid partition devices.
  * Merge dm-part-sync.patch from Ubuntu: refactor device-mapper
    partition sync code so it does not fail when unmodified partitions
    are mounted.
  * Merge udevadm-settle.patch from Ubuntu: Run udevadm settle around
    partition table rereads, to avoid races.
  * Merge 16-dos-partitions.patch from Ubuntu: the kernel was not
    being informed of partitions above #16 on dos partition tables
    (closes: #667638).
  * Merge hfs-probe-corrupt.patch from Ubuntu: don't let a corrupt
    FS evoke failed assertion.
  * Backport online resize patches: 0001-parted-resizepart-command.patch,
    0003-libparted-Add-support-for-BLKPG-ioctl-partition-resi.patch,
    and 0004-parted-make-_partition_warn_busy-actually-a-warning.patch
  * Merge fewer-gpt-entries.patch: Backport upstream patches to handle
    GPT labels with fewer than 128 partition entries (LP: #1187560).
  * debian/patches/avoid-disturbing-partitions.patch: Don't remove and
    re-add unmodified partitions (LP: #1060484).
  * debian/patches/linux-specific-gpt-type.patch: Backport upstream
    changes to use a linux specific partition type code instead of
    Microsoft's, which causes Windows to offer to format the partition.

 -- Phillip Susi <email address hidden> Mon, 12 Aug 2013 10:11:10 +0100