Bug 122474 - K3B (and cdrecord) unable to burn from SCSI bus higher than 0.
K3B (and cdrecord) unable to burn from SCSI bus higher than 0.
Status: CLOSED DUPLICATE of bug 122096
Product: Fedora
Classification: Fedora
Component: k3b (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-04 18:13 EDT by Alex Markley
Modified: 2014-03-16 22:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 14:03:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
A console session showing more aspects of the bug. (1.57 KB, text/plain)
2004-05-04 18:26 EDT, Alex Markley
no flags Details
More detailed information from cdrecord. (5.31 KB, text/plain)
2004-05-04 23:16 EDT, Alex Markley
no flags Details

  None (edit)
Description Alex Markley 2004-05-04 18:13:03 EDT
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 18:26:42 EDT
Created attachment 99969 [details]
A console session showing more aspects of the bug.
Comment 2 Alex Markley 2004-05-04 18:28:53 EDT
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 18:30:51 EDT
What happens if you just pass dev=/dev/scd0 (or whatever) to cdrecord?
Comment 4 Alex Markley 2004-05-04 23:16:40 EDT
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-04 23:44:40 EDT
Don't use dev=X,Y,Z, just use dev=<device node>
Comment 6 Alex Markley 2004-05-05 01:14:23 EDT
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@xiph.org> and Xiphophorus

Report bugs to paranoia@xiph.org
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 01:50:25 EDT
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 14:03:00 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.