cdrecord maps <bus>,<target>,<lun> to /dev/sgX imperfectly

Bug #23203 reported by hunger
52
Affects Status Importance Assigned to Milestone
cdrkit (Ubuntu)
Invalid
Medium
Jonathan Riddell
Nominated for Feisty by Milan Bouchet-Valat
cdrtools (Ubuntu)
Fix Released
Undecided
Unassigned
Nominated for Feisty by Milan Bouchet-Valat
k3b (Debian)
Fix Released
Unknown

Bug Description

cdrecord -scanbus reports that my CDRW is device 1,0,0. Using that device causes it to use /dev/sg0,
which is actually my HD. Passing dev=/dev/cdrw works, but k3b and other burning apps do
not use that (and cdrecord claims that this method of giving a device is not supported).

Renaming /dev/sg1 to /dev/sg0 works as well, you do not even have to override the dev passed to
cdrecord then.

Some info about my system (both HD and CDRW are SATA drives):

> cat /proc/scsi/scsi ~
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA Model: HTS726060M9AT00 Rev: MH4O
  Type: Direct-Access ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: MATSHITA Model: DVD-RAM UJ-822S Rev: 1.03
  Type: CD-ROM ANSI SCSI revision: 05

> ls -alF /dev/sd* /dev/scd* /dev/sg* ~
brw-rw---- 1 root cdrom 11, 0 Oct 4 19:27 /dev/scd0
brw-rw---- 1 root disk 8, 0 Oct 4 19:26 /dev/sda
brw-rw---- 1 root disk 8, 1 Oct 4 19:26 /dev/sda1
brw-rw---- 1 root disk 8, 10 Oct 4 19:26 /dev/sda10
brw-rw---- 1 root disk 8, 11 Oct 4 19:26 /dev/sda11
brw-rw---- 1 root disk 8, 12 Oct 4 19:26 /dev/sda12
brw-rw---- 1 root disk 8, 13 Oct 4 19:26 /dev/sda13
brw-rw---- 1 root disk 8, 14 Oct 4 19:26 /dev/sda14
brw-rw---- 1 root disk 8, 2 Oct 4 19:26 /dev/sda2
brw-rw---- 1 root disk 8, 3 Oct 4 19:26 /dev/sda3
brw-rw---- 1 root disk 8, 4 Oct 4 19:26 /dev/sda4
brw-rw---- 1 root disk 8, 5 Oct 4 19:26 /dev/sda5
brw-rw---- 1 root disk 8, 6 Oct 4 19:26 /dev/sda6
brw-rw---- 1 root disk 8, 7 Oct 4 19:26 /dev/sda7
brw-rw---- 1 root disk 8, 8 Oct 4 19:26 /dev/sda8
brw-rw---- 1 root disk 8, 9 Oct 4 19:26 /dev/sda9
crw-rw---- 1 root root 21, 0 Oct 4 19:27 /dev/sg0
crw-rw---- 1 root cdrom 21, 1 Oct 4 19:27 /dev/sg1

> ls -alF /dev/cd*
lrwxrwxrwx 1 root root 4 Oct 4 19:27 /dev/cdrom -> scd0
lrwxrwxrwx 1 root root 4 Oct 4 19:27 /dev/cdrw -> scd0

> cdrecord -scanbus
[bla bla removed]
scsibus0:
        0,0,0 0) 'ATA ' 'HTS726060M9AT00 ' 'MH4O' Disk
        0,1,0 1) *
        0,2,0 2) *
        0,3,0 3) *
        0,4,0 4) *
        0,5,0 5) *
        0,6,0 6) *
        0,7,0 7) *
scsibus1:
        1,0,0 100) 'MATSHITA' 'DVD-RAM UJ-822S ' '1.03' Removable CD-ROM
        1,1,0 101) *
        1,2,0 102) *
        1,3,0 103) *
        1,4,0 104) *
        1,5,0 105) *
        1,6,0 106) *
        1,7,0 107) *

K3B debugging output (without override of dev):
System
-----------------------
K3b Version: 0.12

KDE Version: 3.4.91 (beta1, >= 20050910)
QT Version: 3.3.4
Kernel: 2.6.12-9-686
Devices
-----------------------
MATSHITA DVD-RAM UJ-822S 1.03 (/dev/scd0, /dev/sg1) at /media/cdrom0 [CD-R; CD-RW; CD-ROM; DVD-ROM;
DVD-RAM; DVD-R; DVD-RW; DVD+R; DVD+RW] [DVD-ROM; DVD-R Sequential; DVD-RAM; DVD-RW Restricted
Overwrite; DVD-RW Sequential; DVD+RW; DVD+R; CD-ROM; CD-R; CD-RW] [SAO; TAO; Restricted Overwrite]

K3b
-----------------------
Size of filesystem calculated: 277371

Used versions
-----------------------
mkisofs: 2.1-unofficial-iconv
cdrecord: 2.1.1a01

cdrecord
-----------------------
/usr/bin/cdrecord: Warning: Running on Linux-2.6.12-9-686
/usr/bin/cdrecord: There are unsettled issues with Linux-2.5 and newer.
/usr/bin/cdrecord: If you have unexpected problems, please try Linux-2.4 or Solaris.
/usr/bin/cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler
/usr/bin/cdrecord: Permission denied. WARNING: Cannot set priority using setpriority().
/usr/bin/cdrecord: WARNING: This causes a high risk for buffer underruns.
scsidev: '1,0,0'
scsibus: 1 target: 0 lun: 0
Error trying to open /dev/sg0 exclusively (Permission denied)... retrying in 1 second.
[repeated 9 times]
/usr/bin/cdrecord: Permission denied. Cannot open '/dev/sg0'. Cannot open SCSI driver.
/usr/bin/cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root.
/usr/bin/cdrecord: For possible transport specifiers try 'cdrecord dev=help'.
/usr/bin/cdrecord:
/usr/bin/cdrecord: For more information, install the cdrtools-doc
/usr/bin/cdrecord: package and read /usr/share/doc/cdrecord/README.ATAPI.setup .
Cdrecord-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Joerg Schilling
NOTE: this version of cdrecord is an inofficial (modified) release of cdrecord
      and thus may have bugs that are not present in the original version.
      Please send bug reports and support requests to <email address hidden>.
      The original author should not be bothered with problems of this version.
TOC Type: 3 = CD-ROM XA mode 2

cdrecord command:
-----------------------
/usr/bin/cdrecord.mmap -v gracetime=2 dev=1,0,0 speed=24 -tao driveropts=burnfree -eject -overburn
-multi -xa -tsize=277371s -

mkisofs
-----------------------
277371
INFO: UTF-8 character encoding detected by locale settings.
 Assuming UTF-8 encoded filenames on source filesystem,
 use -input-charset to override.

mkisofs command:
-----------------------
/usr/bin/mkisofs -gui -graft-points -volid K3b data project -volset -appid K3B THE CD KREATOR (C)
1998-2005 SEBASTIAN TRUEG AND THE K3B TEAM -publisher -preparer -sysid LINUX -volset-size 1
-volset-seqno 1 -sort /tmp/kde-tobias/k3bLg7Ela.tmp -rational-rock
-hide-list /tmp/kde-tobias/k3bWAI4fc.tmp -joliet -hide-joliet-list /tmp/kde-tobias/k3bKinSgc.tmp
-full-iso9660-filenames -iso-level 2 -path-list /tmp/kde-tobias/k3bvIN74a.tmp

When I add the user parameters dev=/dev/cdrw then cdrecord uses /dev/sg1 and all is well.

Revision history for this message
hunger (hunger) wrote :

PS: I am using breezy last updated today.

Revision history for this message
Matt Zimmerman (mdz) wrote :

k3b shoud use the /dev naming for exactly this reason

Matt Zimmerman (mdz)
Changed in cdrtools:
assignee: nobody → jr
Revision history for this message
Mikael Gerdin (mgerdin) wrote :

I have the exact same problem with cdrecord in Edgy, cdrecord is trying to write to sg0, regardless of what kind of dev=x,y,z I tell it to use. It works flawlessly with dev=/dev/sr0.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Same here. Using Edgy (updated from Dapper). First HD on 0,0,0 or /dev/sr0, cdrecord *and cdda2wav* trying to open /dev/sg0. Working with dev=/dev/sr0.

If you need some help, please just ask. ;-)

Revision history for this message
Matthieu Patou (mat-matws) wrote :

The root problem is that cdrecord scan /dev/sg* device when you specify dev=bus,target,lun, because 1,0,0 is not necesserly mapped to /dev/sg1.
If you have a sata or scsi drive then you've got a /dev/sg* entry for this device and since it's a drive a simple user has no read/write access (hopefully).
What's happening is the following :you have (or k3b) had specifed a dev=bus,target,lun to cdrecord, so it will try to scan your /dev/sgx devices in order to know which corresponds to the value of bus,target and lun specified in the command line.
The devices will be scaned starting from /dev/sg0,if a hard drive has a number smaller than the cd burner, cdrecord will fail to open it and so quit and won't try devices after it.

So to sum up the problem is not that cdrecord maps incorrectly the bus,target,lun to /dev/sg* but just than it gives up a too easily and its errors message are not precise enougth.

you can check my assertion by :

* renaming /dev/sg0 to /dev/sg27
* renaming /dev/sg1 to /dev/sg14

* run as root (or sudo) cdrecord -scanbus and you will see that what ever the sg number is your cdburner has always the same bus,target,lun address.

* try to burn a cd as a normal user and see that it works (or burn to more precise).

The solution to the bug are not obvious:
* maybe it's possible to change udev rules to number the cdburner before the disks
* Add a parameter to cdrecord to tell him not to exist on the first device guess error, and to yell only if it fails to find the device specified in the parameter
* run cdrecord with setuid (or setgid)

Revision history for this message
Matthieu Patou (mat-matws) wrote :

Needless to say that with the growing number of sata drive in the laptop and workstation this bug will be more and more anoying and will give a very bad image of *ubuntu distro ...

Revision history for this message
hunger (hunger) wrote :

Three dups and several reports here... I count that as confirmed:-)

Changed in cdrtools:
status: Unconfirmed → Confirmed
Revision history for this message
wilko (donwilkinson) wrote :

I fixed this on my system by adding a udev rule. You could simply add the necessary line in 40-permissions.rules but if there is an update to udev it will get overwritten and you'll be back where you started. So I created a new rule and called it 15-local.rules and put the following lines in the file:

# SCSI devices
BUS=="scsi", KERNEL=="sg[0-9]", NAME="%k", GROUP="cdrom"

Restart the system and in terminal run cdrecord -scanbus. You should no longer see the line"Error trying to open /dev/sg0 exclusively (Permission denied)".

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Looks like activity is down here. I was hoping one of the little tweaks exposed here would be added for feisty. Think that without this, we will have to wait 6 month to make many users (SATA disks are quite common) to use their burners out of the box...

Revision history for this message
Mikael Gerdin (mgerdin) wrote :

I suppose the good solution for this is to make cdrecord use sysfs to find out which sg-device belongs to which <bus>,<target>,<lun> triple.
I've just temporarily solved it by explicitly adding dev=/dev/scd0 to additional options for cdrecord in the settings for K3b. This could be generalized to dev=/dev/cdrw and thereby using whichever device udev thinks should be symlinked to /dev/cdrw.

Revision history for this message
Mario Đanić (mario-danic) wrote :

Just use cdrskin.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Mikael Gerdin's solution looks the simpler, and maybe the only that could be implemented before the freeze. I'm not sure this kind of fix is still allowed after the feature freeze, but beta freeze is on March 9th, if nobody plans to ask for an exception. Does anybody in the devel team cares about this bug for Feisty ?

Using cdrskin is a larger question: this may be a user choice, but newbies won't find out how to make their burner work until the default install is corrected in any way.

Revision history for this message
Asheesh Laroia (paulproteus) wrote :

FYI, the k3b issue is fixed in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386327

Changed in k3b:
status: Unknown → Fix Released
Revision history for this message
Schily (schilling-fokus) wrote :

You are not using cdrecord but a defective fork.

The problem you observe never has been in the original
software. Please upgrade to a recent original:

http://cdrecord.berlios.de/

Revision history for this message
Matthieu Patou (mat-matws) wrote :

This behaviour was added by debian/ubuntu patch to the sources of cdrecord.
If it has been decided to keep this patch it might that there is some (good ?) reason(s).

Revision history for this message
hunger (hunger) wrote :

Schily: I do not care what the original software does or does not. Downloading (and maybe even building) software from other places is just not an option. It might be interesting to the ubuntu developers to know this though.

I guess with the move away from cdrecord this bug is no longer relevant anyway.

Revision history for this message
Schily (schilling-fokus) wrote :

It is bad to see that Ubuntu intentionally adds bugs to software
and it is bad to see that Ubunto is not a free Linux distribution.

See

http://cdrecord.berlios.de/old/private/linux-dist.html

for more information.

Revision history for this message
Mikael Nilsson (mini) wrote : Re: [Bug 23203] Re: cdrecord maps <bus>, <target>, <lun> to /dev/sgX imperfectly

Jörg, please keep the politics off the bug tracker, please.

If anyone wants to see the Shilling version in Ubuntu, please file a
wishlist bug.

Here's the original announcement of cdrkit, for those who want more
context:

http://lwn.net/Articles/198171/

Now, back to bug fixing.

/Mikael

fre 2007-07-27 klockan 12:59 +0000 skrev Schily:
> It is bad to see that Ubuntu intentionally adds bugs to software
> and it is bad to see that Ubunto is not a free Linux distribution.
>
> See
>
> http://cdrecord.berlios.de/old/private/linux-dist.html
>
> for more information.
>
--
<email address hidden>

Plus ça change, plus c'est la même chose

Revision history for this message
Reinhard Tartler (siretart) wrote :

reassigning to correct package.

Revision history for this message
Schily (schilling-fokus) wrote :

Cdrecord uses a new libscg since August 2006. The new library contains
a workaround for the incompatible interface changes in the linux kernel that
caused the problems.

Changed in cdrtools:
status: New → Fix Released
Revision history for this message
Przemek K. (azrael) wrote :

Is this bug still valid for cdrkit in Ubuntu 9.10?

Revision history for this message
Schily (schilling-fokus) wrote :

cdrkit is unmaintained since May 6th 2007, don't expect any fix anytime soon.

If you like to use working software just use the original software.

Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Changed in cdrkit (Ubuntu):
status: Confirmed → Incomplete
status: Incomplete → Invalid
Revision history for this message
rusivi2 (rusivi2-deactivatedaccount) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. My apologies as I should not have marked this Invalid. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Maverick Meerkat. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

Changed in cdrkit (Ubuntu):
status: Invalid → Incomplete
Changed in cdrkit (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.