> ~# ./cdrecord -toc > Cdrecord-Clone 2.01 (i586-pc-linux-gnu) .... > .... > first: 1 last 1 > track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: 1 > track:lout lba: 351369 ( 1405476) 78:06:69 adr: 1 control: 4 mode: -1 > > > However after ./cdrecord -tao ./KNOPPIX_V3.8.1-2005-04-08-EN.iso I get: > > ~# ./cdrecord -toc > Cdrecord-Clone 2.01 (i586-pc-linux-gnu) .... > .... > first: 1 last 1 > track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: 1 > track:lout lba: 351371 ( 1405484) 78:06:71 adr: 1 control: 4 mode: -1
Just ignore the 2 extra blocks exist. > ~# dd if=/dev/hdd of=some.image bs=2k skip=351367 count=4 > dd: reading `/dev/hdd': Input/output error > 1+0 records in > 1+0 records out You ought to be able to read 351369 blocks, but not more than that. Don't try to read the 2 additional blocks, they're meaningless to you. If you want to compare the iso's md5 checksum, make sure you only read 351369 blocks from the media. (I've got an md5 script in my scriptutils to do this automatically). As you see you can't even read 351369 blocks - this a long-standing Linux kernel bug. There is no fix, only a workround - when burning, burn a suitably long stream of nulls immediately following the iso image data. cdrecord -pad is meant to do this, but the amount of nulls added is insufficient to be a reliably workaround. Something like up to at least 200kb need to be added. I found that cdrecord -pad padsize=10x75s has always allowed me to read the full amount of iso blocks. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
