Custom Installation on machine with multiple disks, demo mode hard freezes.

[SimonGreen-NZ]

I have a PC with multiple drives in it (dates from 2017) and I want to install on a specific drive. If I go to Custom Install I can open gparted and create new partitions on that device. I created a boot/esp partition, a swap partition, and a btrfs partition that was to be the root.

After saving the partitions I can exit from gparted and return to the list of drives & partitions in the installer but it is impossible to select the ones I want in order to continue. If I double click on the boot & swap partitions these seem to get a tick mark in them - though other than trial and error there was no way to know this was required - but nothing happens if I double click on the btrfs partition. Double-clicking on another randomly chosen partition on a different device got a tick, but I don't want to do that.

Indeed, since there are no instructions on how to actually select the partitions I am unsure what the installer might have done had I proceeded.

At that point I decided to go back to Demo mode hoping to find some hints. Attempting to resize the browser it launched immediately froze the entire machine and I had to hard power cycle to reboot. The hardware is nothing weird, it's a Ryzen 3700X CPU and an nVidia 4070 video card.

I'm not a total novice Linux user - I've been using Linux since kernel version 1.3 - so it is pretty frustrating falling at the first hurdle.

[GwynethLlewelyn]

Interestingly, I came across a very similar issue, but when installing on an ancient MacBook Pro. I used a more recent .iso which had no issues beginning the installation under another old Windows machine; since I stumbled upon an issue (not related to elementary OS!) that remains unsolved (MBR/UEFI conflicts between drives — long story), I then went to install elementary OS from scratch on the MacBook Pro. It installed beautifully, but at the point described by @SimonGreen-NZ (and addressed on #917), the centred installation box displaying the partition table behaved very strangely. It was oddly resized so that the buttons to Cancel and Proceed (I don't remember the exact names) were not completely shown, i.e., way off the screen below. Every time I either attempted to resize that modal or clicked on the partitions to select them, the modal would just get wider and wider — pushing the buttons further right and down — until they were simply off-screen altogether and not clickable.

The solution, in that case, was simply to use Tab to move focus to the buttons and press Enter.

After that step, everything went smoothly all the way, and elementary OS didn't have the slightest issue in properly recognising the Retina screen and the Nvidia card at first try — as well as both Ethernet and Wi-Fi, with which I had struggled in past installations on ancient Macs.

To conclude:

1. There is nothing wrong with the installation per se: I used the same .iso on the same USB pen drive to install both on a PC and on a Mac.
2. Both the PC and the Mac have Intel quad-core CPUs, Nvidia cards, and Samsung SSDs, although the similarities stop there! (It's just a coincidence.) The Mac is slightly older than the PC but essentially the same generation.
3. The issue with the buttons and the weird automatically-widening modal window only happens under the Mac for some reason, but not on the PC (in my case; @SimonGreen-NZ is reporting about a PC, so this issue is not strictly related to PC vs. Mac).
4. Once the partitioning step is dealt with, everything else runs smoothly (during installation as well as actually booting into elementary OS), and almost all hardware on the Mac was either detected immediately or just required some extra patches/drivers (i.e., for the Nvidia card) which were run in the background, delivered, and installed properly, all without manual intervention — exactly what I was expecting from elementary OS and its claim to be "the simplest and easiest distro to install".

The discussion on #917 about how the installation application was 'hacked' together at different times may be relevant in the sense that whatever is handling the resizing sometimes gets it right and sometimes fails horribly, and this is not dependent on the .iso itself but rather on some strange configuration present in some combinations of hardware — although the suggested changes in the code might completely side-step the issue at all.