Bug 140956 - mkisofs tries to update souce tree
Summary: mkisofs tries to update souce tree
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: cdrtools   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Harald Hoyer
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-26 23:09 UTC by John Summerfield
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-28 13:32:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description John Summerfield 2004-11-26 23:09:35 UTC
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

The alternative, of copying up to 11 Gbytes of source is unattractive.

Version-Release number of selected component (if applicable):

How reproducible:

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

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

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)
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.

Comment 1 Jay Turner 2004-11-27 20:21:45 UTC
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.

Comment 2 John Summerfield 2004-11-28 02:05:06 UTC
How do I have this decision reviewed?

Comment 3 Jay Turner 2004-11-28 11:08:10 UTC
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.

Comment 4 John Summerfield 2004-11-28 11:44:33 UTC
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.

Comment 5 Jay Turner 2004-11-28 12:02:53 UTC
mkisofs is performing according to specification.  Check the man page:

              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.

Comment 6 John Summerfield 2004-11-28 13:01:32 UTC
"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:

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.

Comment 7 Jay Turner 2004-11-28 13:32:12 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.