How to mount a sparsed disk image

I have an image of the mSATA SSD disk of a PC. The disk contains the operating system and has a capacity of 512GB. I do not have that free storage, so I have cloned the disk into an image with dd compressing it with gz, and later according to the answer of this post , I have copied the sparsed content so that it occupied little. This has worked correctly, resulting in a 512GB image occupying less than 5GB on disk. As a summary of what has been done:

# dd bs=64K if=/dev/sdd conv=sync,noerror status=progress | gzip -c  > /image.img.gz
# gunzip -c /image.img.gz | cp --sparse=always /dev/stdin mini.img
# ls -lhs
4,8G -rw-------  1 balon users 477G ene 13 10:54 mini.img
2,3G -rw-r--r--  1 balon users 2,3G ene 11 08:32 minimal-industrial-pc.img.gz

So far, everything is correct. The problem comes when I intend to mount the image (since I want to cage myself in it and make some changes about the file system). I have tried the following: 1. fdisk

# fdisk -l mini.img
The size mismatch of the primary master boot record (GPT PMBR) (1000215215!= 1000215295) will be corrected by writing.
The backup GPT table is not at the end of the device.
Disk mini.img: 476,94 GiB, 512110231552 bytes, 1000215296 sectors
Units: sectores de 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disc label type: gpt
Disk identifier: 74BC899D-E8BA-4C70-B82D-6F4E8F6343A3

Device    Start   End        Sectors   Size   Type
mini.img1 2048    2203647    2201600   1G     EFI System
mini.img2 2203648 6397951    4194304   2G     Linux file system
mini.img3 6397952 1000212479 993814528 473.9G Linux file system

2. kpartx

# kpartx -a -v mini.img
GPT:Primary header thinks Alt. header is not at the end of the disk.
GPT:Alternate GPT header not at the end of the disk.
GPT: Use GNU Parted to correct GPT errors.
add map loop1p1 (254:4): 0 2201600 linear 7:1 2048
add map loop1p2 (254:5): 0 4194304 linear 7:1 2203648
add map loop1p3 (254:6): 0 993814528 linear 7:1 6397952

In this case there seems to be no problems mounting loop1p1 and loop1p2, but with `loop1p3, which I understand corresponds to the Ubuntu root system, there is no way. 3. gdisk

# gdisk -l mini.img
GPT fdisk (gdisk) version 1.0.9.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk mini.img: 1000215296 sectors, 476.9 GiB
Sector size (logical): 512 bytes
Disk identifier (GUID): 74BC899D-E8BA-4C70-B82D-6F4E8F6343A3
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 4717 sectors (2.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2203647   1.0 GiB     EF00
   2         2203648         6397951   2.0 GiB     8300
   3         6397952      1000212479   473.9 GiB   8300

What am I doing wrong?