 | |
Issue with mounting USB-2 flash-drives on Red Hat 6
comp.databases.pick comp.databases.pick
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Issue with mounting USB-2 flash-drives on Red Hat 6 -
06-15-2010
, 03:41 PM
#2
| |||
| |||
|
#3
| |||
| |||
|
|
Steven this doesn't respond to the USB issue but it does respond to the reason why you're using USB: I recently wrote a utility that transparently does account-saves through FTP to a remote server, and it will also transparently account-restore from a remote FTP server. The idea here is that the backup is immediately off-site as soon as it's complete - not still on a USB, tape, DVD, or in a disk pseudo-file which may suffer the same fate as an ill-fated server. It also does selective t-dump/t-loads to/from remote systems. I'll email you off-list. Regards, T |
solution as well with the USB devices, for peace of mind of my customer.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk
#4
| |||
| |||
|
#5
| |||
| |||
|
|
I assume that the people with these systems probably use PC workstations? We have used USB backup for our users for years .... we simply plug the USB drive into a WINDOWS PC, they copy backup from a share on the Linux machine (with a .BAT on the desktop more often than not) and the job is done in a minute or 2 ... EASY AS!! |
providing a removable USB flash-drive backup, and also keeping store
personnel out of the having to take action loop.
There's some hurdles to jump through but it looks like a small kernel
upgrade from 2.2.14 to 2.2.18/2.2.19 will do it. So I'll hack that
today and see if everything works after I recompile the kernel (the
USB is mountable and D3 doesn't hiccup). If so that's what I'll go
with as the stopgap until we get them migrated to either the current
D3 linux or to QM.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk
#6
| |||
| |||
|
|
I assume that the people with these systems probably use PC workstations? We have used USB backup for our users for years .... we simply plug the USB drive into a WINDOWS PC, they copy backup from a share on the Linux machine (with a .BAT on the desktop more often than not) and the job is done in a minute or 2 ... EASY AS!! |
A FETCHBU.BAT to pull the /u/pickbu.bz2 file to c:\pickbu.bz2 might be
@echo off
title fetchbu
@rem that puts a title on this dos window frame on your desktop
net use j: \\RedhatBox\readonly
attrib -r -s c:\pickbu.bz2
copy /b /y j:\u\pickbu.bz2 c:\pickbu.bz2
net use /delete j:
You can omit the line @echo off if you want to see each command on screen as
it runs.
The title line adjusts the windows title bar of the command prompt window this
batch file is running in...
Assumes your linux box has a windows box 'name' of RedhatBox in windows network
neighborhood alias 'computers near me' list, and that linux samba is running and
configured to allow guest access to a share called 'readonly' that is offering linux /
directory.
The attrib line and the /y of COPY are efforts to preclude any interruptions from
windows to ask you 'are you sure?' or 'readonly file exists already, access denied' or
whatever.
I chose to use windows drive letter J: for the mapped network drive here.
If you instead want to push the file from linux over onto a windows disk share,
//winguy/pub as filename pickbu.bz2 there, and that share lets windows
userid george with windows password 'please' have write access, then you
could do the command {smbclient is provided as part of samba client rpm}
smbclient -U george //winguy/pub please \
-c 'put /u/pickbu.bz2 pickbu.bz2'
You can verify your samba is playing happily with the local windows print and file
sharing members by doing smbclient -L localhost | more
and noting it lists the other winboxes on the lan. Sadly modern windows security is
often too advanced or adjusted too tightly for samba to work with, esp. post-win2k,
at least not without some major samba guru consultant help.
Our nightly 'file-save (xy in batch mode' program saves to pickbu1 on monday, etc
but also does bzip2 -k on it and renames the pickbu1.bz2 as just pickbu.bz2
--we get like 3.5 or 4.0 -- to -- one compression rates typically. Your older
redhat won't offer
bzip2 / bunzip2, but you should at least use compress / uncompress, ought to get you at
least 3:1 ...
That reduction is very welcomed if you're waiting on the batch file to suck the file into
windows on
demand, instead of pushing it from linux to a windows share during overnight processing.
Your overnight job should also check the pick return code from the SAVE it does, and
alert staff
if it isn't good status. Maybe enhance the log-message of d3 to reflect that status
code, too...
I'm deeply skeptical that a system bought new just 2 years ago will support redhat 6.x
since our
vendors had by then been offering us boxes that do not support windows98 installs, for
example,
and istr that was the vintage of windows when redhat 6.x releases came out. Also, if
these are refurbed
older motherboards, you might find the bios won't support ide hard disks over 2.1 gigs,
or 32 gigs,
for example, or enough ram to support rhel 4 or 5, so get a proof-of-concept site loaded
up before
commiting to upgrade all your sites to modern redhat.
Sorry dunno what modules were around back at redhat6.x offhand, but it seems at least as
far back as
redhat 9 the kernel module for using usb flash drives ('thumb drives') was
usb-storage
{googled to linux usb flash drive , chose the response on
www.ExtremeTech.com}
and is still usb-storage even today, though in modern linux you'd let the linux autofs
service run
and it would detect the drive when you plug it in, and mount it as /media/foo
where model of drive is foo.
usb-storage provides a simulated scsi drive { see dmesg | more } for you to fdisk/dd /
mount / whatever.
If you are using old refurbed motherboards, you might find the usb slots are hardware
version 1.1 instead of
modern 2.0 -- your drive may not work, or may be limited to 32mb. I don't know of any
command in
linux that will confirm / deny your usb hardware version, sorry.
Test all the usb slots, as on many computers one or more of the usb slots are different
than the others --
maybe you should tape shut a single such retarded usb slot of your server before you ship
it to client...
You can either treat that flash drive as an ide drive with partition table, partions etc
or treat it as
a biiiig floppy if doing a dd copy of a bootable iso file. Ymmv on whether your bios
will even consider
booting off it as a big floppy, though.
Winboxes can also fdisk/format the usb flashdrive, and you can rename the volume label
that linux reads
during automounting, to make it use an alternate /media/foo3 folder for the mount of
that particular specimen.
When done with it you could issue the umount /media/foo before pulling it out of
usb port.
Instead of using ftp to push a copy of pickbu off of linux, consider using scp {cp
command
but using the nice encrypted ssh protocol} if you can arrange a partner ssh server at the
other
end of the link. Erm, in the windows world, the ssh client suite putty calls this
pscp.exe,
if you're out in the field and want to suck a file down from the linux server. << did
redhat 6.x
even have ssh yet? I forget >> If no linux server available out in the field to accept
your scp
from the local d3/linux box, consider loading a winbox up with cygwin and include the
optional
software parts that provide an ssh server on that winbox. Note cygwin can be a pesky
nuisance
to administer, though it is a free download.
#7
| |||||
| |||||
|
|
"Ross Ferris" wrote I assume that the people with these systems probably use PC workstations? We have used USB backup for our users for years .... we simply plug the USB drive into a WINDOWS PC, they copy backup from a share on the Linux machine (with a .BAT on the desktop more often than not) and the job is done in a minute or 2 ... EASY AS!! A FETCHBU.BAT to pull the /u/pickbu.bz2 file to c:\pickbu.bz2 might be @echo off title fetchbu @rem that puts a title on this dos window frame on your desktop net use j: \\RedhatBox\readonly attrib -r -s c:\pickbu.bz2 copy /b /y j:\u\pickbu.bz2 c:\pickbu.bz2 net use /delete j: You can omit the line @echo off if you want to see each command on screen as it runs. The title line adjusts the windows title bar of the command prompt window this batch file is running in... Assumes your linux box has a windows box 'name' of RedhatBox in windows network neighborhood alias 'computers near me' list, and that linux samba is running and configured to allow guest access to a share called 'readonly' that is offering linux / directory. The attrib line and the /y of COPY are efforts to preclude any interruptions from windows to ask you 'are you sure?' or 'readonly file exists already, access denied' or whatever. I chose to use windows drive letter J: for the mapped network drive here. If you instead want to push the file from linux over onto a windows disk share, //winguy/pub as filename pickbu.bz2 there, and that share lets windows userid george with windows password 'please' have write access, then you could do the command {smbclient is provided as part of samba client rpm} smbclient -U george //winguy/pub please \ -c 'put /u/pickbu.bz2 pickbu.bz2' You can verify your samba is playing happily with the local windows print and file sharing members by doing smbclient -L localhost | more and noting it lists the other winboxes on the lan. Sadly modern windows security is often too advanced or adjusted too tightly for samba to work with, esp. post-win2k, at least not without some major samba guru consultant help. Our nightly 'file-save (xy in batch mode' program saves to pickbu1 on monday, etc but also does bzip2 -k on it and renames the pickbu1.bz2 as just pickbu.bz2 --we get like 3.5 or 4.0 -- to -- one compression rates typically. Your older redhat won't offer bzip2 / bunzip2, but you should at least use compress / uncompress, ought to get you at least 3:1 ... That reduction is very welcomed if you're waiting on the batch file to suck the file into windows on demand, instead of pushing it from linux to a windows share during overnight processing. Your overnight job should also check the pick return code from the SAVE it does, and alert staff if it isn't good status. Maybe enhance the log-message of d3 to reflect that status code, too... I'm deeply skeptical that a system bought new just 2 years ago will support redhat 6.x since our vendors had by then been offering us boxes that do not support windows98 installs, for example, and istr that was the vintage of windows when redhat 6.x releases came out. Also, if these are refurbed older motherboards, you might find the bios won't support ide hard disks over 2.1 gigs, or 32 gigs, for example, or enough ram to support rhel 4 or 5, so get a proof-of-concept site loaded up before commiting to upgrade all your sites to modern redhat. |
couple of other models that escape me. But all purchased within the
last 2 years. The exception being one Celeron-processor Compaq that is
almost 3 years old. It comes due for scheduled replacement in August.
Those two model numbers happen to be on my workbench right now which
is now I can report what they are. 2gb DDR-2 with 512mb assigned to
D3. Either Athlon LE1640, AMD 64 3800, AMD 64 4800, 5000, 5200 or 5600
processors. We put a dumb Realtek RTL8192 LAN card in for standardized
convenience (disabling the on board LAN) and add a Lava Industries PCI
slot parallel port card for the Okidata printer. All the systems are
running Red Hat 6.1 or 6.2 and D3 Linux 7.2.0. I installed them
myself. Other than this recent A/C failure-induced system crash
nothing ever goes wrong, they run fast, the 10 year old dbms serves
their data reliably, etc.
Quote:
|
Sorry dunno what modules were around back at redhat6.x offhand, but it seems at least as far back as redhat 9 the kernel module for using usb flash drives ('thumb drives') was usb-storage {googled to linux usb flash drive , chose the response on www.ExtremeTech.com} and is still usb-storage even today, though in modern linux you'd let the linux autofs service run and it would detect the drive when you plug it in, and mount it as /media/foo where model of drive is foo. usb-storage provides a simulated scsi drive { see dmesg | more } for you to fdisk/dd / mount / whatever. |
place are running 2.2.14. The USB flash-drives are seen, can be
mounted writable and the psuedo-tapes can be copied onto the
flash-drives. Looking back it seems the big leap forward in terms of
ease of dealing with USB in the linux kernel came code at the 2.2.18
kernel. This is what was in the 2.4.x series kernels. So I'm going try
one of my testbed machines with a kernel upgrade and see how it goes.
Quote:
|
If you are using old refurbed motherboards, you might find the usb slots are hardware version 1.1 instead of modern 2.0 -- your drive may not work, or may be limited to 32mb. I don't know of any command in linux that will confirm / deny your usb hardware version, sorry. |
rolled out vanilla by Compaq into Fry's etc. All front and back USB
slots are 2.0 and accessible (writable) using a 2.4.x kernel.
Quote:
|
Test all the usb slots, as on many computers one or more of the usb slots are different than the others -- maybe you should tape shut a single such retarded usb slot of your server before you ship it to client... You can either treat that flash drive as an ide drive with partition table, partions etc or treat it as a biiiig floppy if doing a dd copy of a bootable iso file. Ymmv on whether your bios will even consider booting off it as a big floppy, though. Winboxes can also fdisk/format the usb flashdrive, and you can rename the volume label that linux reads during automounting, to make it use an alternate /media/foo3 folder for the mount of that particular specimen. When done with it you could issue the umount /media/foo before pulling it out of usb port. |
as an idle disk drive for now to be mounted at boot time right befor
D3 stars up; unmounted/remounted when swapped-out each week. Though
that might change once we see it in production use.
Quote:
|
Instead of using ftp to push a copy of pickbu off of linux, consider using scp {cp command but using the nice encrypted ssh protocol} if you can arrange a partner ssh server at the other end of the link. Erm, in the windows world, the ssh client suite putty calls this pscp.exe, if you're out in the field and want to suck a file down from the linux server.<< did redhat 6.x even have ssh yet? I forget>> If no linux server available out in the field to accept your scp from the local d3/linux box, consider loading a winbox up with cygwin and include the optional software parts that provide an ssh server on that winbox. Note cygwin can be a pesky nuisance to administer, though it is a free download. |
instead of FTP (disabled). It's just a question of automating it.
Wasn't an issue until now. But now it is. And yes, ssh was all there
in 6.x RH. We use it instead of telnet (disabled) for external
accessing of the in-store servers.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk
#8
| |||
| |||
|
|
On 06/16/2010 10:36 AM, Frank Winans wrote: "Ross Ferris" wrote I assume that the people with these systems probably use PC workstations? We have used USB backup for our users for years .... we simply plug the USB drive into a WINDOWS PC, they copy backup from a share on the Linux machine (with a .BAT on the desktop more often than not) and the job is done in a minute or 2 ... EASY AS!! A FETCHBU.BAT to pull the /u/pickbu.bz2 * file to c:\pickbu.bz2 might be @echo off title fetchbu @rem that puts a title on this dos window frame on your desktop net * use * j: \\RedhatBox\readonly attrib * *-r * *-s * *c:\pickbu.bz2 copy * /b /y j:\u\pickbu.bz2 * c:\pickbu.bz2 net * use * */delete j: You can omit *the *line * *@echo * off * * *if you wantto see each command on screen as it runs. The *title * line * * adjusts the windows title bar of the command prompt window this batch file is running in... Assumes your linux box has a windows box 'name' of RedhatBox in windows network neighborhood alias 'computers near me' list, and that linux samba is running and configured to allow guest access to a share called 'readonly' *that is offering linux / directory. The attrib * line * * and the */y *of COPY *are efforts to preclude any interruptions from windows to ask you 'are you sure?' or *'readonly file exists already, access denied' or whatever. I chose to use windows drive letter * J: * * for the mapped network drive here. If you instead want to push the file from linux over onto a windows disk share, //winguy/pub * * * *as filename pickbu.bz2 there, * and that share lets windows userid *george with windows password 'please' * * have write access, then you could do the command {smbclient is provided as part of samba *client * rpm} smbclient -U *george * * *//winguy/pub * please * * * \-c * 'put /u/pickbu.bz2 * pickbu.bz2' You can verify your samba is playing happily with the local windows print and file sharing members by doing * * *smbclient *-L *localhost * *| *more and noting it lists the other winboxes on the lan. *Sadly modern windows security is often too advanced or adjusted too tightly for samba to work with, esp. post-win2k, at least not without some major samba guru consultant help. Our nightly 'file-save (xy * in batch mode' *program *saves *to pickbu1 on monday, etc but also does bzip2 *-k * *on it and renames the pickbu1.bz2 *as just *pickbu.bz2 --we get like 3.5 or 4.0 * *-- to -- *one * compression rates typically. *Your older redhat won't offer bzip2 */ bunzip2, * but you should at least use compress / uncompress, ought to get you at least 3:1 ... That reduction is very welcomed if you're waiting on the batch file to suck the file into windows on demand, instead of pushing it from linux to a windows share during overnight processing. Your overnight job should also check the pick return code from *the SAVE * it does, and alert staff if it isn't good status. *Maybe enhance the log-message * *of * d3 to reflect that status code, too... I'm deeply skeptical that a system bought new just 2 years ago will support redhat 6.x since our vendors had by then *been offering us boxes that do not support windows98 installs, for example, and istr that was the vintage of windows when redhat 6.x releases came out. Also, if these are refurbed older motherboards, you might find the bios won't support ide hard disks over 2.1 gigs, or 32 gigs, for example, *or enough ram to support rhel 4 or 5, so get a proof-of-concept site loaded up before commiting to upgrade all your sites to modern redhat. The boxes are all off-the-shelf Compaqs. Models SR5605F, SR5615F and a couple of other models that escape me. But all purchased within the last 2 years. The exception being one Celeron-processor Compaq that is almost 3 years old. It comes due for scheduled replacement in August. Those two model numbers happen to be on my workbench right now which is now I can report what they are. 2gb DDR-2 with 512mb assigned to D3. Either Athlon LE1640, AMD 64 3800, AMD 64 4800, 5000, 5200 or 5600 processors. We put a dumb Realtek RTL8192 LAN card in for standardized convenience (disabling the on board LAN) and add a Lava Industries PCI slot parallel port card for the Okidata printer. All the systems are running Red Hat 6.1 or 6.2 and D3 Linux 7.2.0. I installed them myself. Other than this recent A/C failure-induced system crash nothing ever goes wrong, they run fast, the 10 year old dbms serves their data reliably, etc. Sorry dunno what modules were around back at redhat6.x offhand, but it seems at least as far back as redhat 9 the kernel module for using usb flash drives ('thumb drives') was usb-storage {googled to linux * usb * flash * drive * , *chose the response onwww.ExtremeTech.com} and is still usb-storage *even today, though in modern linux you'd let the linux * autofs service run and it would detect the drive when you plug it in, and mount it as */media/foo where model of drive is foo. usb-storage provides a simulated scsi drive { see dmesg *| more } *for you to fdisk/dd */ mount / whatever. I tested an 8 year old 2.4.x kernel last night. The servers I have in place are running 2.2.14. The USB flash-drives are seen, can be mounted writable and the psuedo-tapes can be copied onto the flash-drives. Looking back it seems the big leap forward in terms of ease of dealing with USB in the linux kernel came code at the 2.2.18 kernel. This is what was in the 2.4.x series kernels. So I'm going try one of my testbed machines with a kernel upgrade and see how it goes. If you are using old refurbed motherboards, you might find the usb slots are hardware version 1.1 instead of modern 2.0 -- your drive may not work, or may be limited to 32mb. * I don't know of any command in linux that will confirm / deny your usb hardware version, sorry. No refurbished mobos. Just the ones that come in the machines that are rolled out vanilla by Compaq into Fry's etc. All front and back USB slots are 2.0 and accessible (writable) using a 2.4.x kernel. Test all the usb slots, as on many computers one or more of the usb slots are different than the others -- maybe you should tape shut a single such retarded usb slot of your *server before you ship it to client... You can either treat that flash drive as an ide drive with partition table, partions etc or *treat it as a biiiig floppy if doing a dd copy of a bootable *iso * file. *Ymmv on whether your bios will even consider booting off it as a big floppy, though. Winboxes can also fdisk/format the usb flashdrive, and you can rename the volume label that *linux reads during automounting, to make it use an alternate /media/foo3 * folder for the mount of that particular specimen. When done with it you could issue the umount /media/foo * * before pulling it out of usb port. Thanks for the food for thought. We're going to treat the flash-drives as an idle disk drive for now to be mounted at boot time right befor D3 stars up; unmounted/remounted when swapped-out each week. Though that might change once we see it in production use. Instead of using ftp to push a copy of pickbu off of linux, consider using *scp * {cp command but using the nice encrypted ssh protocol} if you can arrange a partner ssh server at the other end of the link. * Erm, in *the windows world, the *ssh client *suite putty calls this pscp.exe, if you're out in the field and want to suck a file down from the linux server.<< *did redhat 6.x even have ssh yet? *I forget>> * *If no linux server available out in the field to accept your scp from the local d3/linux box, consider loading a winbox up with * cygwin and include the optional software parts that provide an ssh server on that winbox. *Note cygwin can be a pesky nuisance to administer, though it is a free download. Thanks. Lots of good stuff there. We already use SCP for moving data instead of FTP (disabled). It's just a question of automating it. Wasn't an issue until now. But now it is. And yes, ssh was all there in 6.x RH. We use it instead of telnet (disabled) for external accessing of the in-store servers. -- Cheers, SDM -- a 21st Century Schizoid Man Systems Theory project website:http://systemstheory.net find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby free MP3s of Systems Theory, Mike Dickson & Greg Amov music athttp://mikedickson.org.uk- Hide quoted text - - Show quoted text - |
they last longer - right?
#9
| |||
| |||
|
|
On 06/16/2010 10:36 AM, Frank Winans wrote: If you are using old refurbed motherboards, you might find the usb slots are hardware version 1.1 instead of modern 2.0 -- your drive may not work, or may be limited to 32mb. I don't know of any command in linux that will confirm / deny your usb hardware version, sorry. No refurbished mobos. Just the ones that come in the machines that are rolled out vanilla by Compaq into Fry's etc. All front and back USB slots are 2.0 and accessible (writable) using a 2.4.x kernel. |
it is gnome-volume-manager {according to man gnome-mount }
which relies on haldaemon aka hald service, and that in turn relies on
messagebus aka dbus-daemon services of /etc/rc5.d/S*
Gnome can be configured to not use /media/foo based on volume label of the
usb 'disk' partition, but I leave that as an exercise for the reader.
Oh, and I neglected to mention linux will cause undue wear and tear on your
usb flash drive if you do not
mount
it with the
noatime
option -- linux writes to update the access time {ie, when it was read from last}
of files and folders, which would tend to happen overnight when the locate
database gets refreshed by cron {anacron?}, and could be done many many times
to the top level directories of a usb drive with lots of files under 'em.
I wrote you can find what scsi drive letter /dev/sd* your usb device was
assigned by usb-storage kernel module by pawing through dmesg output -- you can
also see similar lines in /var/log/messages; but it might be easier to get it from
lsscsi
or lsscsi -v
I see lsusb -v shows flash drive serial number -- I guess I could use
3 buck units from the thrift store in D/FW area as dongles for d3/linux clients
on modern mboards (evil smirk...)
Viewing the volume label without borrowing a windows box;
if you already know your usb flash drive is associated (this time) with /dev/sdc1
you can view the volume label contents with
echo 'drive f: file="/dev/sdb1"' > ~/.mtoolrc
mlabel -s f: # shows current vfat partition label
rm ~/.mtoolrc
Lastly, I found you _can_ see the usb hardware version of each slot with
lsusb -v | grep B # grep matches "Bus" and "bcdUSB"
Ah, the things we go through to sneakernet an honest file-save off-site...
#10
| |||
| |||
|
|
"sdavmor" wrote On 06/16/2010 10:36 AM, Frank Winans wrote: If you are using old refurbed motherboards, you might find the usb slots are hardware version 1.1 instead of modern 2.0 -- your drive may not work, or may be limited to 32mb. I don't know of any command in linux that will confirm / deny your usb hardware version, sorry. No refurbished mobos. Just the ones that come in the machines that are rolled out vanilla by Compaq into Fry's etc. All front and back USB slots are 2.0 and accessible (writable) using a 2.4.x kernel. I gave you a bum steer -- it is not autofs that mounts a usb drive as /media/foo it is gnome-volume-manager {according to man gnome-mount } which relies on haldaemon aka hald service, and that in turn relies on messagebus aka dbus-daemon services of /etc/rc5.d/S* Gnome can be configured to not use /media/foo based on volume label of the usb 'disk' partition, but I leave that as an exercise for the reader. Oh, and I neglected to mention linux will cause undue wear and tear on your usb flash drive if you do not mount it with the noatime option -- linux writes to update the access time {ie, when it was read from last} of files and folders, which would tend to happen overnight when the locate database gets refreshed by cron {anacron?}, and could be done many many times to the top level directories of a usb drive with lots of files under 'em. I wrote you can find what scsi drive letter /dev/sd* your usb device was assigned by usb-storage kernel module by pawing through dmesg output -- you can also see similar lines in /var/log/messages; but it might be easier to get it from lsscsi or lsscsi -v I see lsusb -v shows flash drive serial number -- I guess I could use 3 buck units from the thrift store in D/FW area as dongles for d3/linux clients on modern mboards (evil smirk...) |
Quote:
|
Viewing the volume label without borrowing a windows box; if you already know your usb flash drive is associated (this time) with /dev/sdc1 you can view the volume label contents with echo 'drive f: file="/dev/sdb1"'> ~/.mtoolrc mlabel -s f: # shows current vfat partition label rm ~/.mtoolrc Lastly, I found you _can_ see the usb hardware version of each slot with lsusb -v | grep B # grep matches "Bus" and "bcdUSB" Ah, the things we go through to sneakernet an honest file-save off-site... |
seen as a SCSI device. The USB file system is getting automounted. So
I'm just mounting the drive where I want it to be for writing at the
end of /etc/rc.d/rc.local right before offering to start D3 and away
we go. I did notice *nix takes a long-time to unmount when doing a
halt or reboot, but other than that it seems to be working fine.
Next up pushing a copy onto the store manager's Windows PC. I might
get around to that this weekend. Right now it's being pulled each
morning using WinSCP.
--
Cheers, SDM -- a 21st Century Schizoid Man
Systems Theory project website: http://systemstheory.net
find us on MySpace, GarageBand, Reverb Nation, Last FM, CDBaby
free MP3s of Systems Theory, Mike Dickson & Greg Amov music at
http://mikedickson.org.uk
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.