On Wed, 2 Apr 2008 20:55:46 -0400, Tom Horsley wrote:
> > I usually use that option. I noticed that it didn't
work for the last CD
> > I burned - SysRescCD/Clonezilla 2.4.0. I burned 3 copies and all 3 gave
> > me the md5 error. I assumed there was something about the CD image, but
> > it's possible this feature is broken...
>
> I installed an older kernel to prove my theory: 2.6.23.15-137.fc8
> Located via bodhi and koji, and the highest one not 2.6.24*.
>
> With it, k3b verifies written data fine.
I bet this is one of those gray areas where everyone can blame each other.
I've noticed a distinct tendency for ISO images to be produced with
a header that says the ISO is so big, but the file is actually smaller
than the header implies. For instance, here is some of the output
from an isoinfo dump of an ubuntu iso file:
zooty> isoinfo -d -i ubuntu-7.10-alternate-amd64.iso
...
Logical block size is: 2048
Volume size is: 355219
...
So that says the file should be 355219*2048 bytes big == 727488512
In fact, this ISO is that big, but I have encountered ISO files
that were smaller, and when I've dd'ed /dev/zero onto the end
to make up the size difference, I've been able to write & verify them
fine in k3b.
That being the case, this seems like something k3b could do, so
maybe it could be categorized as a k3b bug?
? What is your theory if the ISO size is valid?
?? And a k3b bug, but still dependent on the Linux kernel version?
Why does it work fine with Linux < 2.6.24?
I have never before had problems with verifying/reading ISO images from
CDs/DVDs. I burn them in DAO (SAO) mode. With the same and other similarly
reliable hardware I have never had to play with padding to work around
run-out sectors at the end.