UNIX for Advanced & Expert Users

I have been trying to get USB storage devices to auto-mount themselves under "/media/usb/<dev>" but have been running into some problems with udev (on FC7, btw... running udevd v.106)

Every time I put in a FAT (not 32) USB stick, udev identifies it as "USB storage", identifies the partition and calls it "/dev/sdb1", triggers my rule to create a dev-alias of "/dev/sdb1" to something like "/dev/usb-sdb1", and triggers my other rule to run a "safely mount/unmount" script on that dev-alias.

The problem is when I try to use FAT32. I never get more than a "SCSI Generic" detection, thus never get a "sdb1"... in other words, it looks like FC7/udev cant identify that there is a valid partition there? The problem I have with this is that it kills the auto-mounting. I dont care if there is a dev-node for the partition itself, but if I cannot detect this situation, then I cant run the subsequent mount on "/dev/sdb" for example (which does actually work)

Is there some kind of Kernel USB/FAT32 options that need to be used for this to work? Or am I doing something stupid?

BTW - I will try to get udevmonitor output, but I don't own the machine

Some manufacturers have obnoxiously preformatted their flash drives with no boot sector whatsoever, the FAT32 partition begins right at sector zero like an old-fashioned floppy disk -- meaning the disk, /dev/sdb, does what you'd normally expect the partition to do. There's no /dev/sdb1, you must mount /dev/sdb!

When I encounter a flash drive laid out like that I usually fdisk and reformat it.

Believe it or not, you have helped me significantly.

I admit my udev rules relied heavily on a "USB-Storage" partition existing:

Code:

ACTION=="add", KERNEL=="sd*[0-9]", DRIVERS=="usb-storage",  SYMLINK="usb/%k"
ACTION=="add", KERNEL=="sd*[0-9]", DRIVERS=="usb-storage", RUN+="/bin/mkdir -p /media/usb/%k"
ACTION=="add", KERNEL=="sd*[0-9]", DRIVERS=="usb-storage", RUN+="/bin/mount /dev/%k /media/usb/%k -o sync", OPTIONS="last_rule"

However, if I tried to change them to use the base Kernel name, then all partitioned USB drives were failing... vice versa, when using the partition...

So what I did was push this identification into a script called "usbplug" which does the mkdir, tests if the mount succeeds, and does the rm on an empty dir if necessary after failed mount attempt. This way I can try to mount "/dev/sdc" for a partitioned drive, it will fail, and nobody really cares. But additionally, "/dev/sdb" (a FAT32 non-partitioned disk) will work, as will "/dev/sdc1" (a FAT16 partitioned disk).

Now my rules look like the following (and yes, I got a bit carried away and added an auto-run option):

Code:

# Auto-mount USB storage (on add):
ACTION=="add", KERNEL=="sd*", DRIVERS=="usb-storage", NAME="usb-%k", SYMLINK="usb/%k"
ACTION=="add", KERNEL=="sd*", DRIVERS=="usb-storage", RUN+="/etc/udev/scripts/usbplug --mount /dev/usb-%k /media/usb/%k"
ACTION=="add", KERNEL=="sd*", DRIVERS=="usb-storage", RUN+="/etc/udev/scripts/usbplug --autorun /dev/usb-%k", OPTIONS="last_rule"

You will also note that the rule now uses a "NAME" to insure that all USB mounts are grep-able simply with "mount | grep -i usb"... this helps the script avoid looking at my OS partitions (var, root, etc).

Fun stuff.

I wonder why they can get away without a partition table altogether... seems wrong.

two three four reasons.

1) History. FAT is capable of doing this because this is how floppy disks were formatted.
2) Windows tolerates it for reason #1.
3) It may be simpler for standalone things to understand. (I have a flash drive with references to "Flash Disk Tester 2.0" still left in it somewhere from the factory.) Perhaps also easier for a BIOS to boot from. (There are LOTS of very broken USB boot BIOSes out there.)
4) Windows is, or was, terrible at handling partitions on removable drives. I haven't checked lately but it used to be that any partitions beyond the first were ignored. When it does that why bother having a partition table at all?