12:19 a.m.
As part of getting my desktop working again, it'd help to be able to
mount and unmount my flash drive from a command line, but I couldn't
figure out how to work out just which device name to use. A question on
fedoraforum had an answer in just a few hours, and I'm almost ashamed to
admit that I didn't think of it myself. As root,
fdisk -l
will tell you exactly what you need. D'oh!
6:56 p.m.
On Thu, 2011-12-08 at 09:27 -0600, Aaron Konstam wrote:
> And thus the drive is /dev/sdf, with the data partition
/dev/sdf1.
>
> You may need to scroll back a bit if a lot of stuff is going on in
> dmesg.
>
Great, but could the displaying of the information be made more obscure?
----
dmesg | grep usb
Craig
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
7:28 a.m.
On 12/07/2011 07:19 AM, Joe Zeff wrote:
As part of getting my desktop working again, it'd help to be able
to
mount and unmount my flash drive from a command line, but I couldn't
figure out how to work out just which device name to use. A question on
fedoraforum had an answer in just a few hours, and I'm almost ashamed to
admit that I didn't think of it myself. As root,
fdisk -l
will tell you exactly what you need. D'oh!
cat /proc/partitions
The flash drive is usually the last one, it usually has a single
partition and you will probably recognize its size.
--
Roberto Ragusa mail at robertoragusa.it
5:21 a.m.
On 12/09/2011 01:54 AM, jdow wrote:
On 2011/12/08 16:56, Craig White wrote:
> On Thu, 2011-12-08 at 09:27 -0600, Aaron Konstam wrote:
>
>>> And thus the drive is /dev/sdf, with the data partition /dev/sdf1.
>>>
>>> You may need to scroll back a bit if a lot of stuff is going on in
>>> dmesg.
>>>
>> Great, but could the displaying of the information be made more obscure?
> ----
> dmesg | grep usb
>
> Craig
After the kernel ring buffer has wrapped?
Try this:
grep usb /var/log/dmesg
Then you have to decode it. And, of course, the drive on which "grep" lives
AND the drive on which /var/log/dmesg lives, if different, will be spun up.
The /var/log/dmesg file is a snapshot taken during booting (when
rc.sysinit runs) on systems using traditional SysV init (inc. upstart)
so if a device was not present during boot (or had its drivers loaded
after the snapshot was taken) it will not appear here.
It's not updated later and does not seem to be created on systems using
systemd.
Either look in /var/log/messages or specify log_buf_len=n[KMG] on the
kernel command line to set a lager ring buffer (modern systems with
plenty of RAM can comfortably increase this to 10s of MB rather than the
128k default).
Regards,
Bryn.
3:37 p.m.
On 08Dec2011 09:27, Aaron Konstam <akonstam(a)sbcglobal.net> wrote:
| On Thu, 2011-12-08 at 10:34 +1100, Cameron Simpson wrote:
| > On 07Dec2011 10:44, Joe Zeff <joe(a)zeff.us> wrote:
| > | On 12/07/2011 06:18 AM, Robert Nichols wrote:
| > | > An issue with both the fdisk and blkid solutions is that they will spin
| > | > up every sleeping drive on your system. Looking at the output from dmesg
| > | > won't do that.
| > |
| > | I tried dmesg first but never found anything useful in it.
| >
| > There should be a sequence like the below when you plug in a USB drive:
[...]
| > And thus the drive is /dev/sdf, with the data partition /dev/sdf1.
| >
| > You may need to scroll back a bit if a lot of stuff is going on in
| > dmesg.
| >
| Great, but could the displaying of the information be made more obscure?
Sure, but you'd need to recompile your kernel. (If you do, maybe turn on
the timestamps option, off by default - it drives me mad not knowing
_when_ a message landed in dmesg.)
I'm sure there's some cool udev event watcher widget somewhere that will
pop up a growl-like alert for you.
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
The wicked man shall be punished for his own wickedness, for he shall never
find inner peace and will seldom be given the really good tables at tearooms.
- Gardner
9:27 a.m.
On Thu, 2011-12-08 at 10:34 +1100, Cameron Simpson wrote:
On 07Dec2011 10:44, Joe Zeff <joe(a)zeff.us> wrote:
| On 12/07/2011 06:18 AM, Robert Nichols wrote:
| > An issue with both the fdisk and blkid solutions is that they will spin
| > up every sleeping drive on your system. Looking at the output from dmesg
| > won't do that.
|
| I tried dmesg first but never found anything useful in it.
There should be a sequence like the below when you plug in a USB drive:
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
scsi 9:0:0:0: Direct-Access WD My Book 1110 1030 PQ: 0
ANSI: 4
sd 9:0:0:0: Attached scsi generic sg7 type 0
scsi 9:0:0:1: CD-ROM WD Virtual CD 1110 1030 PQ: 0
ANSI: 4
sd 9:0:0:0: [sdf] 1952151552 512-byte hardware sectors: (999 GB/930 GiB)
sd 9:0:0:0: [sdf] Write Protect is off
sd 9:0:0:0: [sdf] Mode Sense: 23 00 10 00
sd 9:0:0:0: [sdf] Assuming drive cache: write through
sr0: scsi3-mmc drive: 51x/51x caddy
sr 9:0:0:1: Attached scsi CD-ROM sr0
sr 9:0:0:1: Attached scsi generic sg8 type 5
scsi 9:0:0:2: Enclosure WD SES Device 1030 PQ: 0
ANSI: 4
scsi 9:0:0:2: Attached scsi generic sg9 type 13
sd 9:0:0:0: [sdf] Assuming drive cache: write through
sdf: sdf1
usb-storage: device scan complete
sd 9:0:0:0: [sdf] Attached SCSI disk
And thus the drive is /dev/sdf, with the data partition /dev/sdf1.
You may need to scroll back a bit if a lot of stuff is going on in
dmesg.
Great, but could the displaying of the information be made more obscure?
--
=======================================================================
The luck that is ordained for you will be coveted by others.
=======================================================================
Aaron Konstam telephone: (210) 656-0355 e-mail: akonstam(a)sbcglobal.net
7:16 a.m.
On 12/08/2011 04:17 AM, Bryn M. Reeves wrote:
On 12/07/2011 02:18 PM, Robert Nichols wrote:
> An issue with both the fdisk and blkid solutions is that they will spin
> up every sleeping drive on your system. Looking at the output from dmesg
> won't do that.
>
That's only true of fdisk -l (with no other arguments). The blkid
command operates out of a cache so will only spin up drives if run with
-p (low-level probe). This also allows users without read access to a
block device to retrieve label, file system type& UUIDs.
When I run blkid (with no arguments) as root it waits while a standby
drive spins up. If blkid is run by a non-root user there is indeed
no spin up.
util-linux-ng-2.16.2-9
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
4:17 a.m.
On 12/07/2011 02:18 PM, Robert Nichols wrote:
On 12/07/2011 12:19 AM, Joe Zeff wrote:
> As part of getting my desktop working again, it'd help to be able to
> mount and unmount my flash drive from a command line, but I couldn't
> figure out how to work out just which device name to use. A question on
> fedoraforum had an answer in just a few hours, and I'm almost ashamed to
> admit that I didn't think of it myself. As root,
>
> fdisk -l
>
> will tell you exactly what you need. D'oh!
An issue with both the fdisk and blkid solutions is that they will spin
up every sleeping drive on your system. Looking at the output from dmesg
won't do that.
That's only true of fdisk -l (with no other arguments). The blkid
command operates out of a cache so will only spin up drives if run with
-p (low-level probe). This also allows users without read access to a
block device to retrieve label, file system type & UUIDs.
Regards,
Bryn.
5:34 p.m.
On 07Dec2011 10:44, Joe Zeff <joe(a)zeff.us> wrote:
| On 12/07/2011 06:18 AM, Robert Nichols wrote:
| > An issue with both the fdisk and blkid solutions is that they will spin
| > up every sleeping drive on your system. Looking at the output from dmesg
| > won't do that.
|
| I tried dmesg first but never found anything useful in it.
There should be a sequence like the below when you plug in a USB drive:
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
scsi 9:0:0:0: Direct-Access WD My Book 1110 1030 PQ: 0
ANSI: 4
sd 9:0:0:0: Attached scsi generic sg7 type 0
scsi 9:0:0:1: CD-ROM WD Virtual CD 1110 1030 PQ: 0
ANSI: 4
sd 9:0:0:0: [sdf] 1952151552 512-byte hardware sectors: (999 GB/930 GiB)
sd 9:0:0:0: [sdf] Write Protect is off
sd 9:0:0:0: [sdf] Mode Sense: 23 00 10 00
sd 9:0:0:0: [sdf] Assuming drive cache: write through
sr0: scsi3-mmc drive: 51x/51x caddy
sr 9:0:0:1: Attached scsi CD-ROM sr0
sr 9:0:0:1: Attached scsi generic sg8 type 5
scsi 9:0:0:2: Enclosure WD SES Device 1030 PQ: 0
ANSI: 4
scsi 9:0:0:2: Attached scsi generic sg9 type 13
sd 9:0:0:0: [sdf] Assuming drive cache: write through
sdf: sdf1
usb-storage: device scan complete
sd 9:0:0:0: [sdf] Attached SCSI disk
And thus the drive is /dev/sdf, with the data partition /dev/sdf1.
You may need to scroll back a bit if a lot of stuff is going on in
dmesg.
Cheers,
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
Ride with a llama and you never ride alone.
- Jeff Earls, DoD #0530, <jearls(a)tekig6.pen.tek.com>
8:18 a.m.
On 12/07/2011 12:19 AM, Joe Zeff wrote:
As part of getting my desktop working again, it'd help to be able
to
mount and unmount my flash drive from a command line, but I couldn't
figure out how to work out just which device name to use. A question on
fedoraforum had an answer in just a few hours, and I'm almost ashamed to
admit that I didn't think of it myself. As root,
fdisk -l
will tell you exactly what you need. D'oh!
An issue with both the fdisk and blkid solutions is that they will spin
up every sleeping drive on your system. Looking at the output from dmesg
won't do that.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
2:43 a.m.
On 07/12/11 06:19, Joe Zeff wrote:
As part of getting my desktop working again, it'd help to be able
to
mount and unmount my flash drive from a command line, but I couldn't
figure out how to work out just which device name to use. A question on
fedoraforum had an answer in just a few hours, and I'm almost ashamed to
admit that I didn't think of it myself. As root,
fdisk -l
will tell you exactly what you need. D'oh!
blkid
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of fedoraproject.org
7:54 p.m.
On 2011/12/08 16:56, Craig White wrote:
On Thu, 2011-12-08 at 09:27 -0600, Aaron Konstam wrote:
>> And thus the drive is /dev/sdf, with the data partition /dev/sdf1.
>>
>> You may need to scroll back a bit if a lot of stuff is going on in
>> dmesg.
>>
> Great, but could the displaying of the information be made more obscure?
----
dmesg | grep usb
Craig
After the kernel ring buffer has wrapped?
Try this:
grep usb /var/log/dmesg
Then you have to decode it. And, of course, the drive on which "grep" lives
AND the drive on which /var/log/dmesg lives, if different, will be spun up.
{^_^}
4:11 p.m.
On 07/12/11 14:18, Robert Nichols wrote:
An issue with both the fdisk and blkid solutions is that they will
spin
up every sleeping drive on your system. Looking at the output from dmesg
won't do that.
If you can't boot, a spinning disk may be the least concern.
--
Regards,
Frank Murphy
UTF_8 Encoded
Friend of fedoraproject.org
8:38 a.m.
On 7 December 2011 09:43, Frank Murphy <frankly3d(a)gmail.com> wrote:
On 07/12/11 06:19, Joe Zeff wrote:
> As part of getting my desktop working again, it'd help to be able to
> mount and unmount my flash drive from a command line, but I couldn't
> figure out how to work out just which device name to use. A question on
> fedoraforum had an answer in just a few hours, and I'm almost ashamed to
> admit that I didn't think of it myself. As root,
>
> fdisk -l
>
> will tell you exactly what you need. D'oh!
blkid
--
I like bashmount to do the unmounting:
http://sourceforge.net/projects/bashmount/
Chris
4546
days inactive
4548
days old
15 comments
11 participants
participants (11)
-
Aaron Konstam -
Bryn M. Reeves -
Cameron Simpson -
Chris Rouch -
Craig White -
fedora -
Frank Murphy -
jdow -
Joe Zeff -
Robert Nichols -
Roberto Ragusa