On 2021-03-19 15:55, Warner Losh wrote:
On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current@freebsd.org> wrote:
> On 20. Mar 2021, at 00:21, Yuri Pankov <yur...@yuripv.dev> wrote:
>
> Chris wrote:
>> On 2021-03-19 13:06, bugzilla-nore...@freebsd.org wrote:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
>>>
>>> Nathan Whitehorn <nwhiteh...@freebsd.org> changed:
>>>
>>> What |Removed |Added
>>>
----------------------------------------------------------------------------
>>>
>>> Severity|Affects Only Me |Affects Some People
>>> CC| |i...@freebsd.org
>>> Priority|--- |Normal
>>>
>>> --- Comment #6 from Nathan Whitehorn <nwhiteh...@freebsd.org> ---
>>> Thanks for the suggestion about the documentation -- I've updated the
>>> man page.
>>>
>>> The core problem here is that our tar can't extract archives to FAT32
>>> with
>>> default options, since it treats inability to set modification time as
>>> a fatal
>>> error and FAT32 doesn't let you do that on the root directory. As
>>> such, any
>>> file in the release tarballs can't be extracted to FAT32. For
interactive
>>> installations, the bsdinstall distextract tool, a CURSES-y frontend to
>>> libarchive, solves this by ignoring ctime/mtime errors.
>>>
>>> Some extra commentary on solutions, so it can be in one place.
>>> Possibilities
>>> are:
>>>
>>> 1. We drop /boot/efi from mtree. That will result in it not existing in
>>> base.txz, solving this issue, but will result in it not being in
>>> mtree. It will
>>> also leave in place an identical bug that will break scripted
>>> installation on
>>> bare-metal POWER8 and POWER9 systems, although that is a tier-2
platform.
>>>
>>> 2. We add an option to tar to ignore failure in setting ctime/mtime,
>>> like the
>>> interactive installer uses. This has the difficulty that the patch is
>>> hacky and
>>> would have to go through upstream.
>>>
>>> 3. We go back to using distextract for scripted installations as well
as
>>> interactive ones, reverting d7640440fb644fde697f62fdff0b55aa3a4d5ef7.
>>> This
>>> fixes this issue but will result in installation failures for scripted
>>> installs
>>> without a controlling tty. (It will also add nice progress bars to
>>> scripted
>>> installs).
>>>
>>> 4. We do --exclude /boot/efi when running tar, then mkdir -p it by hand
>>> afterward. This is incredibly hacky and otherwise essentially
>>> functionally
>>> equivalent to #1. Like #1, it will fix this issue and has no obvious
>>> functional
>>> downside, but leaves scripted installs bare-metal POWER8 and POWER9
>>> broken.
>>>
>>> 5. We patch the file system driver to (pretend to) allow setting times
>>> on the
>>> mount point. I don't want to do this, since I don't want to solve this
>>> in the
>>> kernel at RC3 and I don't like it pretending to do things it can't do.
>>
>> 6. (my favorite) do NOT require that the efi/ partition be in strictly
a
>> fat32 format. I mean fat32 is not strictly required as the format for
>> the efi
>> partition. It is simply _assumed_ to be the required format and as
>> such, the
>> one used in so many cases.
>
> Wrong, see "13.3 File System Format" in UEFI specification.
>
it is not as simple as that:)
13.3.1.1 is more specific:
=====================
The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the
EFI file system. What variant of EFI FAT to use is defined by the size of
the media. The rules defining the relationship between media size and FAT
variants is defined in the specification for the EFI file system.
We've also seen a few non-conformant systems where FAT12 support has been
removed, so there's also a bit of real-world experience that goes along
with reading the UEFI specification :(.
I suppose that may be part of where my understanding came from. I've
got a couple of "hackintoshes" that dual-boot OS X, and FreeBSD. Part of
the process was working with the EFI partition (ESP) to get recognition
of both OS's in the (EFI) boot menu, as well as getting the firmware
properly functional in both instances. I also draw from a long article
by a boot manager author whom insisted that fat32 was not a requirement.
I've not got the time ATM to dig up the article. But it had many pointers
to the EFI spec to prove the point. All of which I verified.
In any case, sorry for the noise if I'm wrong. I'll dig up my references
when I can find the time. :-)
--Chris
Warner
On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current@freebsd.org> wrote:
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
