UEFI Boot Issues with VFAT32 vs VFAT16
by jwings from LinuxQuestions.org on (#59V8H)
I have been a long time user of Linux (dating back to loading 20 floppies!!).
My latest project has been to update my hardware to the low power processor boards and updating the OS to centos 7.8. For the most part the process has been smooth with only a few issues.
However, I made at attempt to make multiple copies of a system disk to avoid the longer install process (and the longer process of finding all the things need to mesh into my network system.) The process actually works quite well, with only a few patches needed to make the new clone disk work.
The big issue came when I tried to learn/use the EFI boot system rather than the old MBR version. I used gparted to create the disk on an SSD drive. The root partition was ext4, but I decided (for whatever reason!) to make the EFI partition vfat32 rather than the VFat16 as the installer did. The result was about three days of major frustration with getting the system to boot as it should.
---------------
Short version: the board is an ASRock 4050 mini-itx with 8 GiB mem and an 8GiB SSD.
Using the fat32, the board BIOS was never able to find the EFI partion. Once the SSD partion was changed to fat16 and the proper GRUB cfg was created, all went as planned.
-----------------
The Question: According to all of the UEFI specs I can find, the partition can be any variety of the FAT versions. Is this a bug? an ASRock bios issue? a GRUB configuration?
(I did find one forum question (RHEL?) that indicated the 'bug' in the installer that required the use of the partition 1 rather than MBR to get the proper installer - dos vs efi. That is the case here, as indicated by the refusal of anaconda to create the grub.cfg file for the efi version).
Any insight into this issue would be greatly appreciated.
Julianne
My latest project has been to update my hardware to the low power processor boards and updating the OS to centos 7.8. For the most part the process has been smooth with only a few issues.
However, I made at attempt to make multiple copies of a system disk to avoid the longer install process (and the longer process of finding all the things need to mesh into my network system.) The process actually works quite well, with only a few patches needed to make the new clone disk work.
The big issue came when I tried to learn/use the EFI boot system rather than the old MBR version. I used gparted to create the disk on an SSD drive. The root partition was ext4, but I decided (for whatever reason!) to make the EFI partition vfat32 rather than the VFat16 as the installer did. The result was about three days of major frustration with getting the system to boot as it should.
---------------
Short version: the board is an ASRock 4050 mini-itx with 8 GiB mem and an 8GiB SSD.
Using the fat32, the board BIOS was never able to find the EFI partion. Once the SSD partion was changed to fat16 and the proper GRUB cfg was created, all went as planned.
-----------------
The Question: According to all of the UEFI specs I can find, the partition can be any variety of the FAT versions. Is this a bug? an ASRock bios issue? a GRUB configuration?
(I did find one forum question (RHEL?) that indicated the 'bug' in the installer that required the use of the partition 1 rather than MBR to get the proper installer - dos vs efi. That is the case here, as indicated by the refusal of anaconda to create the grub.cfg file for the efi version).
Any insight into this issue would be greatly appreciated.
Julianne