installation fails due to missing fat32 support

[janxkoci]

What Happened?

I was doing an "upgrade" from OS 6.1 to OS 7. By "upgrade" I mean fresh install, but the previous OS was Jólnir.

The installer failed in about 5 seconds after starting. After a few attempts I noticed the helpful terminal output - it was failing to prepare new partitions. So I went to the live session to look in GParted to see what's up. GParted showed 4 partitions - a boot partition formatted as fat32 (I think this should be EFI partition) and the main ext4 partition for the OS (shown with a lock icon btw) plus two small partitions marked as "unused".

Now, the fat32 partition had a warning in GParted saying that fat32 support is missing and I can install either dosfstools or mtools. The first was already present, so I installed the second one, just to be sure. But since I wasn't sure this would be preserved outside of the live session, I decided to remove the offending fat32 partition entirely, since the installer was gonna make new partitions anyway. So ultimately, I don't know if the package was needed, but some support for fat32 was apparently missing.

Long story short, removing the fat32 partition fixed the problem and installer was able to proceed. But it was unable to do it on its own - I had to have the knowledge necessary to fix the problem myself.

Steps to Reproduce

1. Have a fat32 partition before installing. I guess EFI partitions usually use this?
2. Boot the installation medium to start the installer.
3. When asked whether to try live session or install, choose "Erase disk and install".
4. The installer will fail within first few seconds, and offer trying again, starting live session, or powering down (thanks for this btw).

Expected Behavior

The existing fat32 partition should not pose a problem for the installer, it should be able to solve it without intervention.

Note also that the first failure rendered the device unbootable, as there was no working bootable partition afterwards. So maybe introduce some compatibility checks before you do anything, to prevent making devices unbootable.

OS Version

7.x (Horus)

Software Version

Older release (I have not run all updates)

Log Output

I don't have the logs from the installer nor the live session, sorry.

Hardware Info

Slimbook Essential 14 (came with elementary OS 5 preinstalled). The laptop had no issues upgrading from OS 5 to OS 6.1 (again, manual fresh install).

The installer was from the released ISO (file name ends with rc, as if it was just a release candidate, but your website doesn't offer any newer ISO) and so it might not have been the latest version.

[ealaney]

I encountered this when installing elementary OS 7.1 on a series of Dell Latitude 7390 laptops that had been set up with Windows 10. The existing Windows install, as well as my desired elementary OS install, were performed under UEFI, so the EFI vfat partition was present.

I found that the most reliable way to perform the install was to first select "Custom Install," then choose "Modify Partitions." When GParted appeared, I created a whole new GPT partition table on the SSD, then closed GParted and hit the "Back" button to the "Try or Install" screen. If I then selected "Erase Disk and Install," the installation would proceed with no problems.

I also found that if I connected to the internet, I could Ctrl+Alt+F1 into a command line session and sudo apt install mtools. That would provide the installer with the ability to read the fat32 / vfat EFI partition, but it wasn't reliable enough when installing 10 laptops to use that as my procedure. The installer would still have issues.