Bug 122474

Summary: K3B (and cdrecord) unable to burn from SCSI bus higher than 0.
Product: [Fedora] Fedora Reporter: Alex Markley <alex>
Component: k3bAssignee: Bill Nottingham <notting>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: 64bit_fedora, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 19:03:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A console session showing more aspects of the bug.
none
More detailed information from cdrecord. none

Description Alex Markley 2004-05-04 22:13:03 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
Seems that access to devices on SCSI bus 1 is very limited. I can
mount disks in devices on scsi bus one, but I can not burn to these
devices, or rip from them.

I am not sure, but it seems this may be a /dev/inode problem.

Version-Release number of selected component (if applicable):
k3b-0.11.9-3

How reproducible:
Always

Steps to Reproduce:
1. Boot system with two SCSI adaptors installed.
2. Make sure CDROM device is present on the second bus.
3. Make sure modules are loaded.
4. Run "cdrecord -scanbus"

Actual Results:  Only the first real bus appears.

Expected Results:  All devices on all busses should appear.

Additional info:

I will be attaching /proc files and program output in a few minutes...
Comment 1 Alex Markley 2004-05-04 22:26:42 UTC 
Created attachment 99969 [details]
A console session showing more aspects of the bug.
Comment 2 Alex Markley 2004-05-04 22:28:53 UTC 
BTW. Sorry for picking k3b as the buggy component. I know the bug
isn't a k3b bug, but I don't know where else to put it. ;)
Comment 3 Bill Nottingham 2004-05-04 22:30:51 UTC 
What happens if you just pass dev=/dev/scd0 (or whatever) to cdrecord?
Comment 4 Alex Markley 2004-05-05 03:16:40 UTC 
Created attachment 99973 [details]
More detailed information from cdrecord.

Seems that providing the /dev/inode of the device works, even when the cdrecord
device number doesn't.

The exact error from cdrecord is that it can't find the pg entry it wants. Even
after creating this entry, the burn fails when referencing the device using
cdrecord's device numbering scheme.
Comment 5 Bill Nottingham 2004-05-05 03:44:40 UTC 
Don't use dev=X,Y,Z, just use dev=<device node>
Comment 6 Alex Markley 2004-05-05 05:14:23 UTC 
Sadly, it's not that simple. K3B can't access cdrecord without using
the dev=x,y,z reference format, and cdrecord clearly complains about
using the device node:
"Warning: Open by 'devname' is unintentional and not supported."

Also, what I believe to be the same problem causes cdparanoia to be
unable to open the drive:
[root@lightning tmp]# ls -l -h /dev/sg1
crw-rw-rw-  1 root disk 21, 1 Feb 23 16:02 /dev/sg1
[root@lightning tmp]# cdparanoia -B -d /dev/scd0
cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty> and Xiphophorus

Report bugs to paranoia
http://www.xiph.org/paranoia/

Error trying to open /dev/sg1 exclusively (No such device or address).
retrying in 1 second.
Error trying to open /dev/sg1 exclusively (No such device or address).
retrying in 1 second.
Error trying to open /dev/sg1 exclusively (No such device or address).
retrying in 1 second.
Error trying to open /dev/sg1 exclusively (No such device or address).
retrying in 1 second.
Error trying to open /dev/sg1 exclusively (No such device or address).
retrying in 1 second.

[root@lightning tmp]#

I'm beginning to think that this is a bug in RedHat's patched kernel.
I will be building a vanilla kernel for this machine tomorrow to test
this theory.
Comment 7 Bill Nottingham 2004-05-05 05:50:25 UTC 
Closing as dup of the other k3b-doesn't-use-the-correct-cdrecord syntax.

I think you'll find that the new behavior is a general 2.6 thing.

*** This bug has been marked as a duplicate of 122096 ***
Comment 8 Red Hat Bugzilla 2006-02-21 19:03:00 UTC 
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.