Bug 486283 - Requiring "parted /dev/sdX print" in sosreport
Requiring "parted /dev/sdX print" in sosreport
Status: CLOSED DUPLICATE of bug 517028
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sos (Show other bugs)
5.5
All Linux
medium Severity medium
: rc
: ---
Assigned To: Adam Stokes
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-19 02:27 EST by Zhenyong(Jerry) Jiang
Modified: 2013-07-28 20:44 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-06 10:51:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Zhenyong(Jerry) Jiang 2009-02-19 02:27:32 EST
Description of problem:

As we know, Huge disk/LUN(>2TB) and GPT label disk is becoming normal in now days and "fdisk"  not work well with those devices.  

Current version of SOS does not print GPT partitions.

I suggest we can use parted to replace fdisk in the future sos versions.

Version-Release number of selected component (if applicable):

sos

How reproducible:

100%

Steps to Reproduce:

Current version of SOS does not print GPT partitions.

Expected results:

SOS should contain GPT partitions info of all the block disks.
Comment 2 Zhenyong(Jerry) Jiang 2009-03-12 05:00:31 EDT
Current sos does not collect GPT partition table info. It will common while huge disk (1TB or 1.5TB ) is going to affordable.
Comment 3 Bryn M. Reeves 2009-03-12 06:33:55 EDT
parted's default print output is less useful than fdisk's since everything is rounded to "friendly" units. This makes cross matching to e.g. /proc/partitions, blockdev --getsize, /sys etc. more difficult and less precise.

These tools don't have a large cost; we should collect both for the time being (upstream parted has discussed more flexible formatting options but these will not be available in RHEL5).

Also, while I realise it's not part of this patch and is in the sos version this patch was generated from, that dumpe2fs looks a little worrying. Without a "-h" the block group output can grow quite large on a large file system (~256K/100G or so). Since the detailed output is rarely useful there doesn't seem to be much point in collecting this on every run.
Comment 5 Adam Stokes 2009-09-08 11:15:09 EDT
Ping
Comment 7 Adam Stokes 2010-01-06 10:51:41 EST

*** This bug has been marked as a duplicate of bug 517028 ***

Note You need to log in before you can comment on or make changes to this bug.