#103 Fix resizing underlying filesystem together with the LV
Closed 2 months ago by pwhalen. Opened 5 months ago by hricky.
hricky/arm-image-installer fix-resizefs  into  main

file modified
+2 -6
@@ -467,16 +467,12 @@ 

  		if [ "$LVM_NAME" != "" ]; then

  			vgchange -a y $LVM_NAME > /dev/null 2>&1

  			pvresize "$ROOTPART"

- 			lvextend -l +100%FREE /dev/$LVM_NAME/root

+ 			lvextend -l +100%FREE -ry /dev/$LVM_NAME/root

  			ROOTPART="/dev/$LVM_NAME/root"

  		fi

  	fi

  

- 	if [ "$FS_TYPE" = "xfs" ] && [ "$LVM_NAME" != "" ]; then

- 		mkdir /tmp/root > /dev/null 2>&1

- 		mount "$ROOTPART" /tmp/root > /dev/null 2>&1

- 		xfs_growfs /tmp/root

- 	elif [ "$FS_TYPE" = "btrfs" ]; then

+ 	if [ "$FS_TYPE" = "btrfs" ]; then

  		mkdir /tmp/root > /dev/null 2>&1

  		mount "$ROOTPART" /tmp/root > /dev/null 2>&1

  		btrfs filesystem resize max /tmp/root

When arm-image-installer is executed with the --resizefs option, in the case of an image that uses LVM (like Fedora Server), FS_TYPE gets LVM2_member as the value (Line 407). This way Line 475 is not triggered and the file system is not resized.

By adding -ry to the lvextend command (Line 470), it automatically resizes the file system along with the LV.

Can we clean up the pieces in 475 if they're handled as part of line 470?

1 new commit added

  • Clean up XFS file system resizing conditional statement
5 months ago

Not sure if we have an image that uses XFS without LVM, but even if we don't, it's probably better to be safe and leave it at that for now at least.

Officially the only image using XFS is server. Don't suppose it matters we try again after the lvresize step.

1 new commit added

  • Clean up redundant XFS filesystem resizing
5 months ago

Clean up the resizing of the XFS file system by removing the unnecessary part.

Thanks for the PR, apologies for the delay. This should be fixed in the latest version.

Pull-Request has been closed by pwhalen

2 months ago
Metadata