Referring back to the many threads on CD's failing to burn...
But posting with a new topic to make more ('important') people to notice
this and actually maybe read through it and take action (it's one
trivial line for goodness sake).
Actually, the problem isn't with padding in mkisofs - whether it's enable
in mkisofs or not doesn't actually make a difference - because the md5sum
of the file which is burned into the beginning sectors is calculated from
the whole file mkisofs creates (ie. if mkisofs includes padding then this
padding will be included in the md5sum that anaconda creates and thus this
padding will need to be readable in order for mediacheck to pass). What
needs to be done is padding needs to be added _after_ the anaconda
mediacheck md5sum is calculated and added into the image. This can be
done in two ways:
1) run mkisofs
run anaconda-md5sum-implantation
append 30-300KB worth of zeroes to the image
md5sum the image and distribute it
burn image with cdrecord with or without padding (doesn't matter)
this way the distributed image has padding at the end which isn't included
in the mediacheck checksum, but the padding is included in the md5sum
which is distributed alongside the file (so the file will pass both
mediacheck after burning even if the last few KB is unreadable, and will
pass manual md5sum before burning)
2) run mkisofs
run anaconda-md5sum-implantation
md5sum the image and distribute it
burn image with cdrecord with padding
this is the current way it is done - on bad burners (yes, it _is_ a
hardware issue, but it is a _very_ common hardware issue) this works since
the padding is done by cdrecord. Unfortunately cdrecord doesn't pad by
default and hence what you normally get is:
3) run mkisofs
run anaconda-md5sum-implantation
md5sum the image and distribute it
burn image with cdrecord (default of no padding)
which often fails mediacheck since the last 30KB or so might come out
unreadable, and even though they are only padding (from the default 300KB
padding of mkisofs) they are still included in the mediacheck checksum,
and thus being unable to read this padding causes mediacheck to fail (the
CD will likely work though it'll fail mediacheck...)
Now situation (3) is what we have.
Situation (2) is the current solution to get good mediacheck passing
iso's. But it requires all users burning CD's to remember to pad in
cdrecord.
It would be better for this to be done once by the image creator - ie.
situation (1).
There are actually a few other solutions:
a) the best IMHO - is situation (1) - repad after md5sum implantation
b) modify cdrecord to burn with pad by default (will take _a long_ time to
spread into the wild)))
c) modify anaconda mediacheck to skip the zeroed out sectors at the end
(effectively calculating the md5sum of only the part of the iso before
padding) - but this is a little dangerous (there might be zeroes out
sectors before the padding which actually have meaning)
Option (a) can be performed immediately by just adding a single line
(dd if=/dev/zero bs=2048 count=150 >> file.iso) to the scripts used to
create the iso/dvd images right after the anaconda implantation.
Option (b) is nice and should probably be done anyway (making -pad
cdrecord option the default) but will take ages to spread and in the
meantime cd burning problems will continue to plague us.
Option (c) is also nice and should possibly be done, once we figure out
how to determine how much padding the file contains (or just assume it's
always 300KB since that's how much mkisofs adds?)
Still, option (a) is best for now at least and would solve this problem
once and for all.
Cheers,
MaZe.
