PUMP can result in non-bootable images

We've discovered a case in which PUMP results in a non-bootable image, MWE is presented below:

FROM https://downloads.raspberrypi.org/raspbian_lite/images/raspbian_lite-2019-04-09/2019-04-08-raspbian-stretch-lite.zip

PUMP 1G

Output:

### PUMP 1G
pump conversion to 1M * 1000
pump ceil: 1M * 1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 15.7714 s, 66.5 MB/s
Model:  (file)
Disk /root/Base.img: 2852MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      4194kB  49.2MB  45.0MB  primary  fat32        lba
 2      50.3MB  1804MB  1753MB  primary  ext4

add map loop1p1 (253:2): 0 87851 linear 7:1 8192
add map loop1p2 (253:3): 0 5472256 linear 7:1 98304
rootfs: 39794/107072 files (0.1% non-contiguous), 239385/428032 blocks
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/mapper/loop1p2 to 684032 (4k) blocks.
The filesystem on /dev/mapper/loop1p2 is now 684032 (4k) blocks long.

del devmap : loop1p2
del devmap : loop1p1
add map loop1p1 (253:2): 0 87851 linear 7:1 8192
add map loop1p2 (253:3): 0 5472256 linear 7:1 98304
update-binfmts: warning: qemu-arm already enabled in kernel.
update-binfmts: warning: qemu-armeb already enabled in kernel.
update-binfmts: warning: qemu-aarch64 already enabled in kernel.
mount: can't find PARTUUID=c1dc39e5-01
### Warning: Mounting image partitions using /etc/fstab failed.

My conjecture is that parted's fix approach introduced here, may change partition UUIDs resulting in errors in some booting configurations.

https://github.com/Nature40/pimod/blob/696fd7e9b9c06a59f01f1236c550f7548c3628da/stages/20-prepare.sh#L29-L32

Nature40 / pimod

PUMP can result in non-bootable images #42