From owner-freebsd-current@freebsd.org Fri Mar 19 22:49:15 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D1E9C5AF511 for ; Fri, 19 Mar 2021 22:49:15 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2Jwq4V4Dz4WG0 for ; Fri, 19 Mar 2021 22:49:15 +0000 (UTC) (envelope-from tsoome@me.com) Received: by mailman.nyi.freebsd.org (Postfix) id 9A12E5AF409; Fri, 19 Mar 2021 22:49:15 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 99CF65AF243 for ; Fri, 19 Mar 2021 22:49:15 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-tydg10021701.me.com (pv50p00im-tydg10021701.me.com [17.58.6.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F2Jwp2DQ4z4WRg for ; Fri, 19 Mar 2021 22:49:14 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-tydg10021701.me.com (Postfix) with ESMTPSA id C3F6684021A for ; Fri, 19 Mar 2021 22:49:11 +0000 (UTC) From: Toomas Soome Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: [Bug 254395] bsdinstall: fail script install after BETA3 Date: Sat, 20 Mar 2021 00:49:09 +0200 References: <2132088f8d7addba911e3f49fc674e1b@bsdforge.com> <024a371e-a57d-9b94-b85a-e8b59be76a22@yuripv.dev> To: current@freebsd.org In-Reply-To: <024a371e-a57d-9b94-b85a-e8b59be76a22@yuripv.dev> Message-Id: <28321ED9-BFAF-434A-9E3E-07932A3B4863@me.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-19_12:2021-03-19, 2021-03-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2103190157 X-Rspamd-Queue-Id: 4F2Jwp2DQ4z4WRg X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.6.54:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[me.com]; ASN(0.00)[asn:714, ipnet:17.58.0.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_NEUTRAL(0.00)[17.58.6.54:from]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[17.58.6.54:from]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[17.58.6.54:from:127.0.2.255]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[current] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2021 22:49:15 -0000 > On 20. Mar 2021, at 00:21, Yuri Pankov wrote: >=20 > Chris wrote: >> On 2021-03-19 13:06, bugzilla-noreply@freebsd.org wrote: >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254395 >>>=20 >>> Nathan Whitehorn changed: >>>=20 >>> What |Removed |Added >>> = --------------------------------------------------------------------------= -- >>>=20 >>> Severity|Affects Only Me |Affects Some People >>> CC| |imp@FreeBSD.org >>> Priority|--- |Normal >>>=20 >>> --- Comment #6 from Nathan Whitehorn --- >>> Thanks for the suggestion about the documentation -- I've updated = the >>> man page. >>>=20 >>> 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. >>>=20 >>> Some extra commentary on solutions, so it can be in one place. >>> Possibilities >>> are: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> 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. >=20 > Wrong, see "13.3 File System Format" in UEFI specification. >=20 it is not as simple as that:) 13.3.1.1 is more specific: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D rgds, toomas