VMware Cloud Community
Bruce_Ferjulian
Enthusiast
Enthusiast
Jump to solution

partedUtil fixGpt Utility fails with ( Error: Read-only file system during write )

A Vsphere7.3 system is running on a Dell PowerEdge R760.

The system started with a four (4) member raid5 virtual volume. Two (2) additional drives were added to the raid5 virtual volume increasing it's size. The datastore before the new free space is failing grow into the added capacity using the GUI.

expand_01.png

expand_02.png

There seems to be an inconsistency in the GPT table not taking into account the extra space. I have tried to fix the GPT table but get the following error.

 

 

partedUtil fixGpt "/vmfs/devices/disks/naa.6f4ee08061ff44006559e24b04b47edb"

FixGpt tries to fix any problems detected in GPT table.
Please ensure that you don't run this on any RDM (Raw Device Mapping) disk.
Are you sure you want to continue (Y/N): y
Error: The primary GPT table on '/dev/disks/naa.6f4ee08061ff44006559e24b04b47edb' is OK, but secondary is corrupt. Fix secondary table? This will move secondary at the end in case it is not at the end already. It will also set LastUsableLBA to use all the space at the end. diskSize (2343403520) AlternateLBA (1406042111) LastUsableLBA (1406042106)
Fix/Ignore/Cancel? FIX
Error: Read-only file system during write on /dev/disks/naa.6f4ee08061ff44006559e24b04b47edb

 

 

I also tried to use the grow option with no success.

First I probed the partition able.

 

partedUtil getptbl "/vmfs/devices/disks/naa.6f4ee08061ff44006559e24b04b47edb"
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/disks/naa.6f4ee08061ff44006559e24b04b47edb appears to be used, you can fix the GPT to use all of the space (an extra 937361408 blocks) or continue with the current setting? This will also move the backup table at the end if is is not at the end already. diskSize (2343403520) AlternateLBA (1406042111) LastUsableLBA (1406042106) NewLastUsableLBA (2343403514)
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/disks/naa.6f4ee08061ff44006559e24b04b47edb appears to be used, you can fix the GPT to use all of the space (an extra 937361408 blocks) or continue with the current setting? This will also move the backup table at the end if is is not at the end already. diskSize (2343403520) AlternateLBA (1406042111) LastUsableLBA (1406042106) NewLastUsableLBA (2343403514)
gpt
145870 255 63 18747228160
1 64 204863 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 208896 8595455 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 8597504 16984063 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 16986112 268435455 4EB2EA3978554790A79EFAE495E21F8D vmfsl 0
8 268437504 11248336855 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

 

 

partedUtil getUsableSectors "/vmfs/devices/disks/naa.6f4ee08061ff44006559e24b04b47edb"
Error: The primary GPT table on '/dev/disks/naa.6f4ee08061ff44006559e24b04b47edb' is OK, but secondary is corrupt. Fix secondary table? This will move secondary at the end in case it is not at the end already. It will also set LastUsableLBA to use all the space at the end. diskSize (2343403520) AlternateLBA (1406042111) LastUsableLBA (1406042106)

 

 

partedUtil resize "/vmfs/devices/disks/naa.6f4ee08061ff44006559e24b04b47edb" 8 268437504 2343403514
Error: The primary GPT table on '/dev/disks/naa.6f4ee08061ff44006559e24b04b47edb' is OK, but secondary is corrupt. Fix secondary table? This will move secondary at the end in case it is not at the end already. It will also set LastUsableLBA to use all the space at the end. diskSize (2343403520) AlternateLBA (1406042111) LastUsableLBA (1406042106)
Warning: Not all of the space available to /dev/disks/naa.6f4ee08061ff44006559e24b04b47edb appears to be used, you can fix the GPT to use all of the space (an extra 937361408 blocks) or continue with the current setting? This will also move the backup table at the end if is is not at the end already. diskSize (2343403520) AlternateLBA (1406042111) LastUsableLBA (1406042106) NewLastUsableLBA (2343403514)
Error: Read-only file system during write on /dev/disks/naa.6f4ee08061ff44006559e24b04b47edb

 

I should not have to boot a liveCD to fix the GPT partition table. Have I overlooked something simple or can't VMWARE grow a physical volume then expand a datastore?

 

 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Bruce_Ferjulian
Enthusiast
Enthusiast
Jump to solution

SUMMARY: VMware is ok using a new empty volume to create an ( ADDITIONAL DATASTORE ) but poor at growing the size of DATASTORE that was created during the initial install.

 

Trying to expand the default DATASTORE was a total fail.

 

This is a corner case where there does not seem to be a native solution to expand the volume where VSphere was initially installed. When you do your initial install the default behavior is to lay down the base ESX in the first few partitions then use the remainder for the base DATASTORE. If you increase the underlying capacity where you installed there is no way to expand into the new unused space.

 

Since the layout is based on GPT, the backup copy of the label is now before beginning of the newly created space and not where it's supposed to be at the end of the volume. After hours of searching for a solution I finally tried to use a booted live CD to fix the GPT layout but I could not move the DATASTORE size to use the new layout and kept getting a READ_ONLY error.

 

Finally gave up and re-installed the whole thing on the new larger RAID5 volume. 

 

 

View solution in original post

0 Kudos
1 Reply
Bruce_Ferjulian
Enthusiast
Enthusiast
Jump to solution

SUMMARY: VMware is ok using a new empty volume to create an ( ADDITIONAL DATASTORE ) but poor at growing the size of DATASTORE that was created during the initial install.

 

Trying to expand the default DATASTORE was a total fail.

 

This is a corner case where there does not seem to be a native solution to expand the volume where VSphere was initially installed. When you do your initial install the default behavior is to lay down the base ESX in the first few partitions then use the remainder for the base DATASTORE. If you increase the underlying capacity where you installed there is no way to expand into the new unused space.

 

Since the layout is based on GPT, the backup copy of the label is now before beginning of the newly created space and not where it's supposed to be at the end of the volume. After hours of searching for a solution I finally tried to use a booted live CD to fix the GPT layout but I could not move the DATASTORE size to use the new layout and kept getting a READ_ONLY error.

 

Finally gave up and re-installed the whole thing on the new larger RAID5 volume. 

 

 

0 Kudos