bug: batocera broken

[funk-on-code]

I confirm this bug has not already been reported

• [ X] I have searched the issues and this bug has not been reported previously

Describe the bug
Batocera v41 and v42 fail at the S02resize init file (enabled by default) due to a GPT partitioning error that requires either a much larger base partition, or a second disk added for the /userdata partition.

To Reproduce
Steps to reproduce the behaviour:

1. quickget batocera 42
2. quickemu VirtualMachines/batocera-42.conf --display spice

Expected behaviour
Batocera increases the size of the bootable partition correctly, instead of ending with an error of please check /tmp/resize.log for error details

Quickemu output
Quickemu runs successfully, but the error occurs on each bootup, showing an curses screen with the error, then falling over to a blank screen with the distribution attempts to boot without a valid disk to decompress to, spinning CPUs up to 100%.

Additional context
To access the logs, you'll need to load the nbd module first, mount the disk using it using qemu-nbd, navigate to /tmp/ inside the VM and view the log. I have tried using the preload options in Quickemu to solve the problem, anything less than 256G fails with an error similar to:

Partition name: /dev/vda & number: 2
Initial partition size: 1946345 MB
Initial partition size is larger than initial image size, formatting will be skipped
Disk = /dev/vda
Disk partition table type = gpt
Partition type = ext4
Step 1: Moving 2nd GPT table to the end of the disk
cmd:sgdisk -e /dev/vda2

Warning! Secondary partition table overlaps the last partition by
2014 blocks!
Try reducing the partition table size by 8056 entries.
(Use the 's' item on the experts' menu.)
Aborting write of new partition table.
cmd code:4

I can fix this if I manually edit the /etc/init.d/S02resize script inside Batocera and change the sgdisk command to use:

1. sgdisk --zap-all
2. sgdisk -g /dev/vda

and then use batocera-save-overlay to store the configuration change, then reboot -- but by default, the only way I could make Quickemu reliably fix the issue was to add a second disk to my configuration by hand, so the resize script resizes /dev/vdb instead.

Adding a second disk is the only way these two versions seem to work under GNOME-Boxes too, but libvirt (and virt-manager) do allow it to boot successfully.

[funk-on-code]

For additional context, the gist from https://gist.github.com/aderumier/fb965e09e96d5403d56773078ed8725b also works to resolve the problem, but again, isn't a "solution" for Quickget per se, as you still have to manually run the batocera-save-overlay command and reboot in order to apply it successfully