Re: /boot/efi size, 260MiB minimum for FAT32 ESP) -- WAS: /boot size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Chris Murphy wrote:
> Well, mkdosfs defaults to FAT16 and 4K cluster size on a 200M
> partition, so that should continue to work, even though the UEFI spec
> says to use FAT32 on system partitions. So chances are doing nothing
> isn't going to break anything.

Understood.  And I've even verified at least the Windows 7 installer
seems to use a FAT16 just fine, while Windows 8 will still boot from
it (didn't try installing to one with Windows 8).

I haven't had much time with Windows 10.

> In practice, both Windows and OS X use FAT32, but they also use
> cluster sizes smaller than 4K. Presumably both of them will transition
> to 256+M EFI system partitions, rather than use FAT16.

My apologies if I wasn't clear (I should have used the term "sector") ...

A storage device, of 4KiB [logical] _sector_ (correcting my prior,
inappropriate use of "block") _forces_ a 4KiB+ block/cluster size, so
260MiB now becomes the minimum FAT32.  We're now seeing some systems
where new Windows 10 systems use 4KiB logical sector size.

> https://bugzilla.redhat.com/show_bug.cgi?id=1046577
> https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
> https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/
> and maybe
> https://www.redhat.com/archives/anaconda-devel-list/2014-July/msg00002.html

Okay, I see you there.  Thanx for pointing this out!  ;)

> Ideally there'd be an -E flag for mkdosfs to deal with this.

Indeed, that would take it out of the hands of Anaconda et al., and
put it in the tool.  That way the tool can be changed, and everything
downstream using it modified.

> The UEFI spec says firmware is expected to support FAT32, FAT16,
> and FAT12 so it probably doesn't matter that the spec also says the
> system partition (non-removable) should be FAT32, where only
> removables get FAT16 or FAT12. The other thing -E would make
> possible is ensuring the proper invariant "EFI file system" is what's
> actually being created, rather than pure FAT.

I like Garrett's comments.  ;)

If there is a spec that says one thing for one, another thing for
another, we might run into a case of such implementation, and suddenly
an uEFI implementation that doesn't like FAT16 for an ESP.

Murphy's Law.

How Anaconda deals with this possible issue, I don't know.  But given
today's disk sizes, and how 4KiB physical is common, while 512B
logical only remains because BOOTMGR was ignorant originally (let
alone NTLDR has always been), I'm not sure we're doing the right
thing, long-term.

-- bjs

<off-topic>
In any case, and I don't expect Anaconda to be the place where this
"greater issue" ever gets addressed ...

But with Windows x64 version 7, 8 and 10 OEM guides recommending the
#1 and #2 partitions to be the ESP + Reserved partitions (ignoring the
separate "Tools" partition in 8 and 10), I've pretty much solved it by
using the first 0.5GiB as follows ...

  1 - 384MiB (383MiB), EF00h, EFI System Partition (esp)
384 - 512MiB (128MiB), 0C01h, Microsoft Reserved (msftres)

With regards to the ESP, using an 383MiB (starting at 1MiB, sector
2048 for 512B, 256 for 4KiB) solves the problem altogether.  There
shouldn't ever be any issue.  I can also load up a shell, tools and
other things, which would be cool for a distro to offer (assuming they
can be distributed.  I'm even partial to rEFInd, which I'd love to see
a distro ship as an option, because it solves so many multi-boot
issues, but that's another story.

With regards to the MS Reserved, if I do a Google research, everyone
keeps assuming the 2nd is unused, yet I've done some hexdumps and
found bytes _do_ go in there, especially if Windows is installed on
the same system (still trying to find a case where just reading the
disk in Windows does similarly).  I'd also love to see the option to
create this as the #2 partition in a new GPT disk label, in an
installer, if the system is also going to be multibooting with Windows
x64.

But again, I understand this is really outside the realm of Anaconda.
</off-topic>

--
Bryan J Smith  -  http://www.linkedin.com/in/bjsmith
E-mail:  b.j.smith at ieee.org  or  me at bjsmith.me

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list



[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux