Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1232241 - parted -m output is bogus for a blank disk
Summary: parted -m output is bogus for a blank disk
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: parted
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Brian Lane
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2015-06-16 10:53 UTC by Richard W.M. Jones
Modified: 2015-06-16 22:59 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-16 22:59:37 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Richard 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 1 Richard 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.
Comment 3 Brian Lane 2015-06-16 22:59:37 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.