Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 489493

Summary: file on ppc/s390x is unable to correctly identify files created by dump
Product: Red Hat Enterprise Linux 5 Reporter: Milos Malik <mmalik>
Component: fileAssignee: Jan Kaluža <jkaluza>
Status: CLOSED ERRATA QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: ksrot, ovasik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: file-4.17-17 Doc Type: Bug Fix
Doc Text:
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).
 Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-21 05:45:37 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:
Attachments:
Description Flags
a patch none

Description Milos Malik 2009-03-10 13:40:22 UTC 
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
Comment 1 Milos Malik 2009-03-10 13:46:40 UTC 
# rpm -qf `which dump`
dump-0.4b41-3.el5.s390x
Comment 2 Daniel Novotny 2009-03-11 15:38:55 UTC 
Created attachment 334824 [details]
a patch

after rearranging the magic files order a bit, the dump is identified correctly
Comment 3 RHEL Program Management 2009-03-26 17:22:42 UTC 
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 "?".
Comment 8 RHEL Program Management 2010-08-09 18:46:39 UTC 
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.
Comment 10 RHEL Program Management 2011-05-31 13:55:44 UTC 
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.
Comment 15 Jan Kaluža 2012-01-05 09:22:23 UTC 
    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).
Comment 16 errata-xmlrpc 2012-02-21 05:45:37 UTC 
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