[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: has K3B been abandoned?



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]