Automount a specific USB drive

Actually this is a straight forward thing, however since it has been a while I had to google it myself, and was astonished about how many non-working solutions I found, besides solutions that simply mount every USB according to their label. So here is the straight forward solution to mount a specific USB device to a specific location on your Unix hierarchical file system, using udev. It assumes that you have a running version of udev, and the udev tools. If not, please consult the distribution specific documentation on the Linux distribution of your choice. This might include recompiling your Kernel, as udev will need the following settings:

General setup --->
[*] Configure standard kernel features (expert users) --->
[ ] Enable deprecated sysfs features to support old userspace tools
[*] Enable signalfd() system call
Enable the block layer --->
[*] Block layer SG support v4
Networking support --->
Networking options --->
<*> Unix domain sockets
Device Drivers --->
Generic Driver Options --->
() path to uevent helper
[*] Maintain a devtmpfs filesystem to mount at /dev
File systems --->
[*] Inotify support for userspace
Pseudo filesystems --->
[*] /proc file system support
[*] sysfs file system support

As for Gentoo Linux, the other things you will want to do, is to add “udev” to your USE-flags (by adding it into your /etc/portage/make.conf), get udev installed (calling emerge -avuD sys-fs/udev), and add udev to your sysinit runlevel (rc-update add udev sysinit).

Now to the fun part. First of all you need to get some information about the device you are interested in. There are a number of ways, like using udev monitor, etc. Most of them, to me however, are too messy. If you have no idea about your device and still need to figure things out, blkid -o list will show you a nice table of all devices, their device file, file system type, label, mount point and UUID – everything you need. For me, I know I have a stick with the label “Public” on an OS X with file system type exFat, and now I inserted it into a dual boot Linux with a number of partitions:

ancalagon ~ # blkid -o list
device                            fs_type      label         mount point                           UUID
/dev/sdb1                         vfat                       /boot                                 58FB-332D
/dev/sdb2                         swap                       [SWAP]                                73db158f-0e19-4d17-8c88-a8b0c1dff1f3
/dev/sdb3                         ext4                       /home                                 355af6d8-6f03-4a98-9a45-edafc3ccedde
/dev/sdb4                         ext4                       /                                     63be67f3-5c7c-48ea-a8b3-58dff9da1737
/dev/sda1                         ntfs         Wiederherstellung (not mounted)                     562065062064EF05
/dev/sda2                         vfat                       (not mounted)                         6265-B138
/dev/sda4                         ntfs                       (not mounted)                         6C58731C5872E46C
/dev/sdc1                         exfat        Private       /media/private                        56B6-CE90
/dev/sdd1                         exfat        Public        (not mounted)                         56BE-6477
/dev/sda3                                                    (not mounted)

If you want more information, with the device file you can get it with:

ancalagon ~ # udevadm info /dev/sdd1

I want the stick to be mounted at /media/public, so I need to create a rule file; on Gentoo it lies under /etc/udev/rules.d/90-local-usb.rules. Actually the name is totally arbitrary, except for the number at the beginning, and the extension that always has to be .rules. The number should be something high, because we want udev to first run all other rules (e.g. the ones that assign the device to a device file) before running ours. 90 is a good value for that.

So in my case, this is what I added:

SUBSYSTEMS=="usb", ENV{ID_FS_UUID}=="56BE-6477", ACTION=="add", RUN+="/usr/bin/logger --tag udev Mounting public", RUN+="/bin/mount -o umask=0077,nosuid,uid=1000,gid=1001 '%E{DEVNAME}' /media/public"

We need to provide the system or subsystem, which for an USB device is usb. The UUID comes from blkid and identifies the device. The action triggers when to run the command. In our case, when a new USB device is added and it has the UUID we want. And finally the mount command. I’ve added another command such that there is a log entry but thta is no need. And as I want it to be accessible as user, I added uid and gid accordingly. If you need to find out your user and group id, just run:

ancalagon ~ # id -u 
ancalagon ~ # id -g 

And that’s it. If you want to see if the rule triggers, just run

ancalagon ~ # tail -f /var/log/everything/current

It should output:

[udev] Mounting public

somewhere. And you can <em>simulate</em> the USB event with udevadm, by triggering the rule you just wrote (although this is rather interesting for more general rules that should fit more than just one device). This is how it’s done:

ancalagon ~ # udevadm trigger --action="add" --property-match=ID_FS_UUID="56BE-6477"

dyld: shared cached file was build against a different libSystem.dylib, ignoring cache

After my last update of OS X 10.8.5 my terminals were flooded with above message – like twenty-ish lines when I started and up to six times after each console command I issued, making it impossible to work with the console anymore.

The error message also told me to run update_dyld_shared_cache and restart my machine. That’s what I wanted to do, but when I issued the command this is what my computer presented me with:

pygospa@lalaith ~ % update_dyld_shared_cache
update_dyld_shared_cache failed: you must be root to run this tool

So I switched to my administrator account which who is in sudoers and typed in the command again:

eru@lalaith ~ % sudo update_dyld_shared_cache
 update_dyld_shared_cache: for arch i386, can't put /usr/lib/libtidy.A.dylib in shared cache because it is not owned by root
 update_dyld_shared_cache: for arch i386, can't put /usr/lib/libncurses.5.4.dylib in shared cache because it is not owned by root
 update_dyld_shared_cache: for arch i386, can't put /usr/lib/libutil.dylib in

There where at least 50 of those lines, and as it seemed nothing had been done, so I checked the permissions and as it turned out, all files in /usr where in possession of root except for /usr/lib, which belonged to the administrator. Huh, that’s strange. Anyway, let’s run it with the rights of the administrator then:

pygospa@lalaith ~ % update_dyld_shared_cache
update_dyld_shared_cache failed: you must be root to run this tool

Okay, I actually don’t like changing owners on a Mac, as it might break something, so my first try was to just make the files writeable for everyone. So I switched to /usr/lib, entered a chmod 777 * and got a bunch of permission denied responses:

eru@lalaith /usr/lib % chmod 777 *
chmod: Unable to change file mode on cron: Operation not permitted
chmod: Unable to change file mode on libCoreStorage.dylib: Operation not permitted
chmod: Unable to change file mode on libIOKit.A.dylib: Operation not permitted

Coming from Linux this is really strange, as eru was in possession of all those files… I tried making the directory writeable for everyone – with the same effect. Okay, let’s switch to root – root can do anything.

You’d think…

root@lalaith # l /usr/lib
drwxr-xr-x 316 eru wheel 10744 15 Sep 18:33 lib/
root@lalaith # chown root /usr/lib
chown: /usr/lib: Operation not permitted

Okay. Now I was really puzzled. What the frack is up with this strange behaviour? I did, what any good Windows User does, when he encounters a problem. I rebooted. Same old, same old. Next stop: Google-Town.

Tried sudo update_dyld_shared_cache -force and sudo update_dyld_shared_cache -root / -force, sudo update_dyld_shared_cache -verify

(…)If you suspect the shared cache is somehow corrupt, you can run: sudo update_dyld_shared_cache -verify which re-creates the cache and compares the result with your actual cache file.

and a bunch of other stuff. Nope. Okay, Apple Support Communities, hosted under – sometimes they have pretty good answers. And yep, there was someone with the same problem, and there was an answer marked as “solving my questions”, and it was short, and it just said… what?!

You have a missing or damaged system file. Back up all your data, then boot from your installation DVD and reinstall the OS. Your data will be undisturbed. After rebooting, run Software Update to bring everything up to date. You may have to run it more than once.

You’re kidding. I don’t have time for this, seriously! Fracking Mac, fracking Apple, to hell with this load of crap! I was really angry.

Fortunately I don’t follow instructions straight away, and after a lot of head aching googling and cursing the day, I came across Safe Mode.

Starting up into Save Mode does several things:

  • (…)
  • Mac OS X v10.5.6 or later: A Safe Boot deletes the dynamic loader shared cache at (/var/db/dyld/). A cache with issues may cause a blue screen on startup, particularly after a Software Update. Restarting normally recreates this cache.
  • (…)

Sounds related – and yeah, it solved my problem! Starting into Save Mode is pretty easy: Power down, hold the “Shift”-Key, Power – and keep holding the “Shift”-Key for quite a while – untill the Apple logo appears.

It’ll then take a while – at least on a recent, souped-up Macbook Air it was enough time to brew a new cup of coffee. But it actually came up, I logged in, and: Hey! In Safe Mode the annoying message is gone! Reboot, and yeah, in Normal Mode everything’s back to normal.

The ADM-3A leaving it’s mark

Did you ever ask yourself, why on *NIX-Systems your home directory has the shortcut tilde (~)? Or why on the text editor vim the cursor could not only be moved by the arrow keys but also via H, J, K and L? Why not W, A, S and D, which today is famous as it is used by many games? Well I often did ask myself, but never actually tried to find out why. I had my explanation for H, J, K, L, as they lie on the home row of the keyboard, thus allowing fast movement.

One might think that H, J, K and L an idiosyncrasy of vi/vim, but when you look carefully you find other software that use the same keys for moving: Rouge, Hack and NetHack – the predecessors of Diablo use HJKL. Also the C Shell (csh) and it’s improved and today still popular version TENEX C-Shell (tcsh) can be controlled by H, J, K and L. The most recent tools are the web interfaces from Gmail and Google Labs – as well as the browser Pentadactyl. Of course, for the later tools it’s more convenience than a historical cause. But regarding vim, by accident I just now found out why these keys are used – and why the tilde is the shortcut for the home directory on *NIX systems.

Continue reading