has K3B been abandoned?
Gene Heskett
gene.heskett at verizon.net
Mon Dec 1 10:21:39 UTC 2008
On Monday 01 December 2008, D. Hugh Redelmeier wrote:
>| From: Gene Heskett <gene.heskett at verizon.net>
>|
>| [root at 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 at 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 at 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.
More information about the fedora-list
mailing list