Bug 129671

which kernel version?

Last tested version was kernel-2.6.7-1.515. I am downloading the
latest updates now.

Can't test currently due to device node problems related to udev.

update to the newest udev

Doing so and building a new initrd brought back the SCSI device nodes.

The behaviour is still there with 2.6.8-1.526, but I noticed something
helpful.

k3b does not detect the SCSI drives if the sr_mod kernel module is not
loaded when starting k3b (the module is loaded on demand, and is often
not needed before). k3b causes the module to be loaded, but seemingly
not early enough to actually detect the drives. When quitting k3b, the
module is loaded, and so the next start detects the SCSI drives.
Manually unloading sr_mod confirms this behaviour (no SCSI drives on
next k3b startup).

ok, new k3b, new cdrtools and new dvd+rw-tools should be worth a retry :)

With a system current as of today (kernel, udev, k3b...), k3b does not
see any drives at all on startup. This is mainly due to udev
weirdness, the /dev/cdrom*, /dev/cdwriter* et al links are missing,
and because of this the permissions on the devices are not set
correctly by /etc/security/console.perms. In addition, the SCSI CDROM
driver is not being loaded, so the SCSI device nodes are missing, too.

When loading sr_mod manually, and setting the permissions on all CDROM
device nodes to enable read/write access by every user, k3b detects
the DVD writer connected to /dev/hdc. This device is detected
correctly as a writer, the writing modes displayed in the config
dialog are correct, as are the "writes ..." and "reads ..." entries.

The SCSI drives, however, remain invisible. sr_mod is loaded, /dev/sr*
has the correct permissions. Manually adding the devices in the
configuration dialog fails, too. k3b claims that there is no
additional device to be found.

should be fixed now with new k3b, cdrecord and udev

The IDE writer is seen by k3b, and seems to be fully functional (I
have only looked at the config screen, but all the necessary frobs are
set as they ought to be).

All SCSI drives remain invisible to the system at large, due to
missing /dev entries. Please see Bug 131762 and Bug 133171 for similar
reports.

/dev/sr? are now mapped to /dev/scd? with the new udev package

Which udev would that be? I have udev-030-27, and neither sr? nor scd?
appear in /dev.

kernel is 2.6.8-1.584, initrd was rebuilt to include latest udev.

Oh, manually loading sr_mod makes /dev/scdX and associated /dev/cdromX
appear, but sr_mod is not loaded automatically, because the device
nodes are missing. Kind of a chicken-egg-problem.

newesr udev is udev-032 in rawhide

if I load my scsi host adapter module, sr_mod is loaded automatically...
kernel-2.6.8-1.541smp

OK, the newest udev had not made it's way to my mirror-of-choice, I am
getting it from another mirror now.

The scsi host adapter module is loaded by initrd in my case (I don't
know why, since there are no hard disks attached to it anyway, but
mkinitrd seems happy that way, and no harm is done), but it does not
load sr_mod.

Please see Bug 133194.

On my system, if the scsi adapter module is loaded it automatically
loads the sr_mod module after detecting the CDROM attached to it...

# rpm -qf /etc/hotplug/scsi.agent
hotplug-2004_04_01-5

this hotplug agent loads sr_mod for me.

you may set in /etc/sysconfig/hotplug:
DEBUG=1
and watch /var/log/messages

which scsi hostadapter do you have?

Up to the latest and greatest udev/kernel/k3b, and still no luck on
the automatic SCSI drive loading.

The hostadapter is a "Adaptec AHA-2940U/UW/D / AIC-7881U" (courtesty
of lspci), driver is aic7xxx, loaded by initrd (thus, sr_mod can not
be loaded by hotplug when the hostadapter comes up, because sr_mod.ko
is not part of the initrd image).

I tried inserting the sr_mod driver manually, before logging into X,
which creates /dev/scdX and several /dev/cdromX entries. So far, so good.

Logging into X chown()s all cdrom entries (1 IDE, 3 SCSI) to my user
id. Fine. But k3b still does not see any of the SCSI drives. Something
must still be missing.

So we have two different problems here, I think.

could you please attach the output of:
$ strace -f -o open,ioctl k3b

I assume you meant
$ strace -f -e trace=open,ioctl k3b

Created attachment 104261 [details]
strace -f -e trace=open,ioctl

what does:
$ cat /proc/sys/dev/cdrom/info

say?

Hmm... k3b checks...

4848  open("/dev/scd0", O_RDWR|O_NONBLOCK) = 11
4848  ioctl(11, CDROMAUDIOBUFSIZ, 0xfeee85b8) = 0
4848  ioctl(11, 0x5386, 0xfeee8724)     = 0
4848  open("/dev/scd1", O_RDWR|O_NONBLOCK) = 11
4848  ioctl(11, CDROMAUDIOBUFSIZ, 0xfeee85b8) = 0
4848  ioctl(11, 0x5386, 0xfeee8724)     = 0
4848  open("/dev/scd2", O_RDWR|O_NONBLOCK) = 11
4848  ioctl(11, CDROMAUDIOBUFSIZ, 0xfeee85b8) = 0
4848  ioctl(11, 0x5386, 0xfeee8724)     = 0

[sun@nausicaa ~ :) 1]$ cat /proc/sys/dev/cdrom/info
CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name:             sr2     sr1     sr0     hdc
drive speed:            1       6       0       40
drive # of slots:       1       1       1       1
Can close tray:         1       1       1       1
Can open tray:          1       1       1       1
Can lock tray:          1       1       1       1
Can change speed:       0       1       1       1
Can select disk:        0       0       0       0
Can read multisession:  1       1       1       1
Can read MCN:           1       1       1       1
Reports media changed:  1       1       1       1
Can play audio:         1       1       1       1
Can write CD-R:         0       1       0       1
Can write CD-RW:        0       1       0       1
Can read DVD:           0       0       1       1
Can write DVD-R:        0       0       0       1
Can write DVD-RAM:      0       0       0       0
Can read MRW:           1       1       1       1
Can write MRW:          1       1       1       1
Can write RAM:          1       1       1       1

For some obscure reason k3b now manages to see one of the SCSI drives
as well (scd0, the DVD drive). I am not sure what triggered that, but
it may be a newer kernel (currently -590)

OK, I've found the obscure reason: there was a CD in the drive.
Whenever a medium is in one of the SCSI drives when k3b starts (does
not have to be mounted, just be there), k3b detects the drive.

This seems to leave some "residue" somehow. Example:

1) Insert CD in SCSI drive
2) start k3b -> scsi drive is detected (correct name, device,
properties), IDE drive is detected (as always)
3) quit k3b
4) remove disk from SCSI drive
5) start k3b -> IDE drive is now displayed twice, once with it's own
device node and properties, once as the (now empty) SCSI drive (with
the device node and properties of the SCSI drive, but with the name of
the IDE drive)

Very strange things happen.

This could be related to bug 134822 
could you try:
# for i in /dev/scd*;do dvd+rw-mediainfo $i;done
and
# for i in /dev/sg*;do  cdrecord -VVVVVVVV -inq dev=$i;done
# for i in /dev/scd*;do  cdrecord -VVVVVVVV -inq dev=$i;done

Created attachment 104846 [details]
Output of the commands requested above

This is a "script" dump, there may be funny characters in it. The commands are
executed without disks in the drives first, and with disks in them in the
second run.

When I start k3b after doing this (without disks in the drives), I get
three drives listed in the config dialog. All are called "_NEC DVD_RW
ND-2500A" (which is the drive at hdc), but the properties and devices
are those of scd0 (the pioneer dvd reader) and scd2 (the traxdata cd
writer). scd1 does not show, but I suspect I know why that is.

Sorry for the confusion, but scd2 is not the traxdata writer, but the
plextor cd drive.

ok, it seems that the inquiry does not succeed without disks in the
drives... does k3b find all with disks in the drive?

Yes, all drives are correctly found and identified as what they are.
Kernel is 2.6.8-1.590

so, I think, I can make this bug a DUPLICATE of bug 134822 ??

*** This bug has been marked as a duplicate of 134822 ***

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.