I'm running slamd64 - a 64-bit port of slackware (version 12)

I have a Sansa e270r, which under distros like Debian and OpenSuSE, shows up as two separate scsi-generic devices. Assuming I have a flash drive already in /dev/sda (i do in my later pastebins), I should get the Sansa's drive on /dev/sdb, and the Sansa's micro-SD slot on /dev/sdc.

I'm only getting the drive on /dev/sdb.

This is a custom kernel - and I think I may have configured something wrong? It's also possible it's user-space, but dmesg doesn't seem to lead me in that direction. Anyways - now to the useful information:

dmesg output: (see below)
kernel config: http://pastebin.com/f4a58aca5

Note, in the dmesg output above, I already have a USB flash drive in (and on /dev/sda). This issue occurs regardless of any other devices present.

Any ideas what is going on?

Is the Sansa e270r an external drive. For all external drives either allow the system's hal & udev system detect the device and mount it under /media, or use "UUID=" or "LABEL=" instead of a device node in an /etc/fstab. Don't use a directory under /media for the mount point in this case. /media is used for auto mounted removable media. Hal creates and destroys directories under /media. It would be better to use /mnt. You can't rely on the same device node being used every time. That is normal for removable devices.

---

OK, I just looked up Sansa 227r on Google. It is a media device. Does it use a protocol such as mtp or do you interface with it as a fat32 drive. Looking at the specs, it says that it has a microSD expansion slot. That could be what you are seeing as another disk. Suppose that you plug in the device and the Sansa's hard drive is using /dev/sdb and the microSD drive is /dev/sdc. You can get the filesytem UUID from the commands:
udevinfo -q env -n /dev/sdb1

usevinfo -q env -n /dev/sdc1

Here is an example of an fstab entry for a pendrive that I had Christmas music on:
The "noauto" option prevents the system from hanging when you boot up and the device isn't present. The "noatime" option you will want to use on the microSD partition. This will reduce the number of times that the device is written to. The "uid" and "gid" change the ownership and group ownership of the mounted device. The fmask & dmask values allow access to the group and user. Using the "UUID=" entry in /etc/fstab together with the user option means that you will be able to mount the filesystems as a regular user. Other users will not be able to access it.

Thank you for your detailed reply!

You missed an important bit, however. The kernel is not detecting the second component - it's not to the point where HAL or anything could touch it.

It's (supposed to) read as two separate vfat drives. Currently only the internal drive is detecting. If I boot up into a liveCD or such, it works fine. Also works fine in Windows, for what that's worth.


For convenience I'm going to put the dmesg log into the thread rather than on pastebin...

Kernel configuration won't fit... too big for the forum.
Please look at it here.

Try looking at the microSD card in a reader. Some embedded devices don't use fat32 filesystems. Some even use SQLite for serving files and the metadata in a database file instead. The device may not offer the microSD card up to the external usb interface.

However at your end, the usb drive support you have would be enough.

The more I think about it, the more it seems to me that since it is a removable device, you are expected connect the card to the computer directly if you want to copy songs or videos from it or add new material.

I was looking through some howtos installed with the "howto" document package, looking for an Encrypting Disk howto. There is a Linux disk on a chip howto. It is probably on the "www.tldp.org" website as well.