Red Hat Bugzilla – Bug 163729
udev not creating scsi tape devices
Last modified: 2014-03-16 22:54:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux; X11; en_US) KHTML/3.4.2 (like Gecko)
Description of problem:
Afer updating udev, hotplug, mkinitrd (and recreating the boot image) and
booting my external scsi tape devices are not created. The tape is recognized
and is there. Before I used to get nstXX devices and a logical link from tape to nst0.
Going into /dev directory and "MAKEDEV nst" creates all the nst devices and the
tape is usable.
PS: I have all packages at rawhide level except kernel, which is 2.6.12-1.1398_FC4smp
due to a bug in fusion mpt drivers that panic during boot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Upgrade to latest udev, hotplug, mkinitrd
3. try to use tape
cdrom links are not created as well. Device hdc is there but no link. Is this the job of
Some more info on the SCSI tape case: The tape uses the qla1280 driver, which is loaded
via modprobe.conf. This is the 2nd scsi adapter, the first one being the internal disk.
Modules are all loaded properly, just no device nst0 and logical link. Does SYMLINK have to be
on the ACTION line? I am all confused. Below is the output of udevinfo for nst0.
# udevinfo -a -p `udevinfo -q path -n /dev/nst0`
udevinfo starts with the device the node belongs to and then walks up the
device chain, to print for every device found, all possibly useful attributes
in the udev key format.
Only attributes within one device section may be used together in one rule,
to match the device for which the node will be created.
device '/sys/class/scsi_tape/nst0' has major:minor 9:128
looking at class device '/sys/class/scsi_tape/nst0':
follow the "device"-link to the physical device:
looking at the device chain at
looking at the device chain at
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1e.0/0000:02:09.0/host2':
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1e.0/0000:02:09.0':
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1e.0':
looking at the device chain at '/sys/devices/pci0000:00':
Note the SUBSYSTEM=="scsi_tape" line. The line in 50-udev.rules say SUBSYSTEM=="scsi",
is this a contradiction?
yes, "scsi_tape" != "scsi" ^^ This would explain the missing tape device.
Well, that change did not do it (just changing the rules file).
When I boot there is no class/scsi_tape either under /sys or in /dev/.udevdb/.
If I "modprobe st" then they are created.
What can I do?
ah, loading the st module was the job of hotplug
Switching component back, as this will get fixed in udev regardless.
Does scsi_mod & sd_mod get loaded correctly? If so, are those loaded from the
initrd, or from udev?
Yes, they are loaded correctly.
They are loaded from initrd since I have a scsi system. Here are the modules
ext3.ko jbd.ko mptbase.ko mptscsih.ko qla1280.ko scsi_mod.ko sd_mod.ko
qla1280.ko is for the second scsi adapter on which only the external tape is
Out of curiousity, what happens if you make the initrd without qla1280?
I have a long job running on the machine that I don't want to kill write now.
I'll try this as soon as possible.
What I suspect is happening here is that you're not getting the hotplug event
for the scsi tape device, because the adapter is being loaded in the initrd.
If you were to do 'modprobe -r qla1280 ; modprobe qla1280' I *suspect* the node
would be created correctly.
Fixed in 063-2; we were improperly setting SEQNUM on scsi replay events. This
should get handled correctly at boot now.
Unfortunately that did not solve my problem. When I remove the qla1280 from the
initrd than the module is not loaded after a boot. This has been the case in the past
and that is why I added that into modprobe.conf.
Doing a "modprobe qla1280" does load the module as well as the st module and creates all
the /dev/nst0 etc.
The tape is attached to an old Qlogic ISP1020 adapter (only used externally), which now
is also managed by the qla1280 module.
The line that I put into /etc/modprobe.conf are:
alias scsi_hostadapter2 qla1280
install qla1280 /sbin/modprobe --ignore-install qla1280
The tape is SONY SDT-9000, which is on during the boot. As I said I had this problem before
udev (device not being detected).
Hm, 063-2 didn't help at all?
I don't have a tape device, so I was testing with sd_mod; it worked in testing here.
Well, I just looked into the boot log and the adapter is reported by QLA1280 to
be QLA1040 as shown below. This used to be ISP1020 but they changed names
I guess. Where does one put this association to tell them to load qla1280 driver.
I don't see the PCI ID in the hwdata.
Jul 20 08:04:54 compsci kernel: qla1280: QLA1040 found on PCI bus 2, dev 9
Jul 20 08:04:54 compsci kernel: scsi(2:0): Resetting SCSI BUS
Jul 20 08:04:54 compsci kernel: scsi2 : QLogic QLA1040 PCI to SCSI Host Adapter
Jul 20 08:04:54 compsci kernel: Firmware version: 7.65.00, Driver version 3.25
Jul 20 08:04:54 compsci kernel: Vendor: SONY Model: SDT-9000 Rev: 0400
Jul 20 08:04:54 compsci kernel: Type: Sequential-Access ANSI SCSI
Jul 20 08:04:54 compsci kernel: scsi(2:0:2:0): Sync: period 10, offset 12
OK, I think we're talking cross-purposes now.
The new udev-063-2 should work with *whatever* your initrd was before (i.e.,
with both scsi adapters in it). The comments before about changing what was in
the initrd were for debugging, attempting to figure out where the failure was.
OK. This is the summary:
1. Without qla1280 in the initrd hotplug *never* found this device (going back the FC2/FC3
days). In the past the driver was called qlogicisp, which was recently changed to be a
submodule for qla1280.
2. When the qla1280 was in initrd something loaded the "st" module and created the device
nodes and the logical link to tape. I don't exactly know when this stopped working
but it is at most a week or two.
So, it seems like as hotplug functions are transferred to udev this device, which had prolems
to begin with, has fallen into the undefined zone!
Please let me know what other information I can supply.
1. is a module bug, it needs to export PCI ids correctly.
The new udev (063-2) does not solve #2?
No. 063-2 does not solve "2" i.e. it does not load the "st" module.
I am sorry for the delayed response but I am running very long jobs and I
have to wait till they finish before reboot.
I have found/added the following to rc.sysinit file that does the job:
# If a SCSI tape has been detected, load the st module unconditionally
# since many SCSI tapes don't deal well with st being loaded and unloaded
if [ -f /proc/scsi/scsi ] && LC_ALL=C grep -q 'Type: Sequential-Access' /proc/scsi/scsi
2>/dev/null ; then
LC_ALL=C fgrep -q ' 9 st' /proc/devices || modprobe st >/dev/null 2>&1
It is not the desired way but does the job.
Created attachment 117246 [details]
change to /sbin/start_udev
Can you try this patch to /sbin/start_udev?
Relaying the hotplug events via udev doesn't seem to quite make sense if udev
isn't running at the time.
No, it did not help. Furhermore, during boot it gave the [FAILED] message
when udev was starting but continued anyway. No tape devices were created.
One more thing; after doing "modprobe st" now only devices created are nst0a, nst0l, and
nst0m. No logical link to tape and no nst0. This is using the udev from rawhide and the above
lines in rc.sysinit.
This used to work fine with the latest udev so it may have to do with MAKEDEV removal.
OK.... udev-063-6 seems to have solved the problem!