gptfdisk: update to 1.09.2 / fs_resize: improvements

[mglae]

Since update to 1.09 sgdisk -e /dev/<device> is failing in fs_resize.

The issue was reported in forum.

After add adding logging the error was visible.

There is no gptfdisk 1.09.2 source available on Sourceforge. To avoid issues with downloading from git the upstream patches are added.

To ease research on future errors the logging code is included in this PR, it only creates a short log on success:

2023-03-26T11:36:57+0000
/dev/sda2 /storage ext4 rw,noatime 0 0
DISK: /dev/sda  PART: /dev/sda2
*** sgdisk -e /dev/sda >>/flash/fs-resize.log 2>&1
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
*** parted -s -m /dev/sda resizepart 2 100% >>/flash/fs-resize.log 2>&1
*** e2fsck -f -p /dev/sda2 >>/flash/fs-resize.log 2>&1
STORAGE: 11/8192 files (0.0% non-contiguous), 6938/32768 blocks
*** resize2fs /dev/sda2 >>/flash/fs-resize.log 2>&1
resize2fs 1.46.6 (1-Feb-2023)
Resizing the filesystem on /dev/sda2 to 3665900 (1k) blocks.
The filesystem on /dev/sda2 is now 3665900 (1k) blocks long.

Adding support for NVME devices (see installer) and improve error messages.

[antonlacon]

I'd like to avoid writing a file that won't be used for the (hopefully vast) majority of users. Could the logfile be made to tmpfs and then copied to /flash on error? Something like one of:

if $? -ne 0 after each step
resize-step || save-log && die ...

I don't know if the return value will be from the bash function running the spinner or the command it's executing. So maybe checking partition size before and after resize and saving logs if they match instead. Using parted should be something like:

PART_NUMBER="${PART#${DISK}}" # /dev/sda2 -> 2, /dev/mmcblk0p2 -> p2
PART_NUMBER=${PART_NUMBER#p} # 2 -> 2, p2 -> 2
PART_SIZE=$(parted "${DISK}" unit B print list -m | grep "^${PART_NUMBER}" | cut -d ":" -f3)

To get size of the partition in bytes. #5096 has some code for that using blockdev (would need to be enabled in busybox) as an alternative.

[mglae]

@antonlacon My intention was different.

I kept the file system resize as black box for the user but added a small log file as flag for execution and developer information. This allow to even detect not fatal errors in the future. Maybe it is worth to be included into pastekodi.

[antonlacon]

Tested RPi3.

[mglae]

Tested RPi3.

Excellent. Please post the fs-resize.log as reference for MSDOS/MBR partition scheme

[antonlacon]

RPi3 fs-resize.log:

2023-04-03T20:58:39+00:00
/dev/mmcblk0p2 /storage ext4 rw,noatime 0 0
DISK: /dev/mmcblk0  PART: /dev/mmcblk0p2
*** parted -s -m /dev/mmcblk0 resizepart 2 100% >>/flash/fs-resize.log 2>&1
*** e2fsck -f -p /dev/mmcblk0p2 >>/flash/fs-resize.log 2>&1
STORAGE: 11/8192 files (9.1% non-contiguous), 1549/8192 blocks
*** resize2fs /dev/mmcblk0p2 >>/flash/fs-resize.log 2>&1
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/mmcblk0p2 to 7413888 (4k) blocks.
The filesystem on /dev/mmcblk0p2 is now 7413888 (4k) blocks long.

I'm curious how it's 9.1% non-contiguous on a new format. Guessing the SD card is showing its age.

[mglae]

I'm curious how it's 9.1% non-contiguous on a new format. Guessing the SD card is showing its age.

This should be in the image too (you can test with losetup -f --show -P <image file>).

I'm more curious about the "8192 blocks" checked, should be 32768.

[vpeter4]

I'm more curious about the "8192 blocks" checked, should be 32768.

Isn't 8192 blocks * 4k/block = 32 MB = STORAGE_SIZE=32 MB = 32768 kB ?

[mglae]

Isn't 8192 blocks * 4k/block = 32 MB = STORAGE_SIZE=32 MB = 32768 kB ?

Yes, but either in recent LE12 nighties it is 32768 * 1 kiB blocks. I've never seen something else.

[CvH]

gtg ?

[mglae]

IMO yes. Latest discussion is not related to this PR.