Hangover polar bear: udisks

Sunday, March 15, 2015

USB HDD Gets Mounted Again After Safely Remove + Workaround

OBSOLETE: See updated info here.

This is actually an update for my previous post: Workaround for USB Drive is Mounted Again After "Safely Remove" on Debian Wheezy

As I have written before, I have had this issue since Debian 7 "Wheezy". When I perform safely remove, my USB HDD always gets mounted again. Then, I had to perform safely remove once more in order to remove my USB HDD for good.

At the time, I was using a laptop with an NVIDIA chipset and this issue did not occur on my friend's laptop which has an Intel chipset. However, I have been using this laptop since before Debian 7 "Wheezy" and it did not have this issue before. It turns out that this issue has not been solved until this post is written (Launchpad Bug 1239087 and Launchpad Bug 792085).

At that time, I started to look at the changes which has been made in linux kernel and udisks source code. Then I found the following lines in udisks /src/helpers/job-drive-detach.c:

/* the remove file is pretty recent (commit as1297, Dec 2009) */
if (sysfs_exists (udev_device_get_syspath (udevice_usb_device), "remove"))
{
g_printerr ("Disabling USB port for device: ");
if (!sysfs_write (udev_device_get_syspath (udevice_usb_device), "remove", "1"))
goto out;
g_printerr ("OK\n");
}

After some further digging, what I understand was that commit as1297 in linux kernel was intended to add sysfs "remove" attribute to USB devices in order to "emulate" Windows safely remove behavior. If my memory serves my right, this commit did not exist during Debian 6 "Squeeze" days and safely remove issue did not exist back then with my laptop.

With my limited C language understanding, I decided to remove the source code lines above and recompile udisks. After this, the safely remove works without the disk getting mounted again! I keep using this recompiled udisks during Debian 7 "Wheezy" days while waiting for a proper fix from the experts since it involves linux kernel.

Here comes the update.

A few months later, I had to buy a new laptop. This time I got a laptop which has an Intel chipset with a hope that i won't encounter that bug again. The laptop comes with Core i5 Haswell and has USB 3.0 ports. Since Debian 7 "Wheezy" does not support Haswell, I had to use Debian 8 "Jessie" which was still in testing. To my surprise, I encountered a similar bug but with USB 3.0 and it is worse. This time, no matter how many times I perform safely remove, the disk keeps getting mounted again. So, I thought I will remove the "offending" code again and recompile udisks. However, Debian 8 "Jessie" uses udisks2 which is an (incomplete) rewrite of udisks. Genius! I cannot apply my previous trick anymore.

I spend a few weeks to figure out what udisks does but udisks2 does not. I copy pasted source codes from udisks to udisks2 without any proper understanding. Then I modify it a bit so that my franken-udisks2 can be compiled. I can't explain it all here since it is quite long. At the end of it, safely remove works again for me on Debian 8 "Jessie"!

You can get the franken-udisks2 that I compiled for Debian 8 "Jessie" i386 below. For AMD64, you will have to compile it on your own (sorry, I am still maintaining i386 machines). Please note that while it works for mine, it may not work for your hardware. However, you can always try it AT YOUR OWN RISK! I AM NOT RESPONSIBLE FOR ANY DAMAGE CAUSED BY IT.

Franken-udisks2 (Debian 8 "Jessie" i386 build + debian source): Dropbox

This bug has existed since at least 2011. I am writing this post with a hope that it can help to solve it once and for all so that I can retire my franken-udisks2. I am willing to provide any information required.

Saturday, October 26, 2013

Workaround for USB Drive is Mounted Again After "Safely Remove" on Debian Wheezy

Some of you might experience this issue whereby after performing "Safely Remove" on a USB disk, it gets mounted again after a few seconds and you have to perform "Safely Remove" once again. Some people found that only nvidia chipsets are affected by this issue.

The details of this issue can be found here:

My laptop which is affected by this issue is an Acer Aspire 4530.

Acer Aspire 4530

00:00.0 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a2)

00:01.0 ISA bridge: NVIDIA Corporation Device 075e (rev a2)

00:01.1 SMBus: NVIDIA Corporation MCP78S [GeForce 8200] SMBus (rev a1)

00:01.3 Co-processor: NVIDIA Corporation MCP78S [GeForce 8200] Co-Processor (rev a2)

00:01.4 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)

00:02.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)

00:02.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)

00:04.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)

00:04.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)

00:07.0 Audio device: NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1)

00:08.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)

00:09.0 SATA controller: NVIDIA Corporation Device 0ad5 (rev a2)

00:0b.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)

00:13.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)

00:14.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)

00:15.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)

00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor HyperTransport Configuration (rev 40)

00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor Address Map

00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor DRAM Controller

00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor Miscellaneous Control

00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor Link Control

02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 9100M G] (rev a2)

08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5764M Gigabit Ethernet PCIe (rev 10)

0b:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)

If my memory serves my right, this issue did not exist on the original Debian Squeeze release 6.0. However, it is introduced in one of Debian Squeeze release update 6.0.X. Until Debian Wheezy release 7.0, this issue has not been fixed yet.

After dissecting changes on Debian Squeeze release updates and a lot of trial and error, I managed to find that this issue occurs after the following linux kernel commit.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=253e05724f9230910344357b1142ad8642ff9f5a

So, it works like this. When "Safely Remove" is clicked, GNOME (or some other window manager) calls udisks. Udisks will then check whether the running linux kernel has "remove" attribute which was introduced on the linux kernel commit above. If "remove" attribute is found, udisks will then poke it to tell linux kernel to perform safely remove on the USB disk.

My conclusion is this issue might be caused by a bug in the linux kernel. However, since I am no expert, I am unable to debug or provide a fix for this. I can only think of some workarounds for this issue until it is fixed.

Revert the above linux kernel commit and recompile the kernel, or
Patch udisks so that it does not poke the "remove" attribute.

Since recompiling kernel will take a lot of time, I ended up choosing to patch udisks instead.

~~You can get the patched udisks here:~~

I have moved on to Jessie. You can get the patched udisks here (i386 build + source): Dropbox