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_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 :(. 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_at_freebsd.org> wrote:Received on Fri Mar 19 2021 - 22:45:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC