On 12/18/06, Dmitry Rutsky <[EMAIL PROTECTED]> wrote:
It turns out that I'd overlooked relevant sections in the documentation
("Linux Notes" in Chapter 4) and there is (or at least was) a way to use ATAPI
interface. Still it doesn't work for me, and
What happens when you execute this?
cdrecord -scanbus dev=ATAPI
On my sarge system (using cdrecord, not wodim), this gives back the cd
writer as one of the devices. Then, I configure Cedar Backup to use
ATAPI:1,0,0 (or whatever) and it works. I gather that on your system
using wodim, scanbus doesn't find anything?
If that's true, I agree -- it's either a bug or a regression in wodim
(perhaps that functionality was added after the point wodim was forked
from).
[snip]
Consider the following as well: if there is more than one recorders on the
system, it's perfectly clear which one you're referring to when you pass
dev=/dev/cdrw where /dev/cdrw points to correct recorder device,
rather than mysterious dev=ATAPI:0,1,0 for example.
The first way makes much more sense.
If it works, yes, I agree that specifying the device is much less
ambiguous. Cedar Backup should support that syntax somehow.
In an odd coincidence, someone else wrote the Cedar Backup user
mailing list today with the same problem. So, that forces my hand and
I'll have to make a decision soon about how I'll fix it.
> What kernel are you using -- a stock Debian one, or one you built
> yourself? If it's a stock Debian 2.6 kernel, that's great, because I
> should be able to reproduce your situation and do direct testing.
I use a custom-built kernel. Tell me if you want the complete config
for it or just relevant options and I'll send it to you.
It may not matter. I recently transplanted my DVD writer into a
different maching running etch (rather than sarge). If the problem is
wodim-related, I should be able to reproduce it on that box. Even if
I can't reproduce the problem, as long as I can test that passing
dev=/dev/cdrw works properly with wodim, this should be good enough.
> Incidentally, the regression tests are likely failing now because
> you've caused a fundamental assumption to be broken, i.e. that every
> configuration has a SCSI device associated with it. Any changes like
> this ripple through the regression test suite, which is exactly what I
> want to happen. :)
I also had broken the code --- if you set scsi_id tag it'll fail.
I'm just not accustomed to interpreted languages. The following
additional patch should make it work the way it did when the tag is present
(though I didn't test it), and it reduces the number of failed unittests to only
about a dozen.
Ok, thanks.
KEN
--
Kenneth J. Pronovici <[EMAIL PROTECTED]>
http://www.cedar-solutions.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
