[Bug 254395] bsdinstall: fail script install after BETA3

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 23 Mar 2021 19:22:47 +0000
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

--- Comment #14 from commit-hook_at_FreeBSD.org ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=4601382e1362352f17a33e4ed38db5dcfe3f6be5

commit 4601382e1362352f17a33e4ed38db5dcfe3f6be5
Author:     Nathan Whitehorn <nwhitehorn_at_FreeBSD.org>
AuthorDate: 2021-03-23 13:19:42 +0000
Commit:     Nathan Whitehorn <nwhitehorn_at_FreeBSD.org>
CommitDate: 2021-03-23 19:21:33 +0000

    Fix scripted installs on EFI systems after default mounting of the ESP.

    Because the ESP mount point (/boot/efi) is in mtree, tar will attempt to
    extract a directory at that point post-mount when the system is installed.
    Normally, this is fine, since tar can happily set whatever properties it
    wants. For FAT32 file systems, however, like the ESP, tar will attempt to
    set mtime on the root directory, which FAT does not support, and tar will
    interpret this as a fatal error, breaking the install (see
    https://github.com/libarchive/libarchive/issues/1516). This issue would
    also break scripted installs on bare-metal POWER8, POWER9, and PS3
    systems, as well as some ARM systems.

    This patch solves the problem in two ways:
    - If stdout is a TTY, use the distextract stage instead of tar, as in
      interactive installs. distextract solves this problem internally and
      provides a nicer UI to boot, but requires a TTY.
    - If stdout is not a TTY, use tar but, as a stopgap for 13.0, exclude
      boot/efi from tarball extraction and then add it by hand. This is a
      hack, and better solutions (as in the libarchive ticket above) will
      obsolete it, but it solves the most common case, leaving only
      unattended TTY-less installs on a few tier-2 platforms broken.

    In addition, fix a bug with fstab generation uncovered once the tar issue
    is fixed that umount(8) can depend on the ordering of lines in fstab in a
    way that mount(8) does not. The partition editor now writes out fstab in
    mount order, making sure umount (run at the end of scripted, but not
    interactive, installs) succeeds.

    PR:             254395
    Approved by:    re (gjb)
    Reviewed by:    gjb, imp
    MFC after:      3 days
    Differential Revision:  https://reviews.freebsd.org/D29380

    (cherry picked from commit c2f16c595eb51c6e0cb6ece3f6f078d738019059)

 usr.sbin/bsdinstall/partedit/partedit.c | 39 +++++++++++++++++++++++++++++++++
 usr.sbin/bsdinstall/scripts/script      | 30 ++++++++++++++++++-------
 2 files changed, 61 insertions(+), 8 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tue Mar 23 2021 - 18:22:48 UTC

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