1 (edited by sublime167 2017-04-21 00:57:01)

Topic: Error resizing EXT4 partition [SOLVED]

I'm having trouble resizing the GPT partition on a recently expanded RAID array.  This is a single volume with a single partition on it.  Below are the error details and the gdisk -l output.

GParted 0.19.1 --enable-libparted-dmraid

Libparted 3.1
Grow /dev/sdc1 from 23.65 TiB to 47.29 TiB  00:12:36    ( ERROR )
         
calibrate /dev/sdc1  00:00:00    ( SUCCESS )
         
path: /dev/sdc1
start: 2048
end: 50781249535
size: 50781247488 (23.65 TiB)
check file system on /dev/sdc1 for errors and (if possible) fix them  00:12:36    ( SUCCESS )
         
e2fsck -f -y -v -C 0 /dev/sdc1
         
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

6380640 inodes used (1.61%, out of 396730368)
114131 non-contiguous files (1.8%)
3306 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 6366409/12034
5181710676 blocks used (81.63%, out of 6347655936)
0 bad blocks
15 large files

6032952 regular files
345004 directories
0 character device files
0 block device files
25 fifos
0 links
2644 symbolic links (2158 fast symbolic links)
6 sockets
------------
6380631 files
e2fsck 1.42.9 (28-Dec-2013)
grow partition from 23.65 TiB to 47.29 TiB  00:00:00    ( ERROR )
         
old start: 2048
old end: 50781249535
old size: 50781247488 (23.65 TiB)
requested start: 2048
requested end: 101554502399
requested size: 101554500352 (47.29 TiB)
libparted messages    ( INFO )
         
Unable to satisfy all constraints on the partition.
Can't have overlapping partitions.

========================================
GPT fdisk (gdisk) version 0.8.6

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 101554502400 sectors, 47.3 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8301E912-F18F-4A65-B10A-53ED8BB1C8EA
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 101554502366
Partitions will be aligned on 2048-sector boundaries
Total free space is 50773254845 sectors (23.6 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048     50781249535   23.6 TiB    0700  

I've tried align to MiB and None.  Any help would be greatly appreciated.

2

Re: Error resizing EXT4 partition [SOLVED]

Thanks for providing the gparted_details.htm log file.  This helps tremendously with troubleshooting.

The problem appears to be that the requested partition end would result in no space at the end of the device for the backup copy of the GUID Partition Table (GPT).

101,554,502,400 --- total disk sectors from gdisk
101,554,502,399 --- Requested end sector from gparted_details.htm log file

A work around to this issue is to make sure to leave 1 MiB free space following when the partition is resized.

GParted does contain code to ensure adequate unallocated space is left free at the end of the disk device for the backup copy of the GPT, but for some reason this does not appear to have been effective.

Did you permit libparted to move the backup copy of the GPT to the new end of the device?
(GParted should have prompted you on startup).

Also, GParted 0.19.1 and libparted 3.1 are quite old.  We highly recommend using the latest version of GParted.  A good way to do this is by booting from media containing GParted Live.  The most recent stable version is GParted Live 0.28.1-1.

3

Re: Error resizing EXT4 partition [SOLVED]

gedakc wrote:

Thanks for providing the gparted_details.htm log file.  This helps tremendously with troubleshooting.

The problem appears to be that the requested partition end would result in no space at the end of the device for the backup copy of the GUID Partition Table (GPT).

101,554,502,400 --- total disk sectors from gdisk
101,554,502,399 --- Requested end sector from gparted_details.htm log file

A work around to this issue is to make sure to leave 1 MiB free space following when the partition is resized.

GParted does contain code to ensure adequate unallocated space is left free at the end of the disk device for the backup copy of the GPT, but for some reason this does not appear to have been effective.

Did you permit libparted to move the backup copy of the GPT to the new end of the device?
(GParted should have prompted you on startup).

Also, GParted 0.19.1 and libparted 3.1 are quite old.  We highly recommend using the latest version of GParted.  A good way to do this is by booting from media containing GParted Live.  The most recent stable version is GParted Live 0.28.1-1.

Thanks for the quick response!  I am currently working on updating gparted to the latest version but it is not so easy with RHEL 7.  Gparted did prompt me to move the backup GPT to which I responded yes.  I actually had also tried leaving 100MB at the end of the partition but it still failed.  Maybe I will try again with Alignment set to None instead of MiB.

4

Re: Error resizing EXT4 partition [SOLVED]

I am unsure what exactly the fix was but I built a new Gparted from source and tried leaving 1MiB after the partition and setting Align to none.  While I got farther than before and successfully resized the partition, the filesystem resize failed.

After attempting check and repair using the built in e2fsprogs v1.42.9 it hung for several hours doing seemingly nothing but eating CPU.  I found several sources reporting the same behavior with the same version.  I force killed the job, booted the server onto the latest gparted live and reran the check and repair.  This was successful and happily there was no data loss.

5

Re: Error resizing EXT4 partition [SOLVED]

Thanks for reporting back with the steps you took to resolve the issue, and for editing the initial post to prefix SOLVED in front of the title.  This can help others searching for answers to similar questions.

The alignment setting of "none" does not respect partition limitations.  It would work in this case because you allowed for 1 MiB of unallocated space following the partition.  Using alignment options such as MiB or Cylinder will respect partition rules.  See GParted Manual - Specifying Partition Alignment.