Bug 486283 - Requiring "parted /dev/sdX print" in sosreport
Summary: Requiring "parted /dev/sdX print" in sosreport
Keywords:
Status: CLOSED DUPLICATE of bug 517028
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sos
Version: 5.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Adam Stokes
QA Contact: BaseOS QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-19 07:27 UTC by Zhenyong(Jerry) Jiang
Modified: 2013-07-29 00:44 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-06 15:51:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Zhenyong(Jerry) Jiang 2009-02-19 07:27:32 UTC
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 09:00:31 UTC
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 10:33:55 UTC
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 15:15:09 UTC
Ping

Comment 7 Adam Stokes 2010-01-06 15:51:41 UTC

*** 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.