On Monday 01 December 2008, D. Hugh Redelmeier wrote: >| From: Gene Heskett <gene.heskett@xxxxxxxxxxx> >| >| [root@coyote Fedora-10-i386-DVD]# dd if=/dev/sr0|sha1sum -c SHA1SUM >| Fedora-10-i386-DVD.iso: OK > >[Spaces around the pipe symbol would help readability. Partly because >at least some fonts don't make that glyph very distinct.] > >I don't think that that pipeline did what you think that did. > >The dd command piped the raw disk contents to sha1sum (as you expect). > >The sha1sum command ignored its standard input and checked .iso files >named within the SHA1SUM file (surprise!). > >The current working directory had those .iso files. Try the same >pipeline from within another directory and you will see what I'm >talking about. > >So your disk was not checked. > >But there is a better way to verify: just do a cmp between the raw >disk and the .iso file. > >Why is this better? Because you can tell cmp how many bytes to read >from the raw disk. Remember, the raw disk read may appear to have >more bytes than the .iso, and those bytes should be ignored: EOF is >not well defined on a raw disk. This could also trip up k3b >(speculation on my part). > >I use a script called "isoburn" for this stuff. There are two >relevant features of this script: > >- when burning, it pads the file. Otherwise, on some drives, the > kernel will generate read errors when a program tries to read near > the end of the burned part (the kernel does a read-ahead past the > end and gets upset when the drive gives an error). > >- when verifying, it does a cmp with the actual proper length filled > in. This uses a feature of GNU cmp not documented in the man page. > Damn GNU's contempt for man pages. > >Here, in essence, is how the verify works (replace file.iso with the >pathname of the .iso file): > cmp --bytes `isosize file.iso` file.iso /dev/sr0 I'd forgotten to divide the size of the iso by 2048 to get the number of blocks dd should read. If left to its own devices it reads 2 too many and the sum is wrong. Doing it this way, the sum is correct on both disks I've now burnt: [root@coyote misc]# dd if=/dev/sr0 bs=2048 count=1788366 | sha1sum 1788366+0 records in 1788366+0 records out 3662573568 bytes (3.7 GB) copied, 252.066 s, 14.5 MB/s 086fd570518ac58d3966c43c1b6d146e38919d8d - >From the SHA1SUM file: 086fd570518ac58d3966c43c1b6d146e38919d8d *Fedora-10-i386-DVD.iso >From the second disk: [root@coyote misc]# dd if=/dev/sr0 bs=2048 count=1788366 | sha1sum 1788366+0 records in 1788366+0 records out 086fd570518ac58d3966c43c1b6d146e38919d8d - 3662573568 bytes (3.7 GB) copied, 246.414 s, 14.9 MB/s So they all match. An FU8 dvd boots, an FU9 dvd boots (its installed now), a Ubuntu-8.04 cd boots, but these F10-i386-DVD dvd's are ignored, no change in the bios settings. Is iso-linux linked wrong or what? >| So once again all the other excuses, having been removed from the scene, >| are proven to just excuses, k3b needs fixed. And it should be using >| sha1sum too. Which I will keep hammering on till it does work again, it did once, early in its history. k3b worked fine when I was running Fedora 2. But it hasn't worked since. >I never use k3b's verify anyway. I'm too impatient to let it complete >the calculation of the hash of the .iso file. k3b seems to forget >that the hash is wrong (not completely calculated) and thus the >subsequent verification is reported as failing rather than being >impossible to perform. Apparently the authors don't use it either.. Sad. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Your own qualities will help prevent your advancement in the world. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
