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.
DescriptionRichard W.M. Jones
2015-06-16 10:53:05 UTC
Description of problem:
According to the man page:
-m, --machine
displays machine parseable output
Sounds good, unfortunately:
$ truncate -s 1G /tmp/blank.img
$ parted -m -- /tmp/blank.img unit b print 2>/dev/null | hexdump -C
00000000 0d 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |. |
00000010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
*
00000040 20 20 20 20 20 20 20 20 20 20 20 0d 42 59 54 3b | .BYT;|
00000050 0a 2f 74 6d 70 2f 62 6c 61 6e 6b 2e 69 6d 67 3a |./tmp/blank.img:|
00000060 31 30 37 33 37 34 31 38 32 34 42 3a 66 69 6c 65 |1073741824B:file|
00000070 3a 35 31 32 3a 35 31 32 3a 75 6e 6b 6e 6f 77 6e |:512:512:unknown|
00000080 3a 3a 3b 0a |::;.|
Printing ^M and lots of spaces is not "machine readable".
The output is slightly different on RHEL 7, leading me to believe
that it's dumping out the contents of an internal buffer:
00000000 1b 5b 3f 31 30 33 34 68 0d 20 20 20 20 20 20 20 |.[?1034h. |
00000010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
*
00000050 20 20 20 0d 42 59 54 3b 0a 2f 74 6d 70 2f 62 6c | .BYT;./tmp/bl|
00000060 61 6e 6b 2e 69 6d 67 3a 31 30 37 33 37 34 31 38 |ank.img:10737418|
00000070 32 34 42 3a 66 69 6c 65 3a 35 31 32 3a 35 31 32 |24B:file:512:512|
00000080 3a 75 6e 6b 6e 6f 77 6e 3a 3a 3b 0a |:unknown::;.|
0000008c
Version-Release number of selected component (if applicable):
parted-3.1-20.el7.x86_64
How reproducible:
100%
Steps to Reproduce:
1. See description above.
Expected results:
BYT; should be the first line of the output.
Comment 1Richard W.M. Jones
2015-06-16 10:54:03 UTC
Also note the return code is 0 (ie. "no error"). Even though
the full output shows there is an error. So that's another bug.
Also the upstream parted bug tracker is broken.
You need to pass -s for script mode to suppress the spaces. And I think you are mistaking the return code from hexdump for that of parted, it does return 1 on an unrecognized disk label.
$ parted -m -s ./blank.img u b p 2>/dev/null
BYT;
/home/bcl/tmp/blank.img:1073741824B:file:512:512:unknown::;
$ echo $?
1
$ parted -m -s ./blank.img u b p 2>/dev/null | hexdump -C
00000000 42 59 54 3b 0a 2f 68 6f 6d 65 2f 62 63 6c 2f 74 |BYT;./home/bcl/t|
00000010 6d 70 2f 62 6c 61 6e 6b 2e 69 6d 67 3a 31 30 37 |mp/blank.img:107|
00000020 33 37 34 31 38 32 34 42 3a 66 69 6c 65 3a 35 31 |3741824B:file:51|
00000030 32 3a 35 31 32 3a 75 6e 6b 6e 6f 77 6e 3a 3a 3b |2:512:unknown::;|
00000040 0a |.|
00000041
Description of problem: According to the man page: -m, --machine displays machine parseable output Sounds good, unfortunately: $ truncate -s 1G /tmp/blank.img $ parted -m -- /tmp/blank.img unit b print 2>/dev/null | hexdump -C 00000000 0d 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |. | 00000010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | * 00000040 20 20 20 20 20 20 20 20 20 20 20 0d 42 59 54 3b | .BYT;| 00000050 0a 2f 74 6d 70 2f 62 6c 61 6e 6b 2e 69 6d 67 3a |./tmp/blank.img:| 00000060 31 30 37 33 37 34 31 38 32 34 42 3a 66 69 6c 65 |1073741824B:file| 00000070 3a 35 31 32 3a 35 31 32 3a 75 6e 6b 6e 6f 77 6e |:512:512:unknown| 00000080 3a 3a 3b 0a |::;.| Printing ^M and lots of spaces is not "machine readable". The output is slightly different on RHEL 7, leading me to believe that it's dumping out the contents of an internal buffer: 00000000 1b 5b 3f 31 30 33 34 68 0d 20 20 20 20 20 20 20 |.[?1034h. | 00000010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | * 00000050 20 20 20 0d 42 59 54 3b 0a 2f 74 6d 70 2f 62 6c | .BYT;./tmp/bl| 00000060 61 6e 6b 2e 69 6d 67 3a 31 30 37 33 37 34 31 38 |ank.img:10737418| 00000070 32 34 42 3a 66 69 6c 65 3a 35 31 32 3a 35 31 32 |24B:file:512:512| 00000080 3a 75 6e 6b 6e 6f 77 6e 3a 3a 3b 0a |:unknown::;.| 0000008c Version-Release number of selected component (if applicable): parted-3.1-20.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. See description above. Expected results: BYT; should be the first line of the output.