Re: [Bug 254395] bsdinstall: fail script install after BETA3

> On 20. Mar 2021, at 00:21, Yuri Pankov <yuripv_at_yuripv.dev> wrote:
> 
> Chris wrote:
>> On 2021-03-19 13:06, bugzilla-noreply_at_freebsd.org wrote:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395
>>> 
>>> Nathan Whitehorn <nwhitehorn_at_FreeBSD.org> changed:
>>> 
>>>            What    |Removed                     |Added
>>> ----------------------------------------------------------------------------
>>> 
>>>            Severity|Affects Only Me             |Affects Some People
>>>                  CC|                            |imp_at_FreeBSD.org
>>>            Priority|---                         |Normal
>>> 
>>> --- Comment #6 from Nathan Whitehorn <nwhitehorn_at_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.

=====================

rgds,
toomas