FAT16 not supported for EFI partition, system refused to boot with Invalid Image error

[per-bohlin]

I ran into an issue where the UEFI failed to boot an installed system due to FAT16 in the EFI partition where only FAT32 was supported.

When booting it gave the error:

Invalid image
Failed to read header: Unsupported
Failed to load image: Unsupported
start_image() returned Unsupported

System Details:

• Hardware: Dell Precision Tower 3420
• BIOS/UEFI version: 2.15.0
• Drive: 3TB disk with GPT partition table
• Elemental Toolkit version: v2.1.0+gc7885a2

We have a custom image and have built an ISO installer. After booting the ISO from a USB stick and run sudo elemental install /dev/sda, the EFI-partition on sda (sda1) is of type FAT16.
FAT16 was not supported by the BIOS/UEFI. After manually converting the EFI-partition to FAT32 and adding it as an EFI boot entry the system was able to boot.

Questions:

• Are there an official way to force elemental install to create FAT32 partition instead of FAT16 for the EFI-partition?
• If no, are there any plans to switch to FAT32 instead of FAT16?
• or add an install option similar to --efi-fat32 to the elemental install command?

Thank you for making elemental-toolkit. It is an awesome contribution to the software community.

For others who run into this issue, this is an outline of what I did to resolve it. In my case it was for device /dev/sda and will be used as an example. I'm writing from memory so it might contain mistakes (use with care):

1. Do the installation: sudo elemental install /dev/sda
2. Collect information: sudo parted -l && sudo lsblk && sudo efibootmgr
3. Mount the EFI partition: sudo mkdir /tmp/efi && sudo mount /dev/sda1 /tmp/efi
4. Make a backup of the EFI content: sudo cp -r /tmp/efi /tmp/efi.bak
5. Unmount: sudo umount /tmp/efi
6. Format as FAT32: sudo mkfs.fat -F 32 -n "COS_GRUB" /dev/sda1
7. Restore content: sudo mount /dev/sda1 /tmp/efi && sudo cp /tmp/efi.bak/* /tmp/efi/ && sudo umount /tmp/efi
8. Add EFI boot entry (make sure that it matches the entry seen in the information collection stage above): sudo efibootmgr -c -d /dev/sda -p 1 -L "elemental-shim" -l "\EFI\ELEMENTAL\shimx64.efi"
9. Check boot-order: sudo efibootmgr

[frelon]

Hi @per-bohlin!

Glad to hear you are using elemental!

I'm not sure why we picked fat16 as the default for fat/vfat file systems, but I would not be opposed to changing that default.

If you want to prepare a PR I would be happy to review and test! 👍

[per-bohlin]

Hi @frelon ,
Thank you for the quick reply.

I will give it a try, but I can't commit to a timeline.
Do you prefer a straight out replacement, or making it configurable? In case of configurable, any specific mechanism that you want me to use? Please keep in mind that I've never looked at the code base before and I'm a fairly new user of elemental itself.

[frelon]

Hi @frelon , Thank you for the quick reply.

I will give it a try, but I can't commit to a timeline. Do you prefer a straight out replacement, or making it configurable? In case of configurable, any specific mechanism that you want me to use? Please keep in mind that I've never looked at the code base before and I'm a fairly new user of elemental itself.

That's totally ok! I would prefer it to be configurable.

The current code actually has support for passing parameters to the mkfs call, but we don't actually have anywhere to store them for the partition configuration.

Once we have a way to store the flags it should be enough to pass them to the FormatDevice call.

We will also need to actually set the options in the default install config.

Phew, hopefully that should be everything! Let me know if you run into any trouble! 👍

[per-bohlin]

Thanks again. I think I have all the information I need for now.

[davidcassany]

I'm not sure why we picked fat16 as the default for fat/vfat file systems, but I would not be opposed to changing that default.

I am not sure we actively choose that. mks.vfat might make the choice for us depending on the size of the volume. IIRC under 512MB or similar it chooses FAT16. Also I think I have seen the other side of the story too, not booting if the installation is based on FAT32, but booting if it is FAT16. I do not remember the details and use case, but I remember being in that trap of FAT16 vs FAT32 🤔 So I'd definitely vote for a configurable solution.