On Monday 01 December 2008, D. Hugh Redelmeier wrote:
| From: Gene Heskett <gene.heskett(a)verizon.net>
|
| [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.