I recently ran into this issue while configuring my xen box with multiple usb devices. I wanted one to be used by Dom-0, and the other to be used by a VM, so I needed the device to be available to xen-pciback. However, the usb driver was complied into my kernel, so I couldn't just blacklist the driver. My solution was to create a custom initramfs script that unbinds the specific pci port very early in the boot process.
This is Ubuntu 2016.04, but it should work in earlier versions.
There are three files involved. I named them for my specific use case, but ymmv:
The first file, named /etc/unbindpci
file which is a simple csv of the pci device number and the driver (configure as needed here):
0000:08:00.0,xhci_hcd
0000:03:00.0,radeon
Second file /etc/initramfs-tools/hooks/xenfiles
, which copies the above config into the initramfs.
#! /bin/bash
if [ -f /etc/unbindpci ]; then
cp -pP /etc/unbindpci $DESTDIR/etc/unbindpci
fi
Third file is what does the work at boot time, I placed it in /etc/initramfs-tools/scripts/init-top/unbind-early-pci
:
#!/bin/sh
PREREQ=""
prereqs()
{
echo "$PREREQ"
}
case $1 in
# get pre-requisites
prereqs)
prereqs
exit 0
;;
esac
# This only executes if in a xen Dom-0.
# Edit if that's not your use case!
if [ -f /sys/hypervisor/uuid -a -f /etc/unbindpci ]; then
if [ $(cat /sys/hypervisor/uuid) = "00000000-0000-0000-0000-000000000000" ]; then
echo "Unbinding pci ports..."
IFS=,
while read addr driver; do
if [ -f /sys/bus/pci/drivers/$driver/unbind ]; then
echo "Unbinding $addr, device $driver"
echo $addr > /sys/bus/pci/drivers/$driver/unbind
fi
done < /etc/unbindpci
fi
fi
Finally, run update-initramfs -k all -u
and reboot.
I could include support for comments in the config file, and there is a lot of cleanup to do here, but it works for me.
it is not clear which is the current 'officially' supported approach.
Officially supported by whom? If e.g. GNOME includes automount functionality based on udisks, you can be sure it's officially supported by GNOME themselves.
I am more interested in the second (i.e. whatever USB storage device), since for the first I can just add the entries to /etc/fstab
.
There's no "standard way" for doing that. At best, the majority of existing systems have settled on adding automation on top of udisks2
. On its own, udisks doesn't automount anything at all – but it's the "backend" used by many graphical desktop environments (at least both GNOME and Xfce use it; I'm only 80% sure about KDE and Enlightenment).
(So your option 3 would be "udisks2 + automount by udiskie", and option 4 would be "udisks2 + automount by desktop environment".)
Regarding udev rules: whether it's about mounting filesystems or starting services, the short answer is "don't do it" (for various reasons); but the long answer is: "don't do it directly, but you can ask init to do it". So it wouldn't be horrible to run systemd-mount
from an udev rule, which then just passes the mount request to init just like a .mount unit would...
However, expect this to trigger a systemd bug/wart/misfeature: as udev reports the device to be ready only after processing the rules, you could end up with init automatically unmounting the disk because it thinks the device isn't there yet.
Instead, udevil would work better, since it doesn't run anything via rules but only reacts to "device ready" events emitted by udev.
fstab entries are oriented towards static devices. However, they can be sort-of abused for miscellaneous USB sticks by using /dev/disk/by-path/...
, which corresponds to the physical path of a device (e.g. PCI slot 3, USB port 1, partition 1...) This way you can write a fstab entry which matches any disk plugged in to the same USB port.
The autofs kernel automounter is, similarly to udisks, just the backend upon which various automounts can be implemented by userspace. Once an autofs mount is set up, all attempts to access it are reported to the corresponding daemon. The most common implementations are the traditional (maps-based) autofs
, and recently systemd
with the .automount units.
So the "dynamic" USB device logic would still have to be implemented in userspace, and either way it's more work than just using udisks.
With plain systemd, your only option is to build on top of the above fstab "by-path" hack. Once you write a fstab entry for the desired USB port, you can mark it with x-systemd.automount,x-systemd.idle-timeout=300
to use the autofs automounter. (Or, of course, create standalone .mount + .automount units for the same result.)
If you want to dynamically generate automounts for all USB disks on all ports, systemd cannot do that without third-party scripts.
I don't know whether autofsd
can do what you want, but I remember that it supports some kinds of dynamic maps (for user home directories). Perhaps using the program
map-type (and a script which enumerates all connected disks) would work.
Best Answer
So you have this:
The file manager is presenting those error messages, which come from GVfs, which is relaying information from libmtp.
Preventing File Manager Error Popups
Unfortunately, I have not yet discovered a way to suppress error popups in the GNOME/MATE/Cinnamon file manager. Maybe someday, I'll look into the source code to see where the error can be turned off or intercepted.
Since I don't have an answer for this, let's move on to your next-best acceptable option, which is…
Closing File Manager Popups by Command
Here is a script that can be used to clear the popups on GNOME, MATE, and Cinnamon:
If you want an easy command to remember, these will close all the windows in your file manager and cause your desktop to restart your file manager:
killall nautilus
killall caja
killall nemo
Disabling Automounting of Google Pixel
There doesn't seem to be a way to remember to ignore only Google Pixel.
I don't recommend this, and I haven't tested this myself, but to single out Google Pixel, you might have to comment out vendor 18d1 product 4ee1 (Google Pixel) and vendor 18d1 product 4ee2 (Google Pixel debug) in the udev rules and hwdb.
You can find the records with this command:
After commenting out the udev records of Google Pixel, you may need to restart your desktop environment, reboot, and/or run some combination of the following commands:
Again, this is untested, and I don't recommend this especially because in order to mount Google Pixel again, you'd have to undo the manual udev changes.
Explanation
According to
/var/log/syslog
, GNOME is making the error show up because the USB device disappeared on the second attempt to initialize it:In the sample above, GVfs through libmtp identified USB bus 003 device 096 as the Google Pixel device, but the Google Pixel device had already disconnected itself. The next time Google Pixel reconnects, Linux will have assigned a new device ID.
libmtp errors out because it's still trying to work with the device that disappeared. GVfs picks up the error and forwards it to GNOME Files or some other GNOME-based file manager.
Who's At Fault?
Based on what I've discovered, these have room for improvement:
libmtp
libmtp is probably the most responsible in causing this problem.
It should improve error handling when an MTP device is connected and suddenly disconnected. The error should only be passed if the device still exists. If the USB device doesn't exist, it's pointless to try resetting it.
Report issues to libmtp
Android
Android could improve its MTP implementation so that it doesn't disconnect immediately upon connecting to a computer.
Report issues to Android
Nautilus / Caja / Nemo
It would be nice if these software offered a preference to suppress error messages or display them in a less popup-y fashion.
Report issues to GNOME
Report issues to MATE Caja
Report issues to Linux Mint Nemo