I have tried to install Peppermint9 and after, Mint19, onto my laptop.

But in both cases, it misreports that there is 0bytes available for the install. (both dstros' installers look remarkably the same) Whereas there are two huge empty partitions waiting for it, one on each drive.

Here's the setup of my laptop:
AMDx64, 4cores, 8GB RAM
bootingfrom : 2GB USB with Mint 19 live or peppermint9 live.
Storage a: 128GB SSD (presently with Windows7, plus an ext4 partition reserved for Linux (about 50gb).
Storage b: 750GB hdd (has partitions: ext4 previously had Mint 18.3 on it, now empty. data partition.) with a 100gb ext4 available for Linux.

During install, after I select language, keyboard layout, skip wifi (for now), the next screen tells me I have 0bytes available for the install.
(It should be taking me to the next screen where it asks me to select a drive or partition to install to). But it goes no further, ie: blocks me from going any further (No "next").

I even tried opening all partitions, by clicking on them in the file manager (in Mint's Nemo), which placed shortcuts to each one on the desktop. I figured it mounted them, and teh installer surely will see them. But still the message that there is 0.0bytes available.

I've had Mint 18.2 and 18.3, and even some much older versions years ago, on that same hard drive. I know it's not a compatibility issue. The hdd is a standard SATA.

My other concern is, if Mint's latest installer is buggy, I am worried about losing my Windows7 setup that I just spent the past few days setting up and optimising, as I need a dual-boot so I can run a couple windows-specific CAD programs.

Hope this doesn't confuse things further, but here is an image of my devices and the available partitions for install
http://www.bild.me/bild.php?file=2245218pw_minitool.jpg
Note the 37GB available on the SSD (I can easily remove the small FAT to expand that if needed), and the 91GB and 61GB partitions on the HDD that are both empty.

I would rather say you specified a read-only device (or something similar) for installation.

The current Mint documentation shows two installation options i.e. Erase disk and install or Something Else. The Something Else option should be selected to manually partition or select existing partitions. I have not played with the Something Else option lately so not sure if there are bugs or how complicated the steps.

If all the space on the drives is partitioned then it might show as zero available. An empty partition is not the same thing as unallocated. You have to manually select the partition and the desired mount point.

I don't use any *buntu distros, but, you have all your disk space already allocated, so you will need to use the alternate method of installation, which should let you choose where to install your new system, & where to install the boot loader - most distros have a simple install (for newbies) & a regular installation program that lets you decide where it's going to live. .

Guys, NO, none of that!
Am I really that bad at explaining things? After keyboard language, it blocks any further progress.
How could I word differently that so that more people visiting the thread would understand?

@ pan65 and @michaelk: as I mentioned in the OP, I don't even get that far into the install. After keyboard selection, I am blocked from going any further. Nothing is read-only @pan64 - it did not even get that far, where you can specify anything. After keyboard language: it stops, no "next/continue" button.

@fatmac: allocated or not, the installer should ask you (farther than it allowed me to go) whether I want to wipe out the drive and install over, install alongside an existing OS, or something else (where it'll launch gParted).

Have you tried disconnecting the hard drive before booting and see if that makes a difference?

If it doesn't, can you post exact details (perhaps using a screenshot) of the partitioning of your SSD?

You did but I did not pay enough attention. It has been awhile since I have installed Mint to anything but an empty drive and I have not tried Mint 19 so I can't say if this is a bug, a bad ISO download or something unique to your system.

If you are able to choose something else to select the partitions your Windows 7 should be safe. Although with computers nothing is ever 100% guaranteed.

I can't tell if the thing is being locked up or refuses to go on due to the fact that you may have used up the drive for some linux already. Put a blank or some non OS usb drive in before you get too far in the load and see if it allows you to try to install to this usb drive.

They both use the Ubuntu Ubiquity installer and the basic difference is the background color. If I'm reading your post correctly, you do not get the option to select the Installation type where you would choose Something Else for a manual install, is that correct?

The information you posted on the Linux partitions conflicts with the image you posted. On Disk 1 it shows a Linux partition of 61GB with 3.8GB used. On Disk 2, it shows a 37GB Linux partition with 773MB used. If you do not actually have any data on these partitions as you indicated in your post, when you boot Mint open a terminal and run GParted and select those partitions and format them.

After you skip the wifi screen, you should see the Installation Type window where you would select the Something Else option. If you don't see that, the only reason I could see for the message is that it sees the partitions with data and being used.

If you are not getting the installer working properly, then it sounds like you got a bad download, check the md5 sum, or download a fresh copy.

In answer to your first, and last, sentences: As I said, it blocks me from going that far. It stops at the fourth screen. ("Continue" button is dead)

The data used/available seems to be an idiosyncracy of GParted, cylinders, partition boundary etc. I noticed this when I created new partitions there. Depending onthe size, where they start and end, there is either more, or less, data labeled as "used". It was worse on the first try - but I didn't want to take the time to putz around eternally until I got a really small number.

I created a little picture gallery on FB,
showing the various screens, in case you're interested in looking at all of them.

I have downloaded Mint 18.3, so I can text it's installer, with this hardware setup.
(when I had Linux on the HDD before, I was not yet owner of the SSD)

I will also try, with only one at a time, of each of the drives installed, with Mint 19's installer.

I just checked the Mint 19 installer with an existing Mint 18 VirtualBox guest. The installer recognized that 18 was installed and the installation type setup page displayed as expected. The Mint 18 guest was originally installed with default selected, no lvm and no encryption. I am not ruling out a bug.

Obviously I can not simulate your system so it is difficult to know exactly where/why the installer is hanging. The first thing would be to confirm the Mint 19 ISO file matches its md5 sum. Not that it should matter but I assume that you downloaded the 64 bit version?

Trying to install on another blank USB drive is a good idea.

RESOLVED
mintinstall BUG suspected

OK, it turns out, that if I remove the Toshiba HDD, the installer works (with only the SSD).

I swapped that out and added only a WD hard disk, and the installer works.

Add back in the SSD, with the WD hdd still present, and the installer works (with both the SSD and HDD).

So it's something with the Toshiba hard drive. Windows kept on nagging me to make a change to it... and maybe at some point it did. (you know how a pop-up shows up, right in the middle of when you are typing something, and while typing you press spacebar which activates "OK" in the pop up dialogue. I never saw what it was, but on the following dialogue, I answered no, but never did see the first one).

What puzzles me, is that gParted would not launch, and reported a "bug in libparted", and that even with something wrong with the MBR of the hdd, the installer should still have reported on free space on the SSD, and not reported the capacity on the USB I was booting from. It should have identified the drives, and allowed for GParted to wipe the drive with the error on it.

For me, it's "resolved". But for the installer, it is not. There may be something the creators of the installer would want to look into.

I'm not really sure about that. If a disk was corrupted in a system gparted or similar tools probably must not do anything, because that may cause even more problems.