Red Hat Bugzilla – Bug 489493
file on ppc/s390x is unable to correctly identify files created by dump
Last modified: 2012-10-31 05:21:54 EDT
Description of problem: Running file <fs-dump-file> on ppc/s390x machines gives different results than on i386/x86_64 machines. Version-Release number of selected component (if applicable): file-4.17-15 How reproducible: always Steps to Reproduce: # df | grep "/boot" /dev/dasda1 95772 51152 39676 57% /boot # dump -f /tmp/backup /dev/dasda1 DUMP: Date of this level dump: Tue Mar 10 09:25:00 2009 DUMP: Dumping /dev/dasda1 (/boot) to /tmp/backup DUMP: Label: /boot DUMP: Writing 10 Kilobyte records DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 47046 blocks. DUMP: Volume 1 started with block 1 at: Tue Mar 10 09:25:01 2009 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /tmp/backup DUMP: Volume 1 completed at: Tue Mar 10 09:25:06 2009 DUMP: Volume 1 47210 blocks (46.10MB) DUMP: Volume 1 took 0:00:05 DUMP: Volume 1 transfer rate: 9442 kB/s DUMP: 47210 blocks (46.10MB) on 1 volume(s) DUMP: finished in 5 seconds, throughput 9442 kBytes/sec DUMP: Date of this level dump: Tue Mar 10 09:25:00 2009 DUMP: Date this dump completed: Tue Mar 10 09:25:06 2009 DUMP: Average transfer rate: 9442 kB/s DUMP: DUMP IS DONE # file /tmp/backup /tmp/backup: JVT NAL sequence # echo $? 0 Actual results: non-sense Expected results: something similar to what you can see on i386/x86_64 machine # file /tmp/backup /tmp/backup: new-fs dump file (little endian), This dump Tue Mar 10 09:25:24 2009, Previous dump Wed Dec 31 19:00:00 1969, Volume 1, Level zero, type: tape header, Label /boot, Filesystem /boot, Device /dev/sda1, Host i386-5c-m2.lab.bos.redhat.com, Flags 3
# rpm -qf `which dump` dump-0.4b41-3.el5.s390x
Created attachment 334824 [details] a patch after rearranging the magic files order a bit, the dump is identified correctly
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 "?".
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.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: FS dumps generated by "dump" utility on ppc/s390x are not recognized correctly by file. Consequence: File recognizes those dump files as "JVT NAL sequence" Fix: order of magic patterns was changed to not misidentify FS dumps as "JVT NAL sequence". Result: File now identifies FS dumps in the same way as it does on other architectures (new-fs dump file).
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0201.html