Bug 217979 - parted in script mode doesn't correct resized gpt disks
parted in script mode doesn't correct resized gpt disks
Status: CLOSED DUPLICATE of bug 217973
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: parted (Show other bugs)
4.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-30 19:35 EST by Magnus Hagebris
Modified: 2015-08-26 04:12 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-31 15:08:56 EDT
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 Magnus Hagebris 2006-11-30 19:35:30 EST
Description of problem: 
 
After a disk is resized; parted will show something like this: 
--------------------------------- 
# parted -s /dev/sdb print 
Error: The backup GPT table is not at the end of the disk, as it should 
be.  This might mean that another operating system believes the disk is 
smaller.  Fix, by moving the backup to the end (and removing the old 
backup)? 
Warning: Not all of the space available to /dev/sdb appears to be used, 
you can fix the GPT to use all of the space (an extra 2097152 blocks) or 
continue with the current setting? 
 
Model: HP HSV101 (scsi) 
Disk /dev/sdb: 63.4GB 
Sector size (logical/physical): 512B/512B 
Partition Table: gpt 
 
Number  Start  End    Size    File system  Name    Flags 
 1      17.4kB  1049kB  1032kB              primary 
 2      1049kB  38.7GB  38.7GB              primary  lvm 
 3      38.7GB  60.1GB  21.5GB              primary  lvm 
-------------------------------- 
 
A second run will show something like this: 
------------------------------- 
# parted -s /dev/sdb print 
Warning: Not all of the space available to /dev/sdb appears to be used, 
you can fix the GPT to use all of the space (an extra 2097152 blocks) or 
continue with the current setting? 
... 
------------------------- 
 
So obviously the first 'error' is automatically fixed, while the 2nd 
warning is repeated over and over until you do something like this: 
# parted /dev/sdb print Fix 
 
Not a big deal, but why can't this 2nd warning also be automatically 
fixed in script mode(-s)? 
 
Version-Release number of selected component (if applicable): 
'GNU Parted 1.8.0' from http://people.redhat.com/dcantrel/rhel/parted/i386/    
Ok, not official 1.6.19.EL version, but still a problem...  
 
How reproducible: 
- 
 
Steps to Reproduce: 
1.  # parted -s /dev/sdb mklabel gpt   
2.  # parted -s /dev/sdb unit MiB mkpart primary ext3 0 1000 
3.  Resize the lun and reboot your system    
3.  # parted -s /dev/sdb print 
   
Actual results: 
- 
 
Expected results: 
- 
 
Additional info: 
Not a big deal, but running parted(interactive mode) is not desired. Would be 
nice if there was a -y switch that answered yes on all questions...
Comment 1 David Cantrell 2007-08-14 17:05:16 EDT
Flagging for 4.7, problem with the -s mode.  Shouldn't be interactive.
Comment 2 David Cantrell 2007-10-31 15:08:56 EDT

*** This bug has been marked as a duplicate of 217973 ***
Comment 3 Shivanand Tendulker 2015-08-26 04:12:16 EDT
Hello

I'm hitting this issue with Fedora 22. Version of parted used in 3.2

Is this issue being fixed? And is the fix available in Fedora?

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