[Gelöst] Suse10.1: k3b erkennt SCSI-Brenner nicht

[m00nraker]

Hallo.

Wer kann mir helfen?

Problem:
---------------
In meinem PC steckt ein SCSI CD-Schreiber, angeschlossen an eine Adaptec 2940UW Karte, kein weiteres Leselaufwerk.
k3b erkennt den CD-Brenner nur als Lesegerät und nicht zusätzlich auch als
CD-Brenner. cdrecord funktioniert jedoch einwandfrei.

Mein System:
----------------------
CDR: Plextor PX-W124TS '/dev/sr0 (0,5,0)' Firmware 1.06
OS: Opensuse 10.1-GM
KDE-Version: Zuerst v3.5.1 , seit heute v3.5.2
k3b: 0.12.15 (aus Packman Repos für Opensuse 10.1)
cdrecord: v2.01 (i686-suse-linux) - unofficial (modified) (aus Opensuse 10.1 Base Repos.)
cdrdao: v1.2.0
mkisofs: v2.1

Situation:
--------------

Unter Suse Linux 10.0 (Standardinstallation mit k3b von Packman, installiert
durch smart) funktionierte mein k3b einwandfrei. Der Plextor Brenner wurde
problemlos erkannt. Nach dem Upgrade von Suse 10.0 auf Opensuse 10.1-Factory
hat k3b meinen Brenner nur noch als Lesegerät erkannt, obwohl cdrecord auf
Konsolenebene den Brenner einwandfrei erkannt hat. Auch konnte ich auf
Konsolenebene mit cdrecord oder cdrdao einwandfrei CDs brennen.

Nun habe ich Opensuse 10.1 GM komplett neu installiert (kein Upgrade, nur
Standardinstallation). k3b erkennt meinen Brenner noch immer nicht. Dann habe
ich k3b via. Smart durch die Version von Packman ersetzt. Keine Änderung, k3b
listet meinen Brenner nur als Leselaufwerk. Ich hatte k3b stets mit
root-Rechten gestartet. Der selbe Effekt tritt auf, wenn ich k3b als User
starte. Natürlich habe ich auch den k3b-Einrichtungsassistent benutzt, um die
Berechtigungen zu setzen, jedoch mit dem selben Ergebnis: Kein Brenner
erkannt. Dabei habe ich wie vom Assistenten vorgeschlagen vorher eine
Brenngruppe "burning" eingerichtet und den User root, als auch mein
persönliches User-Login dieser Gruppe hinzugefügt. Anschließend hat der
Assistent die Berechtigungen neu gesetzt. Auch dies nützt nichts. Statt der
Gruppe "burning" habe ich es auch mit der vorhandenen Systemgruppe "disk" und
"cdrom" versucht, so wie es hier in den FAQs zu lesen war. Auch damit hatte
ich kein Erfolg. Bisher hatte ich nie Probleme mit k3b gehabt, dass mein
Laufwerk nicht erkannt wurde. Seit der 10.1 (egal ob Factory oder GM) habe
ich dieses Problem. Auf Konsolen-Ebene kann ich jedoch problemlos brennen.

Hier nochmal einige Berechtigungen:
brw-r-----+ 1 root disk 11, 0 2006-05-17 08:49 /dev/sr0
-rwxr-x--- 1 root disk 328616 2006-05-02 08:53 cdrecord
-rws--x--- 1 root disk 567328 2006-05-03 03:40 cdrdao

Bevorzugen würde ich natürlich, dass nicht nur der Brenner wieder von k3b
erkannt wird, sondern dass dies auch gleichzeitig als normaler User
funktionieren würde.

Auf der k3b Projektseite sind derartige Probleme bekannt, dass ein Gerät nicht erkannt wird oder man nicht als User brennen kann. Allerdings führen die Jungs die Ursache meist auf cdrecord zurück und meinen, dass dies nicht an k3b liegen kann. Nur ist es so, dass cdrecord zumindest in meinem Fall einwandfrei läuft. Muss das Problem dann nicht zwangsläufig allein bei k3b liegen? Oder kommen noch andere Ursachen in Frage?

Ich wäre sehr dankbar, wenn mir bitte jemand helfen würde, dieses lästige
Problem in den Griff zu bekommen.

Gruss, Kai

 

[m00nraker]

Also ich habe zur Sicherheit mal eine Knoppix-CD (v4.02) gebootet. k3b hat das Laufwerk einwandfrei als Brenner erkannt. Ist also kein Hardware Problem.

Bei der Knoppix ist mir aufgefallen, das k3b den Brenner über einen symb. Link /dev/sr0 anspricht:
lrwxrwxrwx root cdrom sr0->scd0
brw-rw---- root cdrom scd0

Bei Suse gibt es bei mir diesen symb. Link nicht. Dort sieht es so aus:
brw-rw----+ root cdrom sr0
crw-rw----+ root cdrom sg0
In k3b wird der Brenner nur als Lesegerät mit der Gerätebez. /dev/sr0 gelistet. Wozu sg0 ist, weiss ich nicht.

cdrecord hat unter Knoppix andere Rechte als unter Suse:

Knoppix: -rwxr-sr-x root cdrom cdrecord
Suse: -rwxr-x--- root cdrom cdrecord

Die Rechte unter Suse wurden von dem k3b-Einrichtungsassistenten so gesetzt. Liegt dort vielleicht der Fehler? cdrecord von einer Shell aus gestartet erkennt den Brenner sofort.

Auch habe ich k3b zwischenzeitlich komplett deinstalliert inkl. der k3b-Dateien im Home-Verzeichnis. Eine anschließende Neuinstallation machte keinen Unterschied im Verhalten.

Vielleicht kann mir zumindest jemand erklären, wie bzw. mit welchem externen Programm k3b die Laufwerkserkennung durchführt bzw. den SCSI-Bus nach Geräten scannt. Für meine Verhältnisse habe ich mittlerweile alles ausprobiert und komme leider nicht zum Ziel.

Hat nicht jemand eine Idee?
[/b]

 

[Freecoffee]

/dev/sg0 deutet auf eine generische SCSI-Schnittstelle hin, die ist für manche Geräte noch ab und an nützlich. Näheres dazu in der Kernel-Dokumentation.
Was die Rechte betrifft: Bei mir sieht das so aus:
brw-rw----+ 1 freecoffee disk 3, 64 2006-05-17 20:36 /dev/hdb

Hast du schon versucht, den K3B-Einrichtungsassistenten noch einmal laufen zu lassen? Was steht bei den K3b-Optionen unter "Geräte"?

 

[m00nraker]

N'abend Freecoffee...

Ich hoffe nicht, deshalb noch in der Kernel-Doku wühlen zu müssen...

Also sr0 deutet dann ebenfalls auf eine generische SCSI-Schnittstelle hin. Ist klar, denn der Plexwriter ist ja auch ein SCSI-Device.

Hast du schon versucht, den K3B-Einrichtungsassistenten noch einmal laufen zu lassen?

Den Assistenten habe ich wie oben beschrieben schon x-mal ausgeführt, mit unterschiedlichen Gruppen. Aber k3b erkennt den Plex einfach nicht als Schreiber, cdrecord jedoch schon.

Die Rechte sehen bei mir genauso aus wie bei Dir. Wie ich allerdings sehe, hast Du einen IDE-Schreiber (hdb), richtig? Und als Gruppe benutzt Du die Systemgruppe "disk". Dies hatte ich wie oben beschrieben auch schon versucht. In Knoppix wird als Gruppe "cdrom" genommen. Aber einen Unterschied macht das scheinbar nicht.

Was steht bei den K3b-Optionen unter "Geräte"?

Siehe auch oben. Dort wird mein Schreiberling nur als Lesegerät erkannt.
Gerätename im System: /dev/sr0 (0,5,0).
Das Gerät hat also die SCSI-ID 5. Dies wird auch im Adaptec-Bios angezeigt. Wie gesagt, ich hatte nie Probleme damit gehabt, bis zur Installation der 10.1.

Wenn ich in der Shell "cdrecord --scanbus" ausführe, erhalte ich folgende Ausgabe:

delta:/home/kai # cdrecord --scanbus
Cdrecord-Clone 2.01 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling
Note: This version is an unofficial (modified) version
Note: and therefore may have bugs that are not present in the original.
Note: Please send bug reports or support requests to http://bugs.opensuse.org/
Note: The author of cdrecord should not be bothered with problems in this version.
Linux sg driver version: 3.5.33
Using libscg version 'schily-0.8'.
cdrecord: Warning: using inofficial libscg transport code version (okir@suse.de-scsi-linux-sg.c-1.83-resmgr-patch '@(#)scsi-linux-sg.c   1.83 04/05/20 Copyright 1997 J. Schilling').
scsibus0:
        0,0,0     0) *
        0,1,0     1) *
        0,2,0     2) *
        0,3,0     3) *
        0,4,0     4) *
        0,5,0     5) 'PLEXTOR ' 'CD-R   PX-W124TS' '1.06' Removable CD-ROM
        0,6,0     6) *
        0,7,0     7) *
scsibus1:
        1,0,0   100) 'USB2.0  ' 'CardReader CF RW' '0.0>' Removable Disk
        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) *

Gruss, Kai

 

[Freecoffee]

Versuch doch einmal, den Brenner über das generische Interface /dev/sg0 anzusprechen. Das ist für alles da, was nicht CD-ROM, Festplatte oder Tape ist, insbesondere also für Brenner und Scanner.

 

[m00nraker]

Hallo...

Also, zunächst glaube ich nicht, dass hier ein Rechte-Problem vorliegt.

Das Problem ist nach wie vor, dass ich nicht genau weiss, wie k3b bei der Laufwerkserkennung vorgeht. Deswegen weiss ich auch nicht, wo ich nach dem Fehler suchen muss. Hinzu kommt, dass mir vielleicht bestimmtes Hintergrundwissen fehlt.

Entweder liegt das Problem direkt in k3b (Fehler) oder ist ein spezieller Fehler bzw. eine Eigenheit der Opensuse 10.1. Ein Rechteproblem schließe ich mal aus, da ich diesbezüglich alles versucht habe. Und cdrecord brennt einwandfrei.

Mir ist die Unterscheidung zwischen sg* und sr* nicht so ganz klar, und was k3b nun genau benötigt. Soweit ich rausgefunden habe, ist der udev-deamon (udevd) dafür verantwortlich, u.a. die Gerätenamen in /dev dynamisch zu erzeugen bzw. bei Bedarf wieder zu entfernen.

Beispiel:

Stecke ich einen USB-Stick in den USB-Port, wird dies vom Kernel erkannt. Dieser wiederum informiert den udevd über die neue Hardware. Aufgabe des udevd ist es u.a. nun, im Verzeichnis /dev dynamisch einen neuen Device-Namen für das erkannte Gerät mit den entsprechenden Berechtigungen anzulegen. Dies passiert auch, wenn während des Bootvorgangs neue Hardware wie z.B. CD-Laufwerke erkannt werden. Der Kernel informiert udevd also über das Vorhandensein meines SCSI-Schreibers. udevd erzeugt dann während des Bootens in /dev die beiden Einträge /dev/sr0 und /dev/sg0. In diesem Fall sind die entsprechenden Berechtigungen für diese beiden Geätedateien in

 /etc/udev/rules.d/50-udev-default.rules

festgelegt. Dort steht also z.B. drin, dass sg* die Rechte "640" erhält. Analog dazu sr*. Wenn man also manuel die Rechte von sr0 und sg0 ändert, werden diese gemäß der Festlegung in der rules-Datei nach einem neuen Bootvorgang wieder auf die Default-Werte zurückgesetzt. Deswegen müsste man Rechte wenn schon in der Rules-Datei ändern, damit sie persistent bleiben. Aber die Rechte sind meiner Meinung nach korrekt gesetzt.

Soweit kann ich die udev-Geschichte nachvollziehen.

In den man-Pages von cdrecord ist auch genau beschtrieben, welche Rechte cdrecord für die jeweiligen Anwendungsfälle am besten erhalten sollte. Auch dies ist alles korrekt. Ich könnte sogar als User Brennen.

Wenn ich auf Shell-Ebene z.B. eine CD-RW löschen möchte, mache ich dies so:

cdrecord dev=0,5,0 blank=fast

Ebenso funktioniert aber auch:

cdrecord dev=/dev/sr0 blank=fast

und

cdrecord dev=/dev/sg0 blank=fast

Worin besteht denn nun der Unterschied zwischen den beiden Device-Namen sr0 und sg0?

Wie ich in der Rules Datei sehen kann, handelt es sich bei sg0 um ein sog. Character-Device (kein Block-Device), während sr0 ein Block-Device ist. Dies kennzeichnet im Verzeichnis /dev auch der Buchstabe C bei sg0 und B bei sr0. In der k3b-Geräteliste steht der Schreiber mit /dev/sr0 in der Liste. k3b greift auf das Laufwerk also über einen Gerätenamen für ein Block-Device zu. Während cdrecord damit keine Probleme hat, kann k3b das Laufwerk so aber nicht korrekt erkennen. Der Einrichtungsassistent von k3b setzt Berechtigungen aber sowohl für sr0 als auch für sg0.

Liegt vielleicht dort der Fehler, das k3b das Gerät über den Device-Namen /dev/sr0 nicht richtig als Schreiber erkennt?

Wie kann ich denn k3b dazu bewegen, das Laufwerk über sg0 statt über sr0 anzusprechen? Man kann ja dort nichts einstellen. Und die Hinzufügen-Funktion über Geräte-Einstellen findet keinen weiteren Brenner, egal was ich dort eingebe.

Hier habe ich noch einen Auszug aus /var/log/boot.msg:

<6>scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
<4>        <Adaptec 2940 Ultra SCSI adapter>
<4>        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
<4>
<5>  Vendor: PLEXTOR   Model: CD-R   PX-W124TS  Rev: 1.06
<5>  Type:   CD-ROM                             ANSI SCSI revision: 02
<6> target0:0:5: Beginning Domain Validation
<6> target0:0:5: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 8)
<6> target0:0:5: Domain Validation skipping write tests
<6> target0:0:5: Ending Domain Validation
<4>sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
<6>Uniform CD-ROM driver Revision: 3.20
<7>sr 0:0:5:0: Attached scsi CD-ROM sr0
<5>sr 0:0:5:0: Attached scsi generic sg0 type 5

Sieht doch eigentlich ganz gut aus. sr0 ist sogar als Writer aufgeführt.

Sorry, das ich soviel geschrieben habe, aber ich komme echt nicht weiter.

Gr. Kai

 

[Freecoffee]

Der Unterschied liegt wie du schon sagtest darin, dass sr0 explizit ein block device, sprich eine Festplatte, ein CD-ROM oder ein Bandlaufwerk anspricht. sg0 (für SCSI generic) bietet eine generische Schnittstelle, über die alle Arten von SCSI-Peripherie angesprochen werden können, sie ist also z.B. bei Brennern das Mittel der Wahl.

Versuche einmal in der Datei ~/.kde/config/k3brc im Abschnitt [Devices] den Eintrag device_search_path auf /dev/sg0 zu ändern.

 

[m00nraker]

Danke für Deinen Hinweis, ich habe es sofort ausprobiert.

In

 /root/.kde/share/config/k3brc

stand vor der Änderung folgender Inhalt:

[Devices]
PLEXTOR CD-R   PX-W124TS=0,0,auto,auto
device_search_path=/dev/sr0

In den k3b-Optionen unter Geräte sah es vor der Änderung so aus:

Lesegeräte: PLEXTOR CD-R PX-W124TS
  Gerätename im System: /dev/sr0 (0,5,0)
  Schnittstellentyp          : Generisches SCSI
  ...
  CDRDAO-Treiber         : Auto

Brenner: keine

Ich habe also in der k3brc /dev/sr0 gegen /dev/sg0 ersetzt. Nach einem Neustart von k3b mit root-Rechten sahen die k3b Geräteeinstellungen wie folgt aus:

Lesegeräte: PLEXTOR CD-R PX-W124TS
  Gerätename im System: /dev/sr0 (0,5,0)
  Schnittstellentyp          : Generisches SCSI
  ...
  CDRDAO-Treiber         : Auto

Brenner: keine

Hier ist also kein Unterschied nach der Änderung zu erkennen. Es steht dort weiterhin /dev/sr0. Von sg0 ist nichts zu sehen.

Nachdem ich k3b dann beendet habe, hat k3b den Inhalt der k3brc Datei komischerweise folgendermaßen geändert:

[Devices]
PLEXTOR CD-R   PX-W124TS=0,0,auto,auto
device_search_path=/dev/sg0,/dev/sr0

k3b hat also den Eintrag /dev/sr0 wieder hinzugefügt, obwohl ich den manuell entfernt hatte. Auch ein erneuter Neustart von k3b mit dieser k3brc Datei zeigt die selben Geräteeinstellungen in k3b an.

Ich habe auch versucht, in der k3brc Datei den Eintrag

PX-W124TS=0,0,auto,auto

auf andere Werte zu setzten: ...=0,0,5,0. Ebenfalls ohne Erfolg.

/dev/sg0 taucht in den k3b-Geräteeinstellungen nicht auf, auch wenn es in der rc-Datei steht.

Was kann ich sonst noch machen?

Danke.

 

[m00nraker]

BTW:

Wenn man die k3brc Dateien des jeweiligen Users löscht, legt k3b diese ja automatisch wieder an. Und irgendwo her muss k3b ja die Information über die erkannten Laufwerke bekommen. Ein Ändern der rc-Datei dürfte deshalb doch wenig Sinn machen.
Steckt das Problem dann nicht eher innerhalb von k3b? Ich schätze mal, dass k3b entweder cdrecord oder cdrdao zur Erkennung der Laufwerke benutzt. Vielleicht werden da falsche Parameter verwendet?

 

[m00nraker]

Hmm, ich wollte eigentlich keinen Monolog hier halten, sondern suche Hilfe.

Mein Problem habe ich doch beschrieben.

Wo sind denn die Spezialisten, die sich mit k3b und SCSI auskennen?? Es gibt doch bestimmt noch andere Leute hier, die auch einen echten SCSI-Brenner mit k3b benutzen.

Also wie bereits geschrieben, verwende ich Packmans k3b v0.12.15. Im Changelog von k3b 0.12.15 steht u.a. dies hier:

Use SG IO for scsi commands with newer linux kernels. This should fix problems with scsi device detection.

Wenn ich nur wüsste, ob der Fehler alleine bei k3b liegt...!?

Ich bitte nochmals um Hilfe für eine Problemlösung oder einen Workaround.

Danke.

 

[heippp]

Hatte fast das gleiche Problem.
Bei http://packman.links2linux.de/?action=219
ist inzwischen die neue Version
k3b-0.12.16-3.1.pm.0.i586.rpm
zu finden.
Zusammen mit den dort angegebenen und ev. noch anderen (bei mir z. B. faac-1.24-0.pm.3.i586.rpm, faad2-2.0-0.pm.8.i586.rpm, ffmpeg-0.4.9-6.pm.svn20060701.i586.rpm, ...), außerdem erforderlichen Binärpaketen wird mein SCSI-Brenner jetzt wieder korrekt erkannt. Ob die Brennerei tatsächlich funktioniert weiß ich noch nicht.
In diesem Zusammenhang musste ich auch das Mplayer-Paket MPlayer-1.0pre8-2.i586.rpm durch MPlayer-1.0pre8-3.i586.rpm ersetzen.

 

[m00nraker]

Hallo heippp.

Danke für die Info.

Also mein Problem ist mit der neuen k3b Version 0.12.16 endlich gelöst.

Mein Plextor wird wieder als CD-Schreiber erkannt und ich kann mit k3b CD's brennen.

Das Problem bei mir lag somit eindeutig an k3b.

BTW: Im Changelog der neuen Version steht u.a.:

Properly set the length of SCSI commands (again this fixes some device detection problems).

Gruß, Kai