Shrinking doesn't move last sector

[pucgenie]

After letting it seemingly successfully shrink a FAT32 partition on an microSD card, 1) fsck.vfat afterwards tells me it couldn't seek to the last sector and aborts. 2) Windows Checkdisk doesn't correct it but also doesn't show any detected inconsistencies or errors. Should fatresize rewrite the last sector metadata and is it a bug/regression, or have I misunderstood something in the documentation?

[ya-mouse]

Could you please provide exact params of the microSD card: fdisk -l /dev/sd.. and exact command output from fatresize. PS. fatresize is a wrapper around libparted. There is a possibility, that partition being shrinked after filesystem resize could be one off sector from the actual filesystem size.

[pucgenie]

I didn't capture the output and to reproduce it 100% an old backup would be needed that I don't have.

~/selfcompiled/fatresize$  sudo fdisk -l /dev/mmcblk0p1
Disk /dev/mmcblk0p1: 230.96 GiB, 247995793408 bytes, 484366784 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: dos
Disk identifier: 0x00000000

~/selfcompiled/fatresize$  sudo fsck.vfat  -a /dev/mmcblk0p1
fsck.fat 4.1 (2017-01-24)
Seek to 247995805184:Invalid argument

~/selfcompiled/fatresize$  sudo ./fatresize -vps 248G /dev/mmcblk0p1
fatresize 1.0.3 (20210131)
.part(start=8192, end=484374975, length=484366784)
Backtrace has 5 calls on stack:
  5: /lib/x86_64-linux-gnu/libparted.so.2(ped_assert+0x49) [0x7f8dba4df6a9]
  4: ./fatresize(+0x371f) [0x5577318cd71f]
  3: ./fatresize(+0x30d8) [0x5577318cd0d8]
  2: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf2) [0x7f8dba310cb2]
  1: ./fatresize(+0x353e) [0x5577318cd53e]
Bug: Assertion (ped_geometry_test_sector_inside(range, *sector)) at fatresize.c:347 in function snap() failed.
Aborted

~/selfcompiled/fatresize$  sudo ./fatresize -vs 247G /dev/mmcblk0p1
fatresize 1.0.3 (20210131)
part(start=8192, end=484374975, length=484366784)
Error: The file system is bigger than its volume!

~/selfcompiled/fatresize$  sudo ./fatresize -vs 249G /dev/mmcblk0p1
fatresize 1.0.3 (20210131)
part(start=8192, end=484374975, length=484366784)
Error: The file system is bigger than its volume!

Artificial reproduction steps:

~/selfcompiled/fatresize$  sudo fdisk /dev/mmcblk0

Welcome to fdisk (util-linux 2.36).                                      
Changes will remain in memory only, until you decide to write them.      
Be careful before using the write command.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 
First sector (2048-486998015, default 2048): 484374976
Last sector, +/-sectors or +/-size{K,M,G,T,P} (484374976-486998015, default 486998015): +1030M

Created a new partition 2 of type 'Linux' and of size 1 GiB.

Command (m for help): t
Partition number (1,2, default 2): 2
Hex code or alias (type L to list all): 0x0C

Changed type of partition 'Linux' to 'W95 FAT32 (LBA)'.

Command (m for help): p
Disk /dev/mmcblk0: 232.22 GiB, 249342984192 bytes, 486998016 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: dos
Disk identifier: 0x738a4d67

Device         Boot     Start       End   Sectors  Size Id Type
/dev/mmcblk0p1           8192 484374975 484366784  231G  c W95 FAT32 (LBA
/dev/mmcblk0p2      484374976 486483967   2108992    1G  c W95 FAT32 (LBA

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

~/selfcompiled/fatresize$  sudo mkfs.vfat /dev/mmcblk0p2
mkfs.fat 4.1 (2017-01-24)

Now it even doesn't try to resize the FAT filesystem:

~/selfcompiled/fatresize$  sudo ./fatresize -vps 900M /dev/mmcblk0p2
fatresize 1.0.3 (20210131)
.part(start=8192, end=484374975, length=484366784)
Error: The file system is bigger than its volume!

All commands executed on a current Lubuntu system. EDIT: Wrong partition number, will retry in a few hours.

~$ sudo ~/selfcompiled/fatresize/fatresize -s 1Gi /dev/mmcblk0 -n 2
fatresize 1.0.3 (20210131)
part(start=484374976, end=486483967, length=2108992)
Backtrace has 5 calls on stack:
  5: /lib/x86_64-linux-gnu/libparted.so.2(ped_assert+0x49) [0x7fc49d5136a9]
  4: .../selfcompiled/fatresize/fatresize(+0x371f) [0x5560ff7dc71f]
  3: .../selfcompiled/fatresize/fatresize(+0x30d8) [0x5560ff7dc0d8]
  2: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf2) [0x7fc49d344cb2]
  1: .../selfcompiled/fatresize/fatresize(+0x353e) [0x5560ff7dc53e]
Bug: Assertion (ped_geometry_test_sector_inside(range, *sector)) at fatresize.c:347 in function snap() failed.
Aborted

[ya-mouse]

Disk /dev/mmcblk0p1: 230.96 GiB, 247995793408 bytes, 484366784 sectors
.part(start=8192, end=484374975, length=484366784)
Seek to 247995805184:Invalid argument

So, fatresize has tried to resize the partition beyond the physical flash size (the diff equal to start offset value). I'll look.

[pucgenie]

Thanks for investigating what's wrong. BTW, I just noticed parted.m4 was missing, so after recompiling, the version number changed but everything else seems to be the same.

johannes@clevop:~/selfcompiled/fatresize$ sudo ~/selfcompiled/fatresize/fatresize -s 1Gi /dev/mmcblk0 -n 2
fatresize 1.1.0 (20210204)
part(start=484374976, end=486483967, length=2108992)
Backtrace has 5 calls on stack:
  5: /lib/x86_64-linux-gnu/libparted.so.2(ped_assert+0x49) [0x7f1de23f26a9]
  4: /home/johannes/selfcompiled/fatresize/fatresize(+0x371f) [0x555f07eba71f]
  3: /home/johannes/selfcompiled/fatresize/fatresize(+0x30d8) [0x555f07eba0d8]
  2: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf2) [0x7f1de2223cb2]
  1: /home/johannes/selfcompiled/fatresize/fatresize(+0x353e) [0x555f07eba53e]
Bug: Assertion (ped_geometry_test_sector_inside(range, *sector)) at fatresize.c:347 in function snap() failed.
Aborted

[ya-mouse]

Yeah, something wrong with snapping partition's constraints.

[mjt0k]

in my case this assertion message is always displayed, no matter how I try to resize it - either shrink or extend, fatresize almost always fails immediately with the above message. In a few cases when it actually succeeded, it broke the filesystem, so that an attempt to mount it results in "attempt to access address outside of the device" message from kernel (I don't remember the exact wording), and trying to resize it again with fatresize fails too with "Error: The file system is bigger than its volume!" message as above. I performed quite a lot of various resizes (extending, not shrinking), and it always fails - either immediately with assertion failure (keeping the filesystem intact) or seemingly succeeding at first but damaging the filesystem. I'd say it's quite a dangerous tool.