I hope someone will help me. I have a Sony MicroVault USB solid state drive. I have no problem mounting it with "mount /mnt/sony". After unmounting, everything's ok, until I unplug it. Then two things happen: the directory /mnt/cdrom disappears, as well as /dev/cdrom, which is a symbolic link to /dev/scd0. If I create these files I can use the cdrom again. (I haven't tried to do this while the cdrom is mounted.)
I have the following lines in /etc/fstab
/dev/sda /mnt/sony vfat noauto,user 0 0
/dev/sda1 /mnt/camera vfat noauto,user 0 0
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0
Am I using the wrong devices?
Thanks in advance,
Jose Miguel Pasini
(To reach me, replace the spelled-out numbers in the address with actual numbers)
Your newsreader is producing extremely long lines. Please set it to
wrap lines at 72 characters.
> I have a Sony MicroVault USB solid state drive. I have no problem
> mounting it with "mount /mnt/sony". After unmounting, everything's ok,
> until I unplug it. Then two things happen: the directory /mnt/cdrom
> disappears, as well as /dev/cdrom, which is a symbolic link to
> /dev/scd0. If I create these files I can use the cdrom again.
Which version of which distro are you using? What's the output of
"uname -a"?
> /dev/sda /mnt/sony vfat noauto,user 0 0
This is a little weird. Usually, USB storage devices are partitioned.
> /dev/sda1 /mnt/camera vfat noauto,user 0 0
> /dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0
Try removing the "kudzu" from the /dev/cdrom line. kudzu has, IME,
caused more problems than it's prevented.
> Am I using the wrong devices?
No. Something else is going wrong, possibly kudzu, possibly the hotplug
daemon. It's very difficult to tell what's going on here. After you
unplug the USB device, do "dmesg | tail -20" and post the output.
--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong
http://www.brainbench.com / "He is a rhythmic movement of the
-----------------------------/ penguins, is Tux." --MegaHAL
Your suggestion of removing "kudzu" from the cdrom line in /etc/fstab
worked. Thank you! I've inserted some questions in your answers.
Thanks again,
Jose Miguel Pasini
On 7 Oct 2003 23:12:03 GMT
Dances With Crows <danSPANcesw...@usa.net> wrote:
> On Tue, 7 Oct 2003 18:00:34 -0400, Jose Miguel Pasini staggered into
> the Black Sun and said:
>
> Your newsreader is producing extremely long lines. Please set it to
> wrap lines at 72 characters.
Thanks for the tip. Fixed.
> > I have a Sony MicroVault USB solid state drive. I have no problem
> > mounting it with "mount /mnt/sony". After unmounting, everything's
> > ok, until I unplug it. Then two things happen: the directory
> > /mnt/cdrom disappears, as well as /dev/cdrom, which is a symbolic
> > link to/dev/scd0. If I create these files I can use the cdrom again.
>
> Which version of which distro are you using? What's the output of
> "uname -a"?
Sorry for the slip. I am using RedHat 8.0, and uname -a gives
Linux localhost.localdomain 2.4.20-20.8 #1 Mon Aug 18 14:59:07 EDT 2003
i686 i686 i386 GNU/Linux
> > /dev/sda /mnt/sony vfat noauto,user 0 0
>
> This is a little weird. Usually, USB storage devices are partitioned.
Please elaborate on this. I really know very little about devices. I
just searched the web for solutions, and somebody had this line. What do
you think I should use? I guess your suggestion also applies to my
digital camera.
Actually, I don't know how to find which device corresponds to any piece
of hardware. For example, when I plug in the USB storage device, the
following directory appears: /proc/scsi/usb-storage-0 and inside it
there's one file called "1", which contains
Host scsi1: usb-storage
Vendor: Sony
Product: USB Mass Storage Device
Serial Number: None
Protocol: 8070i
Transport: Bulk
GUID: 054c008b0000000000000000
Attached: Yes
How do I get from this information that the device is attached to
/dev/sda?
> > /dev/sda1 /mnt/camera vfat noauto,user 0 0
> > /dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0
>
> Try removing the "kudzu" from the /dev/cdrom line. kudzu has, IME,
> caused more problems than it's prevented.
I removed "kudzu" from the /dev/cdrom line and now everything works
fine. Thank you very much!! What does "kudzu" do?
Running cdrecord --scanbus shows me :
scsibus0:
0,0,0 0) 'IBM ' 'DORS-32160 ' 'S84A' Disk
0,1,0 1) *
scsibus1:
1,0,0 100) 'IOMEGA ' 'ZIP 250 ' '31.G' Removable Disk
scsibus2:
2,0,0 200) 'LEXAR ' 'DIGITAL FILM ' '/W1.' Removable Disk
scsibus3:
3,0,0 300) '_NEC ' 'DVD_RW ND-1300A ' '1.05' Removable CD-ROM
3,1,0 301) 'PLEXTOR ' 'CD-R PX-W4824A' '1.02' Removable CD-ROM
(I've shown only the relevant lines from the output in this example)
From this I know that the IBM drive is /dev/sda, the zip drive is
/dev/sdb, the usb-brick is /dev/sdc and so on.
Because of the pertitioning of zip disks they usually have the 4th
partition set as the only partition on the drive (I don't know why they
chose to partition the disks this way). So I can mount the zip drive
(with a "standard" disk in) by using
mount -t vfat /dev/sdb4 /<mount-point-1>
I can mount the memory-brick using
mount -t vfat /dev/sdc1 /<mount-point-2>
However if, one day, I don't have the zip drive plugged in and start the
machine then the memory-brick will end up at /dev/sda, all those
carefully calculated mount-points in /etc/fstab are wrong and chaos
reigns. This is where scsidev comes in.
I create a file /etc/scsi.alias with the following contents:
manufacturer=_NEC, devtype=cdrom, alias=dvdwriter
manufacturer=PLEXTOR, devtype=cdrom, alias=cdwriter
manufacturer=IBM, devtype=disk, partition=1, alias=scsidisk0
manufacturer=IOMEGA, devtype=disk, partition=4, alias=zipdrive
manufacturer=LEXAR, devtype=disk, partition=1, alias=usbdrive
Once I've done this then I simply execute "scsidev -d -f" this creates
the following entries : /dev/scsi/dvdwriter /dev/scsi/cdwriter
/dev/scsi/scsidisk0 /dev/scsi/zipdrive and /dev/scsi/usbdrive
I can now issue
mount -t vfat /dev/scsi/usbdrive /<mount-point-1>
These entries can safely be put in /etc/fstab because the /dev/scsi
entries are created when scsidev is executed and don't change if devices
are or are not actually attached. When you need to attach a device that
wasn't present when scsidev was run then you can attach it, run scsidev
and continue as normal. I have an init script which runs when the
machine is booted which I can then re-run as required. For devices which
are removed and then re-inserted operation continues as normal, it is
not necessary to re-run scsidev in this case.
Hope this helps.
--
Andy Ruddock
------------
Senior Software Developer (andy_r...@hotmail.com)