You are not logged in.
Pages: 1
Topic closed
Trying to create a fat32 partition on a new SSD for the efi. I partitioned a 150 M partition on /dev/sda1 and marked it as an EFI System with gdisk (ef00 code). When I try to format it to fat32 I get:
# mkfs.vfat -F32 /dev/sda1
mkfs.fat 3.0.20 (12 Jun 2013)
WARNING: Not enough clusters for a 32 bit FAT!
My EFI bios does not recognize the filesystem even though I copied over Shellx64.efi to it. Nothing on a google search of relevance. Anyone else hit this and solve it?
Last edited by graysky (2013-08-10 15:38:20)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
EFI is such a poorly implemented f*cking pain. Repeating this same procedure no less than 1 mo ago worked fine on identical hardware but now I had to add the following to my formatting step for reasons that baffle me (this is the solution):
mkfs.vfat -F32 -s 2 /dev/sda1
/hissy-fit
Last edited by graysky (2013-08-10 15:43:23)
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I am curious how you managed to find that solution to your problem? I mean, what lead you to think to specify the sector size at all?
FWIW, I have heard in the past that it is often not possible to make a FAT32 filesystem on anything less than a half a GB (512M). Though, I have been able to specify 'F32' on smaller without any kind of warning like what you have gotten. I am not sure what influences this (in)ability to do this, but from my experience I know that this filesystem size is not always a limitation.
These days, I just always make my ESP 512MB to 1024MB just for the sake of ensuring that I don't ever have to deal with that crap. Though I am fairly certain that my machine is fine with FAT16 as well, so I don't know that it would actually make a difference.
I'm not sure how you arrived at calling EFI poorly implemented, when in reality it is the FAT filesystem that you are battling. I'm not saying that I thnk that the implementation of UEFI is perfect, but it just seems that you are complaining about the wrong thing in that statement.
Offline
@Wonderwoofy - The solution was actually on this wiki page. What pisses me off is the inconsistency... I have partitioned 100 MB EFIs for a while now formatting them to fat32 via `mkfs.vfat -F32 /dev/target` with no issues. Why all of a sudden does it throw errors causing the BIOS to not recognize the partition? EFI is a mess if you asked me. Never had an issue with a "bios" setup before.
BTW, it looks like I have Intgr to thank for posting the solution to the wiki page on 05-Aug. Thank you, Intgr.
CPU-optimized Linux-ck packages @ Repo-ck • AUR packages • Zsh and other configs
Offline
I too would be interested i knowing what cases cause a system to be unable to format a FAT32 partition that is less than 512MB. It seems odd to me that I can heard numerous times of this being an issue, yet have never run into it myself.
I don't know that the actual UEFI spec is a mess so much as the implementation by the hardware vendors. Even in these cases, I still don't know if it is the UEFI that is causing the issues so much as the closed and buggy firmwares that are often shipped. It is unfortunate that the standard by which firmware is deemed acceptable is in its ability to successfully operate with windows... that same can be said about acpi.
Offline
I know this is super old, but I would like to add something here in case it helps people. I ran into this problem trying to format a tiny 20MB virtual disk as FAT32 to play around with creating a UEFI-enabled kernel.
Using the "-s 2" option would only help if mkfs.fat had chosen by default to use more than 2 sectors per cluster. The actual logic that mkfs.fat will use to make this decision is rather complicated, but it has to do with the size of the volume.
I was digging into the FAT specification from Microsoft which is actually referenced in the source for mkfs.fat (http://www.win.tue.nl/~aeb/linux/fs/fat/fatgen103.pdf) and the relevant piece of information is that the determining factor for FAT12/FAT16/FAT32 is entirely based on the number of clusters and nothing else.
The criteria is this:
If the number of clusters is less than 4085, it's a FAT12 volume.
If the number of clusters is at least 4085 and less than 65525, it's a FAT16 volume.
If the number of clusters is at least 65525, it's a FAT32 volume.
You can ask mkfs.fat to format a partition as FAT32 using the "-F32" option but if it's too small, it can't make a valid FAT32 volume. The minimum cluster size is 1 sector and FAT kind of requires a sector size of 512 bytes. The minimum number of FATs is 1. Since 65525 * 512 = 33548800, so that means that the volume has to have a minimum of just under 32M just for the data region plus just slightly under 256K for the FAT plus 32 sectors of reserved space at the start of the volume. The FAT size calculation is based on 4 bytes of space in the FAT per cluster.
Therefore, the minimum size for a FAT32 volume is about 32.25M. If you try to format a volume smaller than that with mkfs.fat, you're going to get this warning. You may be able to mount the volume in Linux, but UEFI firmware will likely not recognize the volume. QEMU UEFI firmware will not.
Offline
Mod note: closing this old, solved topic.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Pages: 1
Topic closed