Hide Forgot
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 in size. See: http://www.redhat.com/archives/fedora-test-list/2004-April/msg03118.html
Is this specified in the red/orange/etc books somewhere?
This is what I was able to dig up: http://www.brouhaha.com/~eric/video/dvd/#specs http://www.dvdrw.com/information/DVDRW_Physical_Format_Explanation.pdf http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-267.pdf 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 this.
No, not at the moment. IMO, mkisofs *should* provide a method to specify a pad size; e.g.: -pad-size 32k 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 above) agree.
Created attachment 104323 [details] pad-dvd-iso 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.
Hi, 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. Winfrid
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. Thank you!
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.
Hi, 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". Winfrid