3:17 p.m.
I had an older box which I was using as the site backup machine. A
friend gave me a HP DAT72 drive and I got it up and working on the
Fedora 11 OS. I did backups and tested everything. The tape drive was
accessed as /dev/st4. This box ran Samba and users copied their files to
the this machine. I did backups using:
tar cvf /dev/st4 /home/<user> /home/<user>
Then I decided to upgrade. I swapped out the motherboard and got a 64
bit cpu and upgraded the OS (complete new install). I now have Fedora 15
running on the box.
The tape drive has been visible as /dev/st4 occasionally. And when it is
I have used it to make a small backup and test the restore. But the
/dev/st4 is not always visible and the file /dev/st4 usually disappears
upon reboot. I don't know what I did to make it appear (if anything).
It almost looks like the device changed from /dev/st4 to /dev/st0. Is
that possible?
Some more info:
#ls /dev/st*
/dev/st0 /dev/st0a /dev/st0l /dev/st0m /dev/stderr /dev/stdin
/dev/stdout
#lsscsi
[0:0:0:0] cd/dvd PIONEER DVD-RW DVR-106D 1.08 /dev/sr0
[2:0:0:0] disk ATA WDC WD2500JS-60M 10.0 /dev/sda
[2:0:1:0] disk ATA ST2000DL003-9VT1 CC32 /dev/sdb
[3:0:0:0] disk ATA ST2000DL003-9VT1 CC32 /dev/sdc
[3:0:1:0] disk ATA ST2000DL003-9VT1 CC32 /dev/sdd
[4:0:4:0] tape HP C7438A V312 /dev/st0
# dmesg |grep tape
[ 25.211496] st 4:0:4:0: Attached scsi tape st0
#cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: PIONEER Model: DVD-RW DVR-106D Rev: 1.08
Type: CD-ROM ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: WDC WD2500JS-60M Rev: 10.0
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 01 Lun: 00
Vendor: ATA Model: ST2000DL003-9VT1 Rev: CC32
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi3 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: ST2000DL003-9VT1 Rev: CC32
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi3 Channel: 00 Id: 01 Lun: 00
Vendor: ATA Model: ST2000DL003-9VT1 Rev: CC32
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi4 Channel: 00 Id: 04 Lun: 00
Vendor: HP Model: C7438A Rev: V312
Type: Sequential-Access ANSI SCSI revision: 03
#tar cvf /dev/st4 /root
tar: /dev/st4: Cannot open: No such device or address
tar: Error is not recoverable: exiting now
#tar cvf /dev/st0 /root
<does nothing - just times out after a few minutes with the following
message>
tar: /dev/st0: Cannot open: Input/output error
tar: Error is not recoverable: exiting now
#./rescan-scsi-bus.sh
Host adapter 4 (aic7xxx) found.
./rescan-scsi-bus.sh: line 31: [: too many arguments
Host adapter * (device_info) found.
Scanning hosts 4 * channels 0 for
SCSI target IDs 0 1 2 3 4 5 6 7 , LUNs 0
Scanning for device 4 0 4 0 ...
OLD: Host: scsi4 Channel: 00 Id: 04 Lun: 00
Vendor: HP Model: C7438A Rev: V312
Type: Sequential-Access ANSI SCSI revision: 03
0 new device(s) found. d.txt 0 7 0 ...
0 device(s) removed.
#MAKEDEV /dev/st4
# ls /dev/st*
/dev/st0 /dev/st0l /dev/st4 /dev/st4l /dev/stderr /dev/stdout
/dev/st0a /dev/st0m /dev/st4a /dev/st4m /dev/stdin
#tar cvf /dev/st4 /root
tar: /dev/st4: Cannot open: No such device or address
tar: Error is not recoverable: exiting now
# mt -f /dev/st4 status
/dev/st4: No such device or address
#tar cvf /dev/st0 /root
tar: /dev/st0: Cannot open: Input/output error
tar: Error is not recoverable: exiting now
# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (10000):
IM_REP_EN
#<Reboot>
ls /dev/st*
/dev/st0 /dev/st0a /dev/st0l /dev/st0m /dev/stderr /dev/stdin
/dev/stdout
Does anybody have a clue? Is there some command that I am missing? What
can I do? Thanks for any help!
Bill
4:24 p.m.
Thank-you.
It appears that the st module is loaded.
#lsmod |grep st
<stuff>
st 32080 0
Next, I tried the command write to the tape as /dev/st0. I put a
writeable tape in the drive.
I have a couple of files in /root called yum_list...
tar cvf /dev/st0 /root/yum*
tar: /dev/st0: Cannot open: Input/output error
tar: Error is not recoverable: exiting now
The /dev/tape/by-id/... is a link pointing to /dev/st0
tar cvf /dev/tape/by-id/scsi-1HP_C7438_xxxxx /root/yum*
tar: /dev/tape/by-id/scsi-1HP_C7438A_xxxxx: Cannot open: Input/output error
tar: Error is not recoverable: exiting now
Running rescan-scsi-bus.sh does not help.
Running
mt -f /dev/st0 offline
does not do anything.
mt -f /dev/st0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (10000):
IM_REP_EN
The tape drive still appears in lsscsi
BP
8:09 p.m.
On 10/16/2011 05:47 PM, Cameron Simpson wrote:
I've got a machine at home whose / drive gets renamed depending
on
whether the PCI SCSI RAID stuff is broken or not. Hmm, shall root be on
sdb or sdc today? Maddening when trying to rescue.
Make sure that every partition has a label and use them in fstab. (If
the partition's already mounted by UUID, add a comment to the file
giving the label.) Then, when rescuing, you can unmount your drives and
remount them by using mount -a to get them where you want them.
12:47 a.m.
Once upon a time, Cameron Simpson <cs(a)zip.com.au> said:
On 16Oct2011 20:15, Chris Adams <cmadams(a)hiwaay.net> wrote:
| See /dev/disk/by-{id,path,uuid}.
And does this work _before_ boot, in the root= kernel command line, via
grub.conf?
I'm not sure about the /dev/..., but the UUID does directly (IIRC it is
"UUID=...") with dracut. If you use LVM, dracut handles that as well
(so "root=/dev/mapper/vg_foo-lv_root" works).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
7:43 a.m.
And I would have left IDE style devices as hd, SCSI as sd, SATA as
sa,
and so on, and so forth...
Except you often can't tell the difference. Not all hardware exposes the
connection interface, and then you have things like SATA devices in USB
boxes - so which of your naming is those.
Instead they are named by transport type but how that is presented is up
to the udev userspace.
Alan
7:36 a.m.
On Sun, 2011-10-16 at 20:15 -0500, Chris Adams wrote:
The problem with enumerating devices by HBA/bus/ID/LUN is that
today's
storage is more dynamic. USB ports are "SCSI" (protocol); how do you
number those? IIRC USB ports on a hub are not deterministically
ordered, so a flash card reader on a hub may come before a thumb drive
on one boot and after on the next.
I would have gone down the route of calling USB devices with a usb
device name. So a USB device doesn't become sda and shuffle device
names around for *other* devices.
And I would have left IDE style devices as hd, SCSI as sd, SATA as sa,
and so on, and so forth...
That way when I have a computer with an internal IDE drive, an external
USB, and an external SATA, I could tell them instantly apart from each
other as they would be /dev/hda, /dev/usb1, /dev/sa1. Rather
than /dev/sda, /dev/sdb, and /dev/sdc, where I could guess that the
internal drive was *probably* /dev/sda, but could never guess what
either of the other two were.
--
[tim@localhost ~]$ uname -r
2.6.27.25-78.2.56.fc9.i686
Don't send private replies to my address, the mailbox is ignored. I
read messages from the public lists.
11:15 p.m.
On 16Oct2011 18:09, Joe Zeff <joe(a)zeff.us> wrote:
| On 10/16/2011 05:47 PM, Cameron Simpson wrote:
| > I've got a machine at home whose / drive gets renamed depending on
| > whether the PCI SCSI RAID stuff is broken or not. Hmm, shall root be on
| > sdb or sdc today? Maddening when trying to rescue.
|
| Make sure that every partition has a label and use them in fstab. (If
| the partition's already mounted by UUID, add a comment to the file
| giving the label.) Then, when rescuing, you can unmount your drives and
| remount them by using mount -a to get them where you want them.
Which is no good for the root= kernel command line option.
And the root=LABEL= syntax is apparently a nonstandard kernel patch.
I mount stuff in /etc/fstab with labels - more readable; I tak your
point about using a UUID and a label in the comment.
When I say "rescue", here I'm not meaning "boot off a CDROM and fsck
etc
my OS". I mean "my system doesn't boot because it can't find the root
partition". It is "hunt the /dev/sdX" device, with many minutes of delay
between retries. More annoying that my words can describe.
Cheers,
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
The road less traveled is FASTER !!
- Luc Marcouiller, marcouil(a)ireq.hydro.qc.ca
8:15 p.m.
Once upon a time, Cameron Simpson <cs(a)zip.com.au> said:
I'm all ok with providing sda/hda as discovered, _provided_ one
also has
nice bus/id type names as well. Solaris' bus/id/partition drive names
looked long and complicated but they were reliable - you could look at
the device ids and know what the OS would call them.
See /dev/disk/by-{id,path,uuid}. This is also an advantage of LVM; it
knows how to find the physical volumes, and you generally don't have to
care (/dev/vg_foo is always /dev/vg_foo). Even Solaris' bus number
wasn't stable in the face of card changes IIRC.
The problem with enumerating devices by HBA/bus/ID/LUN is that today's
storage is more dynamic. USB ports are "SCSI" (protocol); how do you
number those? IIRC USB ports on a hub are not deterministically
ordered, so a flash card reader on a hub may come before a thumb drive
on one boot and after on the next.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
7:47 p.m.
On 14Oct2011 23:31, Chris Adams <cmadams(a)hiwaay.net> wrote:
| > Older Linux kernels carried along the SCSI ID as the device name,
|
| No, Linux always assigned SCSI devices in order from the start (e.g.
| sda, sg0, sr0, st0). Assigning with the ID was always something
| controversial, because on one hand, it would have given fixed device
| names (when that was desired for the more "enterprise-level" SCSI, when
| IDE always used hda for primary master, hdb for primary slave, etc.),
| while on the other, there weren't enough device major/minor numbers (and
| that assignment style never handled multiple buses or HBAs) to actually
| do that.
|
| Other OSes did it different, but not Linux, and certainly not any Fedora
| version (as the OP said). I'm pretty sure the only way Fedora would
| have had st4 without st[0-3] would have been if there was a udev rule to
| rename it.
Yes, and this has _long_ been a major annoyance to me.
Add a drive? Other drives get renamed!
Add a bus (eg new PCI SCSI card)? Other drives get renamed!
I've got a machine at home whose / drive gets renamed depending on
whether the PCI SCSI RAID stuff is broken or not. Hmm, shall root be on
sdb or sdc today? Maddening when trying to rescue.
I'm all ok with providing sda/hda as discovered, _provided_ one also has
nice bus/id type names as well. Solaris' bus/id/partition drive names
looked long and complicated but they were reliable - you could look at
the device ids and know what the OS would call them.
Cheers,
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
Three things are certain:
Death, taxes, and lost data.
Guess which has occurred.
- Haiku Error Messages http://www.salonmagazine.com/21st/chal/1998/02/10chal2.html
11:31 p.m.
Once upon a time, Rick Stevens <ricks(a)nerd.com> said:
Back in the day, the SCSI controller was assigned ID 7 and typically
tape drives were given ID 4. Hard drives were usually 0, 1, 2, and 3.
IDs 5 and 6 were left for the user. Don't ask me why...I suppose they
figured no one would ever need more than four hard drives. Then again,
While generally drives were given the low numbers (for boot order on
PCs), most of the drives I saw had the same 3 jumpers to assign any ID
(including 7 if you renumbered the SCSI card for any reason), the
rotating switch, or the up/down push-buttons. There wasn't any actual
reservation of the numbers for specific devices. IIRC I did see one
external tape drive that could only be 5 or 6 though (just because of
convention).
Then again,
Gates said we'd never need more than 640K of RAM.
No, he didn't.
Older Linux kernels carried along the SCSI ID as the device name,
No, Linux always assigned SCSI devices in order from the start (e.g.
sda, sg0, sr0, st0). Assigning with the ID was always something
controversial, because on one hand, it would have given fixed device
names (when that was desired for the more "enterprise-level" SCSI, when
IDE always used hda for primary master, hdb for primary slave, etc.),
while on the other, there weren't enough device major/minor numbers (and
that assignment style never handled multiple buses or HBAs) to actually
do that.
Other OSes did it different, but not Linux, and certainly not any Fedora
version (as the OP said). I'm pretty sure the only way Fedora would
have had st4 without st[0-3] would have been if there was a udev rule to
rename it.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:32 p.m.
On Friday, October 14, 2011 09:59:38 PM Rick Stevens wrote:
On 10/14/2011 11:51 AM, Chris Adams wrote:
> Once upon a time, Bill Perry <wlperry(a)williamperry.com> said:
>> It almost looks like the device changed from /dev/st4 to /dev/st0. Is
>> that possible?
>
> Yeah, I don't know why it would ever have been st4; the SCSI tape
> devices have always been numbered starting with 0 in my experience (I
> think I first used a SCSI tape device on Linux in 1996).
Back in the day, the SCSI controller was assigned ID 7 and typically
tape drives were given ID 4. Hard drives were usually 0, 1, 2, and 3.
IDs 5 and 6 were left for the user. Don't ask me why...I suppose they
figured no one would ever need more than four hard drives. Then again,
Gates said we'd never need more than 640K of RAM.
That actually has quite a
logical explanation. Assuming a narrow scsi bus, you
have 8 data lines. If the bus is idle and a device wants to send data, it
simply puts a signal on the line that corresponds to its ID. Then the device
will wait for a short period of time and then the one with the highest ID will
be allowed to procede. That's why the HBA is ID 7 - it always wins if there
are other devices that try to send at the same time. The tape device carried a
high penalty for running out of data to write: You had to stop the tape,
rewind, start again, find the exact spot and then continue writing. So you'd
give it a high ID. The actual ID wasn't always 4 though. HP DAT drives shipped
set to ID 3, quantum and its OEMs shipped ID6, so did storagetek LTO drives.
Older Linux kernels carried along the SCSI ID as the device name,
hence
the naming of /dev/st4 on older systems.
How old do we talk here? I started using
Linux when the version number still
had a beautiful 0 at the beginning :-)
Seriously though - st4 because of scsi id 4 makes little sense - what if you
have two HBAs? For the fun of it I pulled the 1.0 kernel source and even there
the kernel enumerates sg devices, then assigns the st device when an sg is of
the appropriate type. st4 can only happen if you have 5 devices that identify
themselves as tape or you accidentally set the tape device to the same id as
the controller.
Newer kernels typically query
the device as to what it is and start assigning hard drives starting at
/dev/sda, tapes at /dev/st0 and CD/DVD drives at /dev/cdrom0 (the
"/dev/sd<letter>" bit because drives can be partitioned).
BTW, as an aside, Sun always assigned their first hard drive to ID 1.
I guess because IBM was stupid enough to assign their first floppy to
ID 1 instead of 0 on the IBM PC (aka IBM 5150) and put that bloody
twist in the floppy cable to hide that rather obvious cockup.
SS10 or 20? :) coming
from an IPC where the drive was ID3, that took me a day
to figure out...
BTW, I was on one of the first ANSI SCSI committees (the conversion
from
SASI to SCSI) and was a design engineer for (gasp! is he really
that old?) Micropolis in the mid 70s.
Don't feel bad - nobody here is getting
any younger :)
Peter.
--
http://www.meaninglessrelict.com/
8:59 p.m.
On 10/14/2011 11:51 AM, Chris Adams wrote:
Once upon a time, Bill Perry <wlperry(a)williamperry.com> said:
> Then I decided to upgrade. I swapped out the motherboard and got a 64
> bit cpu and upgraded the OS (complete new install). I now have Fedora 15
> running on the box.
IIRC the "st" module may not be loaded automatically on newer systems.
Try a "lsmod | grep st" and "modprobe st" (if it isn't listed).
If that
fixes it, there are several ways to get the module loaded (try that and
post back the results).
> It almost looks like the device changed from /dev/st4 to /dev/st0. Is
> that possible?
Yeah, I don't know why it would ever have been st4; the SCSI tape
devices have always been numbered starting with 0 in my experience (I
think I first used a SCSI tape device on Linux in 1996).
Back in the day, the SCSI controller was assigned ID 7 and typically
tape drives were given ID 4. Hard drives were usually 0, 1, 2, and 3.
IDs 5 and 6 were left for the user. Don't ask me why...I suppose they
figured no one would ever need more than four hard drives. Then again,
Gates said we'd never need more than 640K of RAM.
Older Linux kernels carried along the SCSI ID as the device name, hence
the naming of /dev/st4 on older systems. Newer kernels typically query
the device as to what it is and start assigning hard drives starting at
/dev/sda, tapes at /dev/st0 and CD/DVD drives at /dev/cdrom0 (the
"/dev/sd<letter>" bit because drives can be partitioned).
BTW, as an aside, Sun always assigned their first hard drive to ID 1.
I guess because IBM was stupid enough to assign their first floppy to
ID 1 instead of 0 on the IBM PC (aka IBM 5150) and put that bloody
twist in the floppy cable to hide that rather obvious cockup.
BTW, I was on one of the first ANSI SCSI committees (the conversion from
SASI to SCSI) and was a design engineer for (gasp! is he really
that old?) Micropolis in the mid 70s.
An alternate way to always access a specific tape drive by a fixed
path
is via /dev/tape/by-id.
Yup. Generally /dev/st0 should get you your first tape drive, /dev/st1
the second and so on. Sorta like CD drives.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, C2 Hosting ricks(a)nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- We are born naked, wet and hungry. Then things get worse. -
----------------------------------------------------------------------
8 p.m.
On Fri, 2011-10-14 at 14:24 -0700, Bill Perry wrote:
Thank-you.
It appears that the st module is loaded.
#lsmod |grep st
<stuff>
st 32080 0
Next, I tried the command write to the tape as /dev/st0. I put a
writeable tape in the drive.
I have a couple of files in /root called yum_list...
tar cvf /dev/st0 /root/yum*
tar: /dev/st0: Cannot open: Input/output error
tar: Error is not recoverable: exiting now
The /dev/tape/by-id/... is a link pointing to /dev/st0
tar cvf /dev/tape/by-id/scsi-1HP_C7438_xxxxx /root/yum*
tar: /dev/tape/by-id/scsi-1HP_C7438A_xxxxx: Cannot open: Input/output error
tar: Error is not recoverable: exiting now
Running rescan-scsi-bus.sh does not help.
Running
mt -f /dev/st0 offline
does not do anything.
mt -f /dev/st0 status
SCSI 2 tape drive:
File number=-1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (10000):
IM_REP_EN
The tape drive still appears in lsscsi
----
st refers to an automatic tape drive and nst refers to a manually
controlled drive and most backup software prefers the usage of nst as it
wants to get control over the drive and tape positioning anyway.
You might want to try...
mt -f /dev/nst0 rewind
mt -f /dev/nst0 status
Craig
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
1:51 p.m.
Once upon a time, Bill Perry <wlperry(a)williamperry.com> said:
Then I decided to upgrade. I swapped out the motherboard and got a 64
bit cpu and upgraded the OS (complete new install). I now have Fedora 15
running on the box.
IIRC the "st" module may not be loaded automatically on newer systems.
Try a "lsmod | grep st" and "modprobe st" (if it isn't listed).
If that
fixes it, there are several ways to get the module loaded (try that and
post back the results).
It almost looks like the device changed from /dev/st4 to /dev/st0. Is
that possible?
Yeah, I don't know why it would ever have been st4; the SCSI tape
devices have always been numbered starting with 0 in my experience (I
think I first used a SCSI tape device on Linux in 1996).
An alternate way to always access a specific tape drive by a fixed path
is via /dev/tape/by-id.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
11:22 p.m.
On 16Oct2011 20:15, Chris Adams <cmadams(a)hiwaay.net> wrote:
| Once upon a time, Cameron Simpson <cs(a)zip.com.au> said:
| > I'm all ok with providing sda/hda as discovered, _provided_ one also has
| > nice bus/id type names as well. Solaris' bus/id/partition drive names
| > looked long and complicated but they were reliable - you could look at
| > the device ids and know what the OS would call them.
|
| See /dev/disk/by-{id,path,uuid}.
And does this work _before_ boot, in the root= kernel command line, via
grub.conf?
| This is also an advantage of LVM; it
| knows how to find the physical volumes, and you generally don't have to
| care (/dev/vg_foo is always /dev/vg_foo). Even Solaris' bus number
| wasn't stable in the face of card changes IIRC.
Yeah, but that is at least infrequent.
With my problem system, the hardware RAID appears before the SATA boot
drives. If RAID volumes are missing (totally failed, for example - there's
some weak hardware involved here) then my boot drive can be any of sda, sdb
or sdc. Normally it is sdc because the RAID has two volumes which land at
sda and sdb.
| The problem with enumerating devices by HBA/bus/ID/LUN is that today's
| storage is more dynamic. USB ports are "SCSI" (protocol); how do you
| number those? IIRC USB ports on a hub are not deterministically
| ordered, so a flash card reader on a hub may come before a thumb drive
| on one boot and after on the next.
I would at least number then _last_! (I know this is slightly
simplistic.)
But I'd be happy if linux presented /dev/usb0/node2/part1, for example.
I don't _care_ about the protocol, and few users of the device _by_name_
care either. As far as that level of user is concerned it is a block
storage device; the protocol is the kernel's problem, not the user's.
Cheers,
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
One rider (Kenny Roberts?) described The CorkScrew as:
It's like driving your bike into a phone booth, and then
having the phone booth dropped down an elevator shaft!
4632
days inactive
4636
days old
14 comments
9 participants
participants (9)
-
Alan Cox -
Bill Perry -
Cameron Simpson -
Chris Adams -
Craig White -
Joe Zeff -
Peter Arremann -
Rick Stevens -
Tim