Re: Something never understood: see USB storage in CLI & mc
Some of what we are explaining has to do with how one
sets up their /etc/fstab configuration but usb drives generate a
predictable set of messages in /var/log/syslog. The particular
details change based upon what has already been installed in
one's file system, but if things are working right, the messages
identify the new device being plugged in as storage and also
identify what new node in the file system the new drive has such
as /dev/sdg or /dev/sdb. At that point, you can use fdisk -l
/dev/sdb or /dev/sdg to identify the partitions which will look
like /dev/sdb1 or /dev/sdh5, depending on how the drive is
formatted.
If this is a temporary situation, such as wanting to read
a drive somebody handed to you, you can mount the desired
partition as mount /dev/stb2 /mnt and that will work as long as
it is a file system that your Linux device knows about.
When one is through working with the drive, umount /mnt
is sufficient to safely remove the mounting but make sure you got
a new shell prompt before you pull the plug because the OS may
not have finished updating the inode list on the drive if you
wrote a huge file to it or removed a huge file from it. I have
actually done that while in a hurry and the results are ugly.
Some other things you can read about are programs such as
blkid which gives you a unique ID called a UUID for any disk
drive. You can use this unique string in your /etc/fstab file to
cause your system to automatically mount the drive every time it
is plugged in or at least let you give a command like mount /arch
and it will know what to do if the drive waiting to be mounted
has that UUID string.
I have two thumb drives which contain archives of stuff I do not
want to lose. Either one mounts to /arch but I must uncomment the
correct line to make it work. Here's what that looks like.
#UUID="238405a2-9d98-4808-ae2c-07905c318761" /arch ext4 ro,user,noauto 0 0
UUID="85e06ca5-abb4-4d28-95ac-bc08441d37ce" /arch ext4 ro,user,noauto 0 0
The line without the # works if I plug in that drive and type
mount /arch.
If I need to use the other /arch drive, I must comment
out the bottom line and uncomment the top line and that other drive will then
work.
The noauto directive tells the system to hold off on
mounting in case maybe I didn't really want to mount it just yet.
Once you mount a drive, even if you did nothing else, you must
use umount to remove it or one may be very unhappy later.
Sorry if this is a bit long, but it is a very useful
system which makes life less frustrating if one learns the
basics.
Martin
Ron Leach <ronleach@tesco.net> writes:
> On 18/05/2016 10:40, Felix Miata wrote:
>
> Ron Leach composed on 2016-05-18 10:30 (UTC+0100):
>
> I'd be grateful for any advice on where to find the physical
> device to
> use in a mount command.
>
>
> # lsscsi
> ...
> [9:0:0:0] disk FLASH Drive SM_USB20 1100 /dev/sdg...
>
> # blkid /dev/sdg
>
> # mount -t auto (or the type reported by blkid)
>
>
>
> Felix, thank you for the (very) prompt reply. It didn't quite work, for
> me.
>
>
> wheezy2:/home/ron# lsscsi
> bash: lsscsi: command not found
> wheezy2:/home/ron# lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 004: ID 0781:a7c1 SanDisk Corp.
>
>
> As you see, lsscsi does not seem to exist on his machine. One alternative
> I've used in other usb contexts, lsusb, sees the device, but without a
> /dev
> /sd...
>
>
>
> Another reply suggested using dmesg output, which I'll try now - and reply
> to in a moment.
>
>
> Regards, Ron
>
>
Reply to: