Xubuntu install fail due partition auto mount defeats Gparted

Bug #1078445 reported by Dave H on 2012-11-13
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
GParted
Fix Released
Medium
Thunar Volume Manager
Won't Fix
Critical
gparted (Ubuntu)
Undecided
Unassigned
thunar (Ubuntu)
Undecided
Unassigned

Bug Description

Wanted to install Xbuntu 12.10 along side Win 7 and Ubuntu 12.10. Needed to create 4 further partitions (boot,swap,/ and home) in a pre-exsisting extended partition. Booted from a Xubuntu 12.10 Live CD on my HP Envy Sleekbook and ran up Gparted.

What I expected to happen:
I expected to be able to shrink a 230gig partition and create 4 additional partitions. To my surprise the extended partition was already mounted when I selected unmount partition in Gparted, Gparted completed the action but then Xubuntu remounted it automatically and opened a filemanager window for every other partition as well.

What happened instead:
 I found I could not unmount any partition without it being automatically remounted.

Installed Xbuntu 12.10 on my Desktop (clean install from a CD). Using Gparted I cannot unmount a spare partition without Xubuntu automatically remounting it.

The Automount feature needs an operator control to allow use of Gparted.

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1078445/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Dave H (dave-hills-2009) wrote :

Couldn't see how to target distribtion Xubuntu and I think the Package is the Thunar file Manager.

tags: added: xubuntu
affects: ubuntu → thunar (Ubuntu)
Launchpad Janitor (janitor) wrote :

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

Changed in thunar (Ubuntu):
status: New → Confirmed

this is an annoyance, to work around it in the "Settings Manager" under "Hardware" you will see "Removable Drives and Media" (click it)
un check the 1st 2 items under "Removable Storage", i just uncheck all 3 checked items
I did this fairly early on in this video tutorial, probably the 3ed or 4th thing i did
https://www.youtube.com/watch?v=2sPGEwqoXA0

This is still a problem in Xubuntu 14.04.1. It can cause gparted to fail mid-operation, e.g. the operation partition resize (which takes the existing filesystem and moves it left and then grows it) will fail immediately after the move left. This leaves the disk in a state where the partition has been expanded, but the filesystem it contains has not, so the filesystem does not fill the partition and needs to be repaired.

tags: added: iso-testing trusty

gparted will fail mid-operation because of XFCE automounting the drive. This could be a serious problem resulting in filesystem corruption and data loss, depending on whether or not the interrupted operation is recoverable. See Launchpad bug
https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1078445

Quotes:

"On startup, gparted ends up causing remove/add events to happen for unmounted partitions. Udisks has some logic in it to NOT auto mount partitions that show up on a disk that itself wasn't just hot plugged to prevent this sort of thing from happening. I guess xubuntu uses something else for auto mounting that isn't quite so smart?"

"This is still a problem in Xubuntu 14.04.1. It can cause gparted to fail mid-operation, e.g. the operation partition resize (which takes the existing filesystem and moves it left and then grows it) will fail immediately after the move left. This leaves the disk in a state where the partition has been expanded, but the filesystem it contains has not, so the filesystem does not fill the partition and needs to be repaired."

There are some hints in the older related bug #588530 ("Automounting not prevented with GParted in Ubuntu 10.04"). It appears that this could be a bug in gparted not locking the drive to prevent automounting, or the automounter not respecting the gparted lock.

Changed in thunar:
importance: Unknown → Critical
status: Unknown → Confirmed

The patch to fix this issue in Ubuntu 10 https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/588530/comments/12 relies on there being a "udisks" executable and running "udisks-daemon" process. The 14.04 livecd appears to have udisks2 installed which seems to have a different executable and daemon. So it appears that the gparted wrapper hasn't been updated to cope with udisks2 and this problem is going to affect all Ubuntu 14.04 (not just Xubuntu).

affects: thunar → thunar-volman
Curtis Gedak (gedakc) wrote :

Thanks Chris for your interest in improving GParted.

As far as I know, udisks2 *does not* contain a command to inhibit automounting of devices.

In the past I was told that a "udisks2-inhibit" command existed, but I have not been able to locate it.

If anyone knows how to inhibit or prevent automounting of devices on systems using udisks2 then I'm all ears.

Many other distributions are migrating to systemd. GParted already contains code to prevent systemd automounting.
The relevant code can be found at the following link:

GParted startup script 'gparted'
https://git.gnome.org/browse/gparted/tree/gparted.in

If I recall correctly, ubuntu will be migrating to systemd for future releases (14.10/15.04).

Ubuntu To Switch to Systemd As Default Following Debian Decision
http://www.omgubuntu.co.uk/2014/02/ubuntu-debian-switching-systemd

udisks2 seems to have an inhibit script written by Martin Pitt, it looks like this is a Debian addition that did not make it upstream to freedesktop:

    udisks2 (1.99.0-4) experimental; urgency=low

    * Add debian/local/udisks2-inhibit: Hack to disallow udisks2 mount
      operations for anyone but root while a program is running. This is similar
      to udisks 1.x's "udisks --inhibit .." command. Install it into
      /usr/lib/udisks2/.

    - https://launchpad.net/ubuntu/quantal/+source/udisks2/+changelog

I realise that this will likely be fixed by systemd, but Ubuntu 14.04 will never be switched to systemd, and since 14.04 is an LTS release supported until 2019, people are going to be installing it and potentially hitting this bug for many years to come.

Curtis Gedak (gedakc) wrote :

In the past I tried "which udisks2-inhibit" to find the location of the command, but this always returned no results. I didn't dig any deeper because I regularly use Kubuntu and Ubuntu and the problem with automounting does not occur.

Today I started my Ubuntu 14.04 Virtual Machine and ran the following command:

  find / -name udisks2-inhibit -print 2>/dev/null

which returned the following result:

  /usr/lib/udisks2/udisks2-inhibit

It seams that this command is in a non-standard location which explains why it didn't show up when using the "which" command.

When using Ubuntu 14.04, I have never encountered the problem with automounting of newly created or edited partitions, and I do a lot of testing using Ubuntu and Kubuntu. This make me think the problem might be unique to Xubuntu and perhaps XFCE.

To determine if udisks2-inhibit works on Xubuntu, would you be able to test gparted by using the following command line invocation?

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

As far as I understand, this is a bug in gparted which fails/failed to lock the partition/filesystem. This is a bug that cannot/shouldn't be fixed in thunar-vfs, hence closing invalid.

Sorry, wanted to close it as won't fix.

> In the past I tried "which udisks2-inhibit" to find the location of the command, but this always
> returned no results.

Try apt-file:

        $ apt-file search udisks2-inhibit
        udisks2: /usr/lib/udisks2/udisks2-inhibit

The problem is very easy to reproduce:

        create VM with blank hard drive and boot xubuntu-14.04.1-desktop-amd64.iso
        sudo gparted
        device > create partition table
        partition > new, create 20MB ext4
        apply

Result: as soon as "apply" is clicked, the partition is created, and XFCE file manager (Thunar) mounts the
partition, even though gparted is still running

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

Yes, this appears to fix the problem - as tested above, partitions are created but Thunar does not open.

It can also be reproduced from parted with:

$ sudo parted
(parted) mklabel msdos
(parted) mkpartfs primary ext2 0 20
ign
(parted) <--- XFCE automounts the new partition here

Changed in thunar-volman:
status: Confirmed → Won't Fix
Changed in thunar:
importance: Unknown → Medium
status: Unknown → Confirmed
Curtis Gedak (gedakc) wrote :

A patch for this issue was included in the upstream GParted 0.22.0 release on March 23, 2015.

Changed in thunar:
status: Confirmed → Fix Released
affects: thunar → gparted
Silvia (afonema) wrote :

I've run into a similar problem in a recent install (Wily Werewolf release).
Solved it by changing settings in Thunar Volume Management (post #4 https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1078445/comments/4 ).

Can this be made the default in installer live distribution? Which project would be that?

Launchpad Janitor (janitor) wrote :

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

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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