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.
