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

From: Warner Losh <imp_at_bsdimp.com>
Date: Fri, 19 Mar 2021 16:55:55 -0600
On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current_at_freebsd.org> wrote:

>
>
> > 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.
>

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 :(.

Warner

On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current <
freebsd-current_at_freebsd.org> wrote:

>
>
> > 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
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Fri Mar 19 2021 - 21:56:07 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC