Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Epiphany/1.3.8 Description of problem: Note the package mkisofs is not listed in bz. mkisofs in some circumstances attempts to update a file in the source tree. This is impossible if the source is ro or if he user lacks permissions. The alternative, of copying up to 11 Gbytes of source is unattractive. Version-Release number of selected component (if applicable): 2.01 How reproducible: Always Steps to Reproduce: 1.Mount a FC DVD image 2.mkisofs -o EL394-dvd.iso -b isolinux/isolinux.bin -A 'EL/3.94 i386' -V 'EL/3.94 i386' -J -R -T -q -x ./lost+found -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /var/local/mirrors/linux/RHEL/3.95/i386/os 3. Actual Results: mkisofs: Read-only file system. Error opening boot image file '/var/local/mirrors/linux/RHEL/3.95/i386/os/isolinux/isolinux.bin' for update. Expected Results: No message. A 4 Gb ISO at EL394-dvd.iso Additional info: the offending open is at line 589 in eltorito.c. I suggest the file should either a) Be modified as it's copied (preferable) or b) Copied to a workfile and modified (maybe an easier workaround). I'm not admitting to an easy workaround because finding the necessary disk space and be difficult, Note that this problem also applies to fc3 and probably every other RHL and FC product, current or otherwise.
I don't believe this is a bug, for the simple fact that when passing the "-boot-info-table" option, you're instructing mkisofs to insert a boot information table into the specified boot file. So, if you instruct mkisofs to modify a file which is on a read-only filesystem, it's understandable, and desired, for it to fail. Things should work as you've described if you remove the "-boot-info-table" option from the command listed above.
How do I have this decision reviewed?
My recommendation would be that you take the source code to mkisofs, modify the way that the "-boot-info-table" option works. Possibly add another option which would copy the boot file to a temporary location, then modify it to include the boot table before including it in the ISO image. Then push these changes upstream to the mkisofs maintainers. You're other option is to not include the "-boot-info-table" option when attempting to create the ISO image. Either way, still isn't a bug, as it's working as coded.
You have a very strange idea of what constitutes a bug. Programs always work as coded. A bug is when a program does not perform to specifications. Sometimes, the specifications themselves are flawed (as in WEP) and need to be fixed. Above all, a program should perform to a reasonable user's reasonable expectations. I contend that when a program whose purpose is to transform an input to create an output, modifying that input is not a reasonable result. That's quite aside from the operational difficulties this misdesign can cause. You didn't answer my question about how to have your decision reviewed.
mkisofs is performing according to specification. Check the man page: -boot-info-table Specifies that a 56-byte table with information of the CD-ROM layout will be patched in at offset 8 in the boot file. If this option is given, the boot file is modified in the source filesystem, so make sure to make a copy if this file cannot be easily regenerated! See the EL TORITO BOOT INFO TABLE section for a description of this table. In particular "the boot file is modified in the source filesystem . . . " If your goal is to get an ISO image from the data on the DVD, then you shouldn't be using mkisofs in the first place. Instead you would just dd the contents of the DVD to a file ('dd if=/dev/dvd of=/tmp/DVD.iso bs=2048k'.) As for reviewing my decision, I did tell you. Make changes to allow for inserting the boot info table into a read-only filesystem and submit those changes upstream to the mkisofs folks. Otherwise, don't ask mkisofs to modify the boot file (i.e. don't include the '-boot-info-table' option) or use the 'dd' solution posted above.
"review your decision" means that someone else, perhaps your manager or perhaps your QA folk reexamines the issue. I think my previous post covers your response. I said somethimes the specifications themselves are wrong. I believe that's the case here. As for what I'm trying to do, that's not relevant to the question as to whether the program is performing correctly. In fact, I'm trying to create a bootable ISO with different content from any I have. See this script: ftp://people.redhat.com/ckloiber/mkdvd-rhel3u2.sh I don't ken all the different options. I do understand that modifying the inputs is undesirable. I am concerned that running it twice over the same inputs could cause irrepearable damage were it allowed to have its way. And, I'm trying to improve the quality of RHEL even though I likely will not use it.
mkisofs creates an ISO image of a given directory tree. If you indicate that you wish to change one of the files in that directory tree before creating the ISO image, then it has to be on a read-write filesystem, otherwise it's going to fail. Without digging through the source to mkisofs, I can't even tell you if it's possible to have mkisofs lookaside for a file. My point is that this is the way that mkisofs is designed to function. The quality of RHEL isn't at risk here, as there's "broken" in the way that mkisofs is performing (either functionally or spec-wise.) As best as I can tell your complaint is that if you ask mkisofs to modify a file on a read-only filesystem as part of creating the ISO image, it fails. That's not a problem. If it didn't fail, then we would have a problem. If you're worried that running this stuff twice might damage something, then either don't pass the "-boot-table-info" option or make a copy of the tree beforehand so that if something goes south, you still have a prestine copy. I reviewed my decision with the technical lead for the QA team and he agrees this isn't a bug, that mkisofs is performing to spec, and that the spec is sound.