Hey gang, I have this 256MB Flash drive, and I'm having troubles mounting in FC2 Linux.
Here's the fstab entry:
/dev/sda1 /mnt/cruzer auto noauto,kudzu,user,owner 0 0
The problem is that I normally use this drive with my Mac, and I recently formatted it with the Mac. When attempting to mount, I get a message that it cannot determine the file system. If I specify the file system as ext3 (which it isn't), the messages are even meaner. I think everything else is right, although I don't know how/why sda1 is the correct device.
Any suggestions as to what filesystem I should go with? I was thinking maybe vfat, because I know Linux and Windows and Mac can all read that.
although I don't know how/why sda1 is the correct device.
i just read something recently that finaly explained why usb devices are sdx...it has to do with linux recognising scsi devices, and when usb devices were introduced they decided to put it under the same device name
So, with the exception of win-formatted zip drives, the first scsi and/or usb device is sda1? If I added another scsi device, it would be sda2, right? Win-formatted zip drives are always sda4, in case anyone was curious.
Actually no. Generally the first generic SCSI device (drive, etc) is sda, the second is sdb, third sdc, etc. I think of it is as SCSI drive "a", SCSI drive "b", etc. Similarly IDE devices are hda (pri/master), hdb (pri/slave), hdc (sec/master), hdc (sec/slave), etc. Also, you can move the zip drive to another device name. For instance, if you already have a real SCSI drive then the zip drive would be sdb4 (like mine). The numbers at the end are the partition numbers. I have no clue why the zip disk partition shows up as partition number #4 but it is an oddity that you must know if you want to mount a zip disk.
Also note that not all SCSI devices show up as sda, sdb, etc. For instance I use Compaq/HP servers with hardware RAID. On one model of the controller the first partition on the first disk on the first controller shows shows up as /dev/ida/c0d0p1. On another model it would show up as /dev/cciss/c0d0p1. Then with the new devfs it might just show up as /dev/scsi/host0/bus0/target0/lun0/part1.
None of that makes much sense. Who came up with this scheme in the first place?
Since we're on the subject, I notice that there is a huge amount of stuff in my /dev folder. Most of it is stuff I would never even think to use. Can they be deleted?
It doesn't make much sense? Heh heh, I makes good sense to me. I believe you can credit Ken Thompson with the design of the device files for accessing devices about 35 years ago. This is very similar to the way most every other OS (*NIX/*NIX like OS that is) does it and I personally really like the flexibility. Probably why it's lasted so long.
As far as deleting the special device files under /dev, you "could" delete unused device files but I would highly recommend not messing with them. These are device files and do not actually take up any space so there is no real reason to delete them.
now, i have no problem mounting my 40gb maxtor external harddrive (sometimes /dev/sda1), or my 128mb usb flashdrive (sometimes /dev/sdb1), but i can't mount an SD card reader (i assumed /dev/sdc1, but i have tried changing the device letter and number, in many combinations, and it didn't find such a device)
like you said that some devices might have strange dev names, is there a weird dev name for a simple PNY SD/MMC card reader? i did a google search and only came up with people saying it should be /dev/sda1
which brings me to another question: is there a way of knowing which mass storage device is sda1/sdb1/etc? i am using a usb hub that plugs into my third usb port on my laptop (first two i use for mouse and external harddrive)
The device file is only part of the equation. You need a driver (kernel module) that knows how to talk to the device that sits between the device and the device file. After plugging in your device you should be able to see it in the output of the "dmesg" command if a driver detected it and is talking to it. If you just want to look for "sdxx" devices you could:
$ dmesg | grep sd
Depending on the type of device you have you should also see it with the "lsusb -v" command, or depending on what kernel you are running by looking at the special files under /proc:
Don't be shy about browsing through /proc. There are some goodies in there. Each driver you are using for whatever device you have hooked up will also likely have information exposed somewhere under /proc that will tell you more if your system isn't automatically setting it up for you. It would be helpful to know the exact make/model of the device(s) you are having trouble with, and it would be helpful to know the distribution and kernel version you are using.
Still having troubles mounting that Cruzer, but I think they are totally different problems. If the disk is formatted to vfat over in Windows, and then mounted by root as sda1 vfat, then the disk is accessible. Problem - the next time I restart, fstab has been wiped, the mount point is gone, and I'm high and dry. Weirdly, changes I have made to zip and cdrom have also been taken back - the users option I added is gone.
So some sort of wicked daemon is rewriting my fstab without permission. I'm wondering if it is kudzu misbehaving. I read the man pages for kudzu, mount, and fstab, and am getting no helpful info about how this process really works.
Do whatever you have to do to get it to automatically add the fstab entry that makes things work, then edit the fstab and remove the keyword "kudzu" from the options on the line in the fstab for your device. This should make the line permanent and kudzu should no longer mess with it. If all else fails:
# /sbin/chkconfig kudzu off
Or, if you want to tinker, the command kudzu actually uses to update the fstab is called "updfstab":
Alright, the Cruzer is now mounting, and is totally hot-pluggable. I had assumed it would be sda1, but I guess the Zip drive at sda4 had taken over all of sda. So the Cruzer gets assigned sdb1. I removed kudzu from fstab. I have no problem mounting these devices by hand as needed.
Your suggestion to run cat /proc/partitions was what cracked the case.
Thanks a ton.
