dd kopiert nicht das gleiche seit 9.0

R

ruiin

Well-Known Member
Hi,

wie unter 8.2 habe ich auch auf 9.0 versucht ein script mit python zu bauen das mir eine cd als .iso auf die Platte zieht. Doch seit 9.0 bekomme ich nur noch solchen output:

Code: 
$ ./dd.py
dd: /dev/cd0: Input/output error
304+0 records in
304+0 records out
622592 bytes transferred in 2.800668 secs (222301 bytes/sec)
1
Dabei liegt die Änderung in FreeBSD bei dem Wechsel von /dev/acd0 nach /dev/cd0 und hardwaretechnisch hab ich einfach das Laufwerk gewechselt und bin mir nicht ganz sicher ob es am Laufwerk liegt.

dd wird folgendermaßen ausgeführt:
Code: 
dd if=/dev/cd0 of=/pfad/zum/ziel.iso bs=2048
Der User ist in der Gruppe operator.

Die /var/run/dmesg.boot sagt:
Code: 
cd0 at ata2 bus 0 scbus2 target 1 lun 0
cd0: <_NEC DVD_RW ND-3530A 1.80> Removable CD-ROM SCSI-0 device 
cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present
uhub2: 4 ports with 4 removable, self powered
 
also ich kann es mal mit einer CD versuchen, bei der ich mir sicher sein kann das die nicht kaputt ist. Hat sich was bei dd seit 8.2 getan?

/EDIT: Also mit einer anderen CD scheint es zu funktionieren, dd ist noch nicht abgeschlossen. Doch meine Frage bleibt, wurde dd upgedatet ? Kann man evtl. die alte version noch mal nachbaun?
 
Hab das Problem identifizieren können.

Wollte überflüssige Hardware ausbauen, deswegen habe ich das einfache CD-Laufwerd ausgebaut und wollte alles nur noch über das CD-RW-Laufwerk machen. Dieses scheint aber nicht so optimal mit dd zusammen zu spielen. Ich bin kein Hardwarefachmann und hab deswegen keine Ahnung warum, aber mit dem alten CD-Laufwerk funktioniert wieder alles.
 
vielleicht mag es auch einfach nur die blockgroesse von 2048 nicht? hast du es schon mit groesseren/kleineren block sizes probiert?
was ist wenn du mit seek und skip arbeitest?
 
Nein, eine CD muss immer 2048 sein. Sonst geht gar nichts...

Zu dem Laufwerk: Neue CD/DVD-Laufwerke taugen nichts mehr, neigen zu vielen Lesenfehlern aufgrund schlechter Mechanik, haben eine miese Fehlerkorrektur und entsprechende Probleme mit nicht ganz korrekten Medien. Verschwörungstheoretiker meinen, es sei nach Intervention der Musikindustrie extra eingebaut worden, um das Auslesen von CDs zu erschweren. Tatsächlich rippen moderne Laufwerke CDs wesentlich langsamer als 10 Jahre alte Modelle.
 
hab ich probiert:
Wenn ich mit dd auf bs=2048 arbeite, bricht er nach dem 304 Block ab.
Wenn ich diese 304 Blöcke mit iseek=304 bzw. 305 maskiere bekomm ich keinen output.
Wenn ich auf kleinen Blockgrößen arbeite bekomm ich ebenfalls keinen output und bei Größeren werden die 304 Blöcke nur je nach Multiplikator umgerechnet.

/EDIT: Dann glaub ich mal den Verschwörungstheoretikern und nutze einfach das alte Philipps Laufwerk weiter.
 
ich glaub es wird zeit das ich ersatzteile auf der müllkippe suche, wenn kein neues laufwerk so funktioniert. bs=512 funktioniert auch nicht ;)
 
Versuche mal 'recoverdisk', aus der manpage:

Code: 
# read an ISO image from a CD-ROM
touch /data/cd.iso; recoverdisk /dev/acd0 /data/cd.iso
 
Yamagi schrieb:
Nein, eine CD muss immer 2048 sein. Sonst geht gar nichts...

Zu dem Laufwerk: Neue CD/DVD-Laufwerke taugen nichts mehr, neigen zu vielen Lesenfehlern aufgrund schlechter Mechanik, haben eine miese Fehlerkorrektur und entsprechende Probleme mit nicht ganz korrekten Medien. Verschwörungstheoretiker meinen, es sei nach Intervention der Musikindustrie extra eingebaut worden, um das Auslesen von CDs zu erschweren. Tatsächlich rippen moderne Laufwerke CDs wesentlich langsamer als 10 Jahre alte Modelle.
Zum Vergrößern anklicken....

erinnert mich an mein Toshiba SDM 1612 (arbeitet immer noch), welches ich mit einer inoffiziellen Firmware http://hijacker.rpc1.org/toshiba_nolimit/ auf volle Leistung freischalten konnte.
 
Ich lasse bei mir die Drossel immer drin. Mich nervt das Gerödel der Laufwerke auf vollen Touren.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben