[Mdk 10.1 / kernel 2.6.8]
 
Il m'est impossible de graver des CD multisessions.
Que ce soit avec k3b ou en ligne de commande, je parviens à graver et à lire la 1ère session, mais après il est impossible de même récupérer les infos la concernant. K3b donne une erreur (disque plein ou non-multisession) et cdrecord donne le message suivant :
 
Cdrecord-Clone 2.01-dvd (i686-pc-linux-gnu)
$ cdrecord -msinfo dev=ATA:1,0,0
Error trying to open /dev/hdc exclusively (Device or resource busy)
 
Est-ce que la gestion des graveurs IDE/ATAPI est en cause ? Je n'avais aucun problème auparavant avec l'émulation SCSI sous kernel 2.4.
Est-il possible de revenir à l'émulation SCSI sous 2.6 ? Ou bien y a-t-il une autre solution ?
 
PS. Tout fonctionne correctement sous XP avec Nero. Cela me ferait ch... de devoir graver mes sauvegardes linux sous m$...

L'émulation SCSI sous 2.6 est cassée et ne sert plus à rien.
Essayer autre chose que cdrecord ?

D'accord, mais quoi ?
Ou bien est-ce que je suis le seul à rencontrer ce problème ?

 
Non, non tu n'es pas seul    
 
Depuis le passage vers des noyaux 2.6.x je dois dire qu'avec cdrecord c'est la zone lorsqu'on a un graveur IDE... A chaque fois des problèmes différents selon la version du noyau et le frontend employé (XCD-Roast, K3B, GCombust, etc) : échec dès le début de la création du CD, problèmes de droits d'accès, CD "créés avec succès" illisibles, plantage juste à la fin de la gravure, etc, etc, etc    . J'ai fais d'autres essais avec mon ancien graveur SCSI et aucun souci... Actuellement le seul point faible de GNU/Linux est, à mes yeux, la gravure.
 
Il y a une option packet writing dans le noyau 2.6.10 mais c'est insuffisant pour remplacer un soft de gravure ; sinon ya aussi libburn, d'ailleurs je crois que je vais finir par jeter un oeil de ce côté-là.

Merci pour tes explications.
En effet, c'est un sacré point faible !
Je ne comprends pas pourquoi l'émulation scsi, qui marchait très bien, a été abandonnée.

Ca fonctionnait bien certes, mais pour gérer des périphs IDE c'est à présent totalement dépassé. L'évolution constante du noyau GNU/Linux veut cela : pour les développeurs, il n'est pas question de simplement rester figé dans une optique "qui marche bien" ; il est question d'aller vers des solutions encore et toujours plus efficaces que les précédentes.
 
Cela peut paraître bizarre de dire cela au vu des problèmes actuellement rencontrés   , mais si l'on regarde de plus près, on se rend rapidement compte qu'accéder directement à son périph de gravure via /dev/hdX est plus simple/fonctionnel et performant, que de passer par un module qui va réinterprêter les commandes avant de les transmettre au périph.
 
Le problème, c'est lorsqu'on se trouve en phase de transitoire : il est toujours difficile d'évoluer radicalement vers une nouvelle technologie sans que cela engendre des problèmes avec celle en place (il y a de nombreux exemple, citons aussi le cas devfs/udev). Le problème se complexifie encore un peu plus quand certains développeurs/mainteneurs y mettent de la mauvaise volonté (Joerg Schilling -le responsable cdrecord et consorts- n'est pas innocent dans cette histoire).
 
Bref, pour le moment c'est un peu le bordel, il y a de quoi râler un peu, mais avec le temps une fois ce passage effectué, tout le monde sera content de profiter de la nouvelle méthode  

J'ai découvert par hasard une info intéressante au fin fond de google :
Avec un kernel 2.6, cdrecord ne peut déliver les données -msinfo que si l'on est root. C'est sans doute la raison pour laquelle k3b (en tant que user) échoue.
 
J'ai réussi à graver et relire deux sessions en ligne de commande en étant root.
C'est un peu pénible mais c'est déjà quelque chose.

http://qa.mandrakesoft.com/show_bug.cgi?id=12822