Linux Lite 5.0 RC1 Released

[WytWun]

I attempted to install this RC on my 32bit UEFI Lenovo 100S which has been problematic with previous versions.

I've done some more testing with this obstreperous device so an update...

Balena Etcher (v1.5.81 portable on Windows 7) failed to produce a bootable USB stick from the ISO :-(.  Showed "ubuntu" twice in the F12 boot menu but both items booted the existing 4.8 install.

Using Rufus' "image copy" (i.e. dd equivalent) mode to flash the ISO produced identical results: same F12 boot menu behaviour as the Etcher flashed USB stick.  I've got a couple of other ideas to test to try and figure out what it isn't liking...

Rufus (v3.10 portable on Windows 7, default options) produced a USB drive that showed up as something like "USB UEFI Mass Storage" (didn't write down the exact text) in the F12 boot menu, which when selected booted up to the live environment from the USB drive (so the 32bit UEFI worked! Yay!).  Started installation and that went all the way through until a failure to grub-update the internal eMMC drive was reported.  I had selected to manually manage partitions so as not to disturb the existing partitioning arrangement (the ext4 & swap partitions were set for reformatting however reformatting the UEFI System partition was not offered as an option) so this may have contributed to the failure.

I've gone back and installed from my 32bit UEFI enabled 4.2 image using exactly the above process and that worked fine.  The 4.2 image was flashed with Rufus using default options (i.e. MBR partitioned file copy mode) as it was for the original 4.2 install.  I then attempted to install the 5.0RC1 image (also flashed to USB with Rufus' defaults) replicating exactly the same install steps and that fails as reported above.  I can only conclude that there is some difference in the installation process involving the final GRUB installation phase between the 4.2 image and the 5.0RC1 image.

I'm wondering whether it is trying to configure GRUB in Legacy/CSM mode rather than UEFI - i.e. the installer hasn't properly registered that this is a UEFI install - but failing because the drive is GPT partitioned??  The partitioning process seemed to recognise the ESP though and offers to use it, and there was nothing different in the observed behaviour of the 4.2 install vs the 5.0RC1 install that might support that hypothesis .

I'll do some more testing as I get the chance to try and figure out why this is going astray, because this failure is right at the last hurdle before rebooting into the installed system - so it's pretty close to being successful...