Hi,
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB?
[root@ip-10-0-0-218 centos]# df -hT --total Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 1.7G 0 1.7G 0% /dev tmpfs tmpfs 1.7G 0 1.7G 0% /dev/shm tmpfs tmpfs 1.7G 23M 1.7G 2% /run tmpfs tmpfs 1.7G 0 1.7G 0% /sys/fs/cgroup */dev/nvme0n1p2 xfs 7.8G 7.0G 824M 90% /* ----> expand /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB. /dev/nvme0n1p1 vfat 599M 6.4M 593M 2% /boot/efi tmpfs tmpfs 345M 0 345M 0% /run/user/1000 total - 16G 7.0G 8.5G 46% - [root@ip-10-0-0-218 centos]# fdisk -l GPT PMBR size mismatch (20971519 != 125829119) will be corrected by write. The backup GPT table is not on the end of the device. This problem will be corrected by write. *Disk /dev/nvme0n1: 60 GiB*, 64424509440 bytes, 125829120 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: E97B9FFA-2C13-474E-A0E4-ABF1572CD20C
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 17512447 16281600 7.8G Linux filesystem /dev/nvme0n1p3 17512448 17514495 2048 1M BIOS boot [root@ip-10-0-0-218 centos]# cat /etc/redhat-release CentOS Linux release 8.2.2004 (Core) [root@ip-10-0-0-218 centos]#
Please suggest. Thanks in Advance.
Best Regards,
Kaushal
Hi,
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB?
[root@ip-10-0-0-218 centos]# df -hT --total Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 1.7G 0 1.7G 0% /dev tmpfs tmpfs 1.7G 0 1.7G 0% /dev/shm tmpfs tmpfs 1.7G 23M 1.7G 2% /run tmpfs tmpfs 1.7G 0 1.7G 0% /sys/fs/cgroup */dev/nvme0n1p2 xfs 7.8G 7.0G 824M 90% /* ----> expand /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB. /dev/nvme0n1p1 vfat 599M 6.4M 593M 2% /boot/efi tmpfs tmpfs 345M 0 345M 0% /run/user/1000 total - 16G 7.0G 8.5G 46% - [root@ip-10-0-0-218 centos]# fdisk -l GPT PMBR size mismatch (20971519 != 125829119) will be corrected by write. The backup GPT table is not on the end of the device. This problem will be corrected by write.
How did you end up in this situation? Did you copy the data from a smaller disk to this 60G disk?
*Disk /dev/nvme0n1: 60 GiB*, 64424509440 bytes, 125829120 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: E97B9FFA-2C13-474E-A0E4-ABF1572CD20C
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 17512447 16281600 7.8G Linux filesystem /dev/nvme0n1p3 17512448 17514495 2048 1M BIOS boot
Looks like you could move p3 to the end of the disk and then enlarge p2 and then grow the XFS on it.
I'm not sure it's a good idea to use fdisk on a GPT disk. At least in the past this wasn't supported and I don't know how much has changed here. I didn't touch a lot of GPT systems yet, and where I did I felt frightened by the whole EFI stuff :)
Regards, Simon
I'm constantly using fdisk on GPT and everything has been fine. Best Regards,Strahil Nikolov
On Fri, Mar 12, 2021 at 15:30, Simon Mattersimon.matter@invoca.ch wrote: > Hi,
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB?
[root@ip-10-0-0-218 centos]# df -hT --total Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 1.7G 0 1.7G 0% /dev tmpfs tmpfs 1.7G 0 1.7G 0% /dev/shm tmpfs tmpfs 1.7G 23M 1.7G 2% /run tmpfs tmpfs 1.7G 0 1.7G 0% /sys/fs/cgroup */dev/nvme0n1p2 xfs 7.8G 7.0G 824M 90% /* ----> expand /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB. /dev/nvme0n1p1 vfat 599M 6.4M 593M 2% /boot/efi tmpfs tmpfs 345M 0 345M 0% /run/user/1000 total - 16G 7.0G 8.5G 46% - [root@ip-10-0-0-218 centos]# fdisk -l GPT PMBR size mismatch (20971519 != 125829119) will be corrected by write. The backup GPT table is not on the end of the device. This problem will be corrected by write.
How did you end up in this situation? Did you copy the data from a smaller disk to this 60G disk?
*Disk /dev/nvme0n1: 60 GiB*, 64424509440 bytes, 125829120 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: E97B9FFA-2C13-474E-A0E4-ABF1572CD20C
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 17512447 16281600 7.8G Linux filesystem /dev/nvme0n1p3 17512448 17514495 2048 1M BIOS boot
Looks like you could move p3 to the end of the disk and then enlarge p2 and then grow the XFS on it.
I'm not sure it's a good idea to use fdisk on a GPT disk. At least in the past this wasn't supported and I don't know how much has changed here. I didn't touch a lot of GPT systems yet, and where I did I felt frightened by the whole EFI stuff :)
Regards, Simon
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I'm constantly using fdisk on GPT and everything has been fine. Best Regards,Strahil Nikolov
That's only true in recent times, because in the past fdisk didn't support GPT at all. Back then you had to use tools like parted.
Simon
On Fri, Mar 12, 2021 at 15:30, Simon Mattersimon.matter@invoca.ch wrote: > Hi,
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB?
[root@ip-10-0-0-218 centos]# df -hT --total Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 1.7G 0 1.7G 0% /dev tmpfs tmpfs 1.7G 0 1.7G 0% /dev/shm tmpfs tmpfs 1.7G 23M 1.7G 2% /run tmpfs tmpfs 1.7G 0 1.7G 0% /sys/fs/cgroup */dev/nvme0n1p2 xfs 7.8G 7.0G 824M 90% /* ----> expand /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB. /dev/nvme0n1p1 vfat 599M 6.4M 593M 2% /boot/efi tmpfs tmpfs 345M 0 345M 0% /run/user/1000 total - 16G 7.0G 8.5G 46% - [root@ip-10-0-0-218 centos]# fdisk -l GPT PMBR size mismatch (20971519 != 125829119) will be corrected by write. The backup GPT table is not on the end of the device. This problem will be corrected by write.
How did you end up in this situation? Did you copy the data from a smaller disk to this 60G disk?
*Disk /dev/nvme0n1: 60 GiB*, 64424509440 bytes, 125829120 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: E97B9FFA-2C13-474E-A0E4-ABF1572CD20C
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 17512447 16281600 7.8G Linux filesystem /dev/nvme0n1p3 17512448 17514495 2048 1M BIOS boot
Looks like you could move p3 to the end of the disk and then enlarge p2 and then grow the XFS on it.
I'm not sure it's a good idea to use fdisk on a GPT disk. At least in the past this wasn't supported and I don't know how much has changed here. I didn't touch a lot of GPT systems yet, and where I did I felt frightened by the whole EFI stuff :)
Regards, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Sun, Mar 14, 2021 at 07:05:37PM +0100, Simon Matter wrote:
I'm constantly using fdisk on GPT and everything has been fine. Best Regards,Strahil Nikolov
That's only true in recent times, because in the past fdisk didn't support GPT at all. Back then you had to use tools like parted.
I've only been playing with GPT and UEFI on CentOS for a little while. I'd read that fdisk wasn't a good idea, but it turns out that CentOS has gdisk, which is very similar and cgdisk which is like cfdisk.
I've been using them with no problem. I did, in a laptop where I was running several distributions for fun, use gparted to expand a partition, and that also worked without problem.
True.I wiped a VM this way , years ago. Best Regards,Strahil Nikolov
On Sun, Mar 14, 2021 at 20:05, Simon Mattersimon.matter@invoca.ch wrote: > I'm constantly using fdisk on GPT and everything has been fine.
Best Regards,Strahil Nikolov
That's only true in recent times, because in the past fdisk didn't support GPT at all. Back then you had to use tools like parted.
Simon
On Fri, Mar 12, 2021 at 15:30, Simon Mattersimon.matter@invoca.ch wrote: > Hi,
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB?
[root@ip-10-0-0-218 centos]# df -hT --total Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 1.7G 0 1.7G 0% /dev tmpfs tmpfs 1.7G 0 1.7G 0% /dev/shm tmpfs tmpfs 1.7G 23M 1.7G 2% /run tmpfs tmpfs 1.7G 0 1.7G 0% /sys/fs/cgroup */dev/nvme0n1p2 xfs 7.8G 7.0G 824M 90% /* ----> expand /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB. /dev/nvme0n1p1 vfat 599M 6.4M 593M 2% /boot/efi tmpfs tmpfs 345M 0 345M 0% /run/user/1000 total - 16G 7.0G 8.5G 46% - [root@ip-10-0-0-218 centos]# fdisk -l GPT PMBR size mismatch (20971519 != 125829119) will be corrected by write. The backup GPT table is not on the end of the device. This problem will be corrected by write.
How did you end up in this situation? Did you copy the data from a smaller disk to this 60G disk?
*Disk /dev/nvme0n1: 60 GiB*, 64424509440 bytes, 125829120 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: E97B9FFA-2C13-474E-A0E4-ABF1572CD20C
Device Start End Sectors Size Type /dev/nvme0n1p1 2048 1230847 1228800 600M EFI System /dev/nvme0n1p2 1230848 17512447 16281600 7.8G Linux filesystem /dev/nvme0n1p3 17512448 17514495 2048 1M BIOS boot
Looks like you could move p3 to the end of the disk and then enlarge p2 and then grow the XFS on it.
I'm not sure it's a good idea to use fdisk on a GPT disk. At least in the past this wasn't supported and I don't know how much has changed here. I didn't touch a lot of GPT systems yet, and where I did I felt frightened by the whole EFI stuff :)
Regards, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 3/12/21 1:45 PM, Kaushal Shriyan wrote:
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB?
parted porbably could do it. there is also a gparted gui (https://gparted.org/), but doesn't seem to be in CentOS 8.
Maybe boot from a livecd that includes the gui tool, like https://gparted.org/livecd.php or https://www.system-rescue.org/
- Thomas
Am 12.03.2021 um 15:23 schrieb Thomas Mueller thomas@chaschperli.ch:
On 3/12/21 1:45 PM, Kaushal Shriyan wrote:
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB?
parted porbably could do it. there is also a gparted gui (https://gparted.org/ https://gparted.org/), but doesn't seem to be in CentOS 8.
Maybe boot from a livecd that includes the gui tool, like https://gparted.org/livecd.php https://gparted.org/livecd.php or https://www.system-rescue.org/ https://www.system-rescue.org/
If the downtime is acceptable, that’s almost always the smartest thing to do, IMO.
On Fri, Mar 12, 2021 at 7:59 PM Rainer Duffner rainer@ultra-secure.de wrote:
Am 12.03.2021 um 15:23 schrieb Thomas Mueller thomas@chaschperli.ch:
On 3/12/21 1:45 PM, Kaushal Shriyan wrote:
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB?
parted porbably could do it. there is also a gparted gui (
https://gparted.org/ https://gparted.org/), but doesn't seem to be in CentOS 8.
Maybe boot from a livecd that includes the gui tool, like
https://gparted.org/livecd.php https://gparted.org/livecd.php or https://www.system-rescue.org/ https://www.system-rescue.org/
If the downtime is acceptable, that’s almost always the smartest thing to do, IMO.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Thanks for the reply. I am running this instance in AWS.
[root@ip-10-0-0-218 centos]# cat /etc/redhat-release CentOS Linux release 8.2.2004 (Core) [root@ip-10-0-0-218 centos]#
Looks like you could move p3 to the end of the disk and then enlarge p2
and then grow the XFS on it.
Is there a way to move p3 to the end of the disk using fdisk or gparted CLI tool?
Please suggest. Thanks in Advance.
Best Regards,
Kaushal
On Fri, Mar 12, 2021 at 7:59 PM Rainer Duffner rainer@ultra-secure.de wrote:
Am 12.03.2021 um 15:23 schrieb Thomas Mueller thomas@chaschperli.ch:
On 3/12/21 1:45 PM, Kaushal Shriyan wrote:
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G
and
occupy the remaining free disk space of 60GB?
parted porbably could do it. there is also a gparted gui (
https://gparted.org/ https://gparted.org/), but doesn't seem to be in CentOS 8.
Maybe boot from a livecd that includes the gui tool, like
https://gparted.org/livecd.php https://gparted.org/livecd.php or https://www.system-rescue.org/ https://www.system-rescue.org/
If the downtime is acceptable, that’s almost always the smartest thing to do, IMO.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Thanks for the reply. I am running this instance in AWS.
[root@ip-10-0-0-218 centos]# cat /etc/redhat-release CentOS Linux release 8.2.2004 (Core) [root@ip-10-0-0-218 centos]#
Looks like you could move p3 to the end of the disk and then enlarge p2
and then grow the XFS on it.
Is there a way to move p3 to the end of the disk using fdisk or gparted CLI tool?
I'm afraid I can't help with AWS, I've never used it and don't know what the partitions are used for.
Simon
On 3/12/21 4:45 AM, Kaushal Shriyan wrote:
Is there a way to expand xfs filesystem /dev/nvme0n1p2 which is 7.8G and occupy the remaining free disk space of 60GB?
Can you set up an identical EC2 instance to test the process? I definitely wouldn't do this on a system with data that you need, but you *might* be able to:
* create a new 1M partition at the end of the drive (not BIOS boot type) * reboot * use 'dd' to copy the content of nvme0n1p3 to nvme0n1p4 * delete the third partition and change the fourth to BIOS boot type. * resize the second partition * grub-install /dev/nvme0n1 * reboot * xfs_growfs
-
Gordon Messmer -
Kaushal Shriyan -
Rainer Duffner -
Scott Robbins -
Simon Matter -
Strahil Nikolov -
Thomas Mueller