Maybe Right - the above multi-partition solution implies that the re-partitioning system boots from microSDXC. Assuming they aren't reinventing the wheel, it is likely a tiny Linux bootable microSD card image with the partitioning software and Linux installer - maybe like a 'live' version. It should be possible, for those of us who would prefer it, to install Linux to the microSDXC card instead of the eMMC.
Where did you see the implication that it boots from the card? It looks as if it is part of the flashing software, which runs on a Windows or Linux machine or a Mac.
In order to re-partition a disk/drive/eMMC/SSD, the device needs to be activated (booted) from an alternate boot point. With the Gemini this means one of seven methods.
1. Boot from the eMMC to a RAM disk then unmount the eMMC and make it available to the USB port as device to be overwritten by a PC/host computer. This is unreliable and a short path to brickage if the process gets interrupted.
2. Boot from an OS on the microSD then either load the OS directly to the eMMC from an image on the microSD. This is how many Android devices with microSD slots were able to load Cyanogenmod. Usually initiated by holding a button on the device during power on (to switch the boot target). This is exactly the process that Planet appeared to be doing to boot to Linux at CES, which is why I'm pretty sure they were booting Linux from microSDXC cards there.
3. Boot from USB media - process is essentially the same as #2 above. Needs some sort of switch (button hold at power on) to tell it to target USB for booting.
The two above can all be done with JUST the Gemini - no additional computer required. All simple with very low likelihood of bricking the device.
Boot the Gemini to Android (normal function).
Download the microSDXC or USB stick installer image.
Write the image to it's destination (microSDXC or USB - whichever one it can boot from).
Verify/check the bootable installer image.
Boot from the installer (hopefully a Debian Live like instance).
Manipulate partitions, select target, install from the boot device to the unmounted eMMC.
If all else fails, re-download the installer ISO image on a PC and dd it onto media (microSDXC or USB) then boot the Gemini from that.
Simple, reliable.
4. Run specialized software on a PC to provide a virtualboot-host over the USB port (much like a USB boot image from #2). Unit needs to be put into a state to accept this boot target (as in #2 and #3) and an OS image to write to the unmounted eMMC. This is how most consumer devices without microSD ports (phones, tablets, ereaders, etc) get their initial factory OS loaded. Usually there is some form of encrypted signing involved to validate the imaging connection. This is complicated and and an entirely unnecessary step as the device would need to be able to boot from a USB image to begin with - at which point it may as well boot from a live Linux image on a USB stick and work entirely within the Gemini itself. I.e. why on earth would they select this method requiring two computers - one of which they cannot predict the state of (your PC) - when it could be completely done within the one (Gemini) that they know you will have in-hand and a piece of media (microSDXC or USB stick) that is ubiquitous.
Regardless of the method above, there must be a method to change the boot-from device for the above methods to work.
5. Load a special - usually signed - 'installer file' to the device then reboot it. The existing OS on the device checks the directory during boot to see if there is a software update, and if so, boots into a special state where the contents of the file are exploded out to overwrite the other system files. This method is unlikely to be used for the purpose of adding/moving/shrinking/expanding/changing partitions though as it requires the partition to be active and mounted in order to read the file - unless it reads the file into a ram disk to then flip to while it overwrites the root/system files (again with brickability). This is probably how your cell phone gets it's OS updates. Special signed file is downloaded, phone reboots, installs new files from the special file over the old files.
6. BIOS/system/firmware boot order includes USB check to see if there is a USB host connected and waiting - then if so puts the device in a USB device mode entirely driven within firmware. At that point it makes an easy target to repartition from the computer it is connected to and any OS image is a dd from image file away. This method has some drawbacks too. It requires that the device have a distinct and independent USB logic controller to act as 'device mode' that runs before the eMMC boots. Effectively a sub-computer with it's own firmware within the Gemini just to handle running it in device mode USB. This strikes me as unlikely, difficult to secure, and very unreliable.
7. Magic. This is a placeholder in case they dreamed up something entirely novel or at least new to me.
