Red Hat Bugzilla – Bug 123548
DVD iso images should be multiple of 32kb in size
Last modified: 2007-11-30 17:10:42 EST
Well, it's too late for FC2, but...
When burning a DVD, growisofs requires that the size of the
pre-mastered ISO be a multiple of 32kb (32,768 bytes). If the ISO is
not a multiple of 32kb, then growisofs will pad it to a multiple of
32kb when burning it. This makes it a pain to verify the MD5
signature of a successful burn; you have to use dd to read only the
size of the ISO from the DVD.
FC2 test2 was a multiple of 32kb bytes, but FC2 test3 was not, and
FC2-i386-DVD.iso is not.
While I'm grateful that FC2 has official DVD ISO images, it would be
really super if future DVD ISO images were always a multiple of 32kb
Is this specified in the red/orange/etc books somewhere?
This is what I was able to dig up:
Multiple sources (including the source for growisofs.c) all claim that
32KB is the minimum ECC block size for DVD.
Assigning to rel-eng.
I don't see an option to mkisofs to pad the .iso image properly. How
should the padding be done?
It seems that the only way to do this reliably is to create the iso, and for mkisofs to
calculate how much padding to add to make the iso live in the 32K boundaries and then
add the necessary padding. Unfortunately it doesn't appear that mkisofs can currently do
No, not at the moment.
IMO, mkisofs *should* provide a method to specify a pad size; e.g.:
I'm guessing the only reason that it doesn't is because it's only
recently that people have been using it to generate DVD ISO images.
Until that feature is added to mkisofs, it's fairly trivial to wrap
the invocation of mkisofs in a shell script that will calculate and
add the required padding. If you want an example, let me know.
I see that FC3-test1-i386-DVD.iso is 4407747329 bytes, which is pretty
far from a multiple of 32K. (In fact, 4407747329 is prime.)
Has there been any progress on this issue?
I requested mkisofs changes upstream and got the royal brushoff. This
does need to be fixed, but it's not a high priority at this point.
Bah. I don't see how upstream can justify a brushoff; it's clear that
DVD ISO files must be a multiple of 32K to satisfy the minimum ECC
blocksize. Every single document I've read (including the ones listed
Created attachment 104323 [details]
Here's something I threw together in bash to pad a DVD ISO to the next 32K
boundary. It uses only the "find" and "dd" commands.
I haven't tested this on files >2GB in size, but as long as dd doesn't choke on
large files, it should work.
I just open bug 141326. I think you are not getting the problem
correct - growisofs does not do anything about the size of the iso-
image. According to the author of growisofs ( Andy Polyakov )
the controller of the DVD recorder pads to a 32kb boundary.
So the people , who create the fedora images are responsible to
DVD isos with a correct size, otherwise a
md5sum of /dev/dvd will report a different checksum.
I agree that the person/process that creates the DVD ISO image should
pad it to a 32KB boundary, for ease of performing verifications.
But by far the easiest way to perform the padding would be for mkisofs
to provide a -pad-size (or whatever) option! After all, it's what's
creating the ISO to begin with.
It would be such a simple thing to do; I don't understand why Andy is
opposed to it.
Ah wait--I misread what you said in comment #11; I thought you were
referring to mkisofs, not growisofs.
IMHO, this isn't a growisofs issue. All growisofs is doing is writing
the provided ISO image. Andy (the growisofs author, not the mkisofs
author as I mistakenly implied in comment #12) is being reasonable
when he asserts that this isn't his problem.
The padding to arbitrary block boundaries should occur is in mkisofs,
when requested by an appropriate command-line switch. But per comment
#8, the mkisofs authors seem to disagree.
Well, this bug is going to sit here until someone convinces upstream
to make the change, so cdrtools it is. James, would you be willing to
talk directly to Joerg about this, since you understand the technical
details better than I do?
*** Bug 141326 has been marked as a duplicate of this bug. ***
*** Bug 153981 has been marked as a duplicate of this bug. ***
Can you guys give mkisofs-2.01.1-9 a try from rawhide, once it shows up there
(probably after FC4test2).
The way to invoke mkisofs would be:
mkisofs -pad -pad-size 32 -o foo.iso /path
I think there is extra junk in the .iso that doesn't get counted in the 32k
padding, at least that's my guess. If you don't like the way things work, fix 'em :)
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
Although I think having the -pad-size option for mkisofs is a good thing, upon
reflecting on some of the comments from upstream, I retract my assertion that
this is a bug.
To summarize upstream: in order to verify what you've written, never read back
more than you wrote, because the recording hardware itself may have performing
padding in (seemingly) non-deterministic ways.
This bug has 2 things to consider, the first is that independent of
mkisofs only DVD images which have a multiple of 32 kb should be
available for download including the correct md5sum/sha1sum .
The second, I suppose -pad-size is just an idea, which never will work,
because most of the people, who will use mkisofs for an DVD will forget about
the option, I think there should be really a parameter for the desired
media CD, DVD, and if new media like blueray require a different pad-size.
This media parameter should set automatically the correct "pad-size".