Thursday, 29 June 2017

Problems extending a disk in Red Hat Enterprise Linux 7.3

Following one of my much earlier posts: -

 Increasing the size of a partition using Red Hat Enterprise Linux 6.3

I hit a bit of a snag.

This all worked: -

fdisk /dev/sda         -    to add a new partition ( having extended the disk using VMware Workstation )

reboot

pvcreate /dev/sda3

  Physical volume "/dev/sda3" successfully created.

vgextend rhel /dev/sda3

  Volume group "rhel" successfully extended

lvextend /dev/rhel/root /dev/sda3

  Size of logical volume rhel/root changed from 47.46 GiB (12151 extents) to 97.46 GiB (24950 extents).
  Logical volume rhel/root successfully resized.

but this step failed: -

resize2fs -p /dev/rhel/root

resize2fs 1.42.9 (28-Dec-2013)
resize2fs: Bad magic number in super-block while trying to open /dev/rhel/root
Couldn't find valid filesystem superblock.

As ever, the internet had the answer: -

resize2fs: Bad magic number in super-block while trying to open

After a bit of trial and error... as mentioned in the possible answers, it turned out to require xfs_growfs rather than resize2fs.

So I tried xfs_grow instead: -

xfs_growfs /dev/rhel/root

meta-data=/dev/mapper/rhel-root  isize=256    agcount=4, agsize=3110656 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=12442624, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=6075, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 12442624 to 25548800

and now my disk is twice the original size: -

 df -kmh

Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/rhel-root   98G  9.2G   89G  10% /
devtmpfs               4.8G     0  4.8G   0% /dev
tmpfs                  4.8G     0  4.8G   0% /dev/shm
tmpfs                  4.8G  8.6M  4.8G   1% /run
tmpfs                  4.8G     0  4.8G   0% /sys/fs/cgroup
/dev/sda1              497M  219M  278M  45% /boot
tmpfs                  983M     0  983M   0% /run/user/0

which is awesome.

No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...