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. > Whould it actually be that much harder to use ffs/ufs? > > You asked. ;-) > >> >> -------- >> >> Of these, 1, 3, and 4 are quite easy to implement, but all have some >> downside. >> My temptation is to do 4 for 13.0, since it will definitely work but >> is just >> lame, then either do #2 or a variant on #3 where distextract notices >> there is >> no tty and doesn't try to set up a dialog as a longer-term fix in >> HEAD. Any >> thoughts?Received on Fri Mar 19 2021 - 21:21:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC