Bug 456221
| Summary: | mkisofs fails with files >4GB and returns 0 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Rainer Traut <rainer.traut> |
| Component: | cdrtools | Assignee: | Harald Hoyer <harald> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.2 | CC: | bugzilla, csewell, pknirsch, rainer.traut, rlerch, schily |
| Target Milestone: | rc | Keywords: | Rebase |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Rebase: Bug Fixes and Enhancements | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-06-02 13:09:02 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Rainer Traut
2008-07-22 10:32:00 UTC
does it work, if you create a udf filesystem instead of iso9660? or "-iso-level 3" ? No it does not work either way; specifying "-udf" or "-iso-level 3" both fail with: mkisofs: Value too large for defined data type. File file1.tar is too large - ignoring and: # echo $? 0 You are using an extremely outdated mkisofs. If you like to get support for files > 4 GB, you need a recent original mkisofs version from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ The binaries shipped by redhat create broken filesystem images for files > 4 GB. In order to get ISO-9660 support for files > 4 GB, you need to specify -iso-level 3 or more. If you specify -udf only the UDF part will contain large files. Note that mkisofs is currently able to handle files up to 8 TB in ISO-9660 and up to 128 GB in UDF. This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?". Is there any hope that RadHat will again ship the original and usable software instead of the fork in a future RedHat release? The current situation is bad as RedHat ships forked software that is full of well known bugs and the fork is unmaintained since May 6th 2007. In addition, the fork cannot be legally distributed as it is in conflict with the GPL and the Copyright law. When will RedHat again ship legal working software? *** Bug 749896 has been marked as a duplicate of this bug. *** This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. i also have lost 6 months of backups due to this issue. just installed mkisofs from cdrtools and it doesn't have this critical unfixed bug. if a file is not added to the iso, it can't exit with 0 status. can't. This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug. Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support). So your problem is that you don't have the skills to upgrade your 10 year old questionable mkisofs variant by a recent version? If this is true, then you hereby flag that RedHat delivers an unmaintained distro. Other larger distros seem to be more clever and meanwhile upgraded to the official original software instead of continuing to ship software that is known to be unmainted and full of bugs. As they say on Battlestar Galactica, "All of this has happened before, and will happen again." Bugs, forks, egos, product management and users getting the shaft. Bugzilla mails me with a weird requests to deal with this bug. This is ridiculous. What am I supposed to do if Red Hat denies to fix it? The problem you describe has been fixed in the original software in August 2006. So there is a fix since nearly 8 years and if you were on a maintained Linux distro, I would expect the fix to be integrated since at least 7.5 years. You have two opportunities: 1) use a recent unomodified original source from: https://sourceforge.net/projects/cdrtools/files/alpha/ or https://sourceforge.net/projects/cdrtools/files/ you need to compile and install the software yourself 2) switch to a linux distro that is maintained. There are more and more Linux distros that kick out the defective fork Redhat is using and return to the original software instead. You could of course try to convince Redhat to come back to the legally correct original code but given the fact that Redhat did not move since a long time, there seems to much stubborness at Redhat tp prevent a change. |