Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When using BACKUP_URL=iso:///backup and ISO generator is mkisofs or genisoimage (RHEL case), include the udf module and enable creating an hybrid iso9660/udf DVD.
This is necessary if the backup archive is >= 4GiB, otherwise the following error occurs:
File ./backup/backup.tar.gz is larger than 4GiB-1.
-allow-limited-size was not specified. There is no way do represent this file size. Aborting.
xorrisofs has not the issue, but since we do not ship xorrisofs, this needs to be fixed.
Version-Release number of selected component (if applicable):
rear-2.4-2.el7
How reproducible:
Always
Steps to Reproduce:
1. Set up rear to embed backup in ISO
# cat /etc/rear/site.conf
BACKUP=NETFS
BACKUP_URL="iso:///backup"
OUTPUT_URL=null
ISO_DIR="/home/rmetrich/rear"
2. Create a big file to make sure resulting backup is larger than 4GB
# dd if=/dev/urandom of=/root/3.2G count=3276 bs=1M
3. Backup the system
# rear mkbackup
Actual results:
genisoimage 1.1.11 (Linux)
Scanning .
Scanning ./backup
File ./backup/backup.tar.gz is larger than 4GiB-1.
-allow-limited-size was not specified. There is no way do represent this file size. Aborting.
2018-11-30 16:04:57.267620909 ERROR: Could not create ISO image (with /bin/mkisofs)
==== Stack trace ====
Trace 0: /usr/sbin/rear:543 main
Trace 1: /usr/share/rear/lib/mkbackup-workflow.sh:22 WORKFLOW_mkbackup
Trace 2: /usr/share/rear/lib/framework-functions.sh:101 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:49 Source
Trace 4: /usr/share/rear/output/ISO/Linux-i386/820_create_iso_image.sh:28 source
Trace 5: /usr/share/rear/lib/_input-output-functions.sh:371 StopIfError
Message: Could not create ISO image (with /bin/mkisofs)
== End stack trace ==
Expected results:
No error
Additional info:
GitHub PR: https://github.com/rear/rear/pull/1992
(In reply to Renaud Métrich from comment #0)
> xorrisofs has not the issue, but since we do not ship xorrisofs, this needs
> to be fixed.
We intend to ship xorrisofs, see bz1462189, bz1638857.
Will it still be a problem when we fix bz1655956 by adding xorriso (bz1638857)? I would prefer not having two fixes for the same problem to reduce the amount of testing needed.
The actual problem (files in ISO images larger than 4 GB, bz1462189) was fixed by including xorriso (bz1638857) and moreover after including xorriso the fix proposed here will not work anyway, as xorriso does not have the required option (-allow-limited-size, it does not even have -udf).