From owner-freebsd-current@freebsd.org Sat Mar 20 00:22:47 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 2A5275B1FA0 for ; Sat, 20 Mar 2021 00:22:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4F2M0k5sV7z4cxP for ; Sat, 20 Mar 2021 00:22:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id C93585B2105; Sat, 20 Mar 2021 00:22:46 +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 C8F7A5B20D4 for ; Sat, 20 Mar 2021 00:22:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F2M0k4Vlpz4d0v for ; Sat, 20 Mar 2021 00:22:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf2c.google.com with SMTP id j17so5887782qvo.13 for ; Fri, 19 Mar 2021 17:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U+c0gxhD7XPv5+qU2/vWsPSe74ik76UBkmJa+/DeJes=; b=dkbg9a3bVUydRzN5Mw17/4N7gogbFPA1ujeRl7F4UfPDSmX7ZCz03Jk72uZL9vdeTv wCZVUUnMDWoMHj9/zDQX91d74fRMVs0Zewyivq63JsR9nCLJi8XRM0bpOK0rg+IwdNk9 e8ECvzw6hK8trGinieySUSrL4rnbplxWdBJCtION/fqP67X49jDoJhNPxwHHIQPr2LOt x/t5UiMJsPlO3cExfL2xjDf4njb08QYlF9x9AWbE0REYExyFV5e2AfjvetnZ6tHNw+nA 53NRTFJOIt+YRPQh9D92Ywvuf4H/mlxkUJjV60qpw1PKJxzjcfU+zx0KCExIyigFyvvf T8AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U+c0gxhD7XPv5+qU2/vWsPSe74ik76UBkmJa+/DeJes=; b=Ik22swjAjzTwBmS33Kcic/gquzYW5gWRBUvE6zRGpgJHJnAmr0lLne6plAFpcScPZ+ depvE0vPcpagzywdUWfGZL1l8tzeL7Mwq3LjuTucCsSBAckQ4pDzzDVLiWKWoUgLsUni 4rbLJO9KTGwV59xnv+CiRSVVxNl2i6Cz2bfrn7T/uB+yRj+4PYm/VOZ/aKh7bk50jWAa dsIqNWoMjMhQaAtqpyGTNIRRBUx58ZsNI1MTQokeeHGFSj0psMw3hEmdLFx4DcbpqLDV 46SiWQE5jTxMYgsS8xX1ZV5sRWFKFXNTXNh5Cmw4d1cY2rkXA/C04+PcXoLBWS3PmEAY 8qwg== X-Gm-Message-State: AOAM533eTiepVTHDRCWjzlMcYpkEZf5IF0sNiKRSl9BVijwOHNXJeLM2 tJVUyoxUjY3PtAY1x54/ARq1zpwOIO/BpgDoySAc0A== X-Google-Smtp-Source: ABdhPJxSZ72iGcrPVGLnuf1nQP3rS/11/af3AysZOw1YZ5rZh77efMCbwt5ZrbpoPMnP5PuKlIwcSILfQNrDShSmTxc= X-Received: by 2002:a0c:8623:: with SMTP id p32mr11822983qva.23.1616199765357; Fri, 19 Mar 2021 17:22:45 -0700 (PDT) MIME-Version: 1.0 References: <2132088f8d7addba911e3f49fc674e1b@bsdforge.com> <024a371e-a57d-9b94-b85a-e8b59be76a22@yuripv.dev> <28321ED9-BFAF-434A-9E3E-07932A3B4863@me.com> <90f9503e7f82aabb4041fc8786e840a5@bsdforge.com> In-Reply-To: <90f9503e7f82aabb4041fc8786e840a5@bsdforge.com> From: Warner Losh Date: Fri, 19 Mar 2021 18:22:34 -0600 Message-ID: Subject: Re: [Bug 254395] bsdinstall: fail script install after BETA3 To: Chris Cc: Toomas Soome , FreeBSD Current X-Rspamd-Queue-Id: 4F2M0k4Vlpz4d0v X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" 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: Sat, 20 Mar 2021 00:22:47 -0000 On Fri, Mar 19, 2021 at 5:45 PM Chris wrote: > 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@freebsd.org> wrote: > > > >> > >> > >> > On 20. Mar 2021, at 00:21, Yuri Pankov wrote: > >> > > >> > Chris wrote: > >> >> On 2021-03-19 13:06, bugzilla-noreply@freebsd.org wrote: > >> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395 > >> >>> > >> >>> Nathan Whitehorn changed: > >> >>> > >> >>> What |Removed |Added > >> >>> > >> > ---------------------------------------------------------------------------- > >> >>> > >> >>> Severity|Affects Only Me |Affects Some People > >> >>> CC| |imp@FreeBSD.org > >> >>> Priority|--- |Normal > >> >>> > >> >>> --- Comment #6 from Nathan Whitehorn --- > >> >>> 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. :-) > FAT32 appears to work the most places, even if it isn't a de-facto requirement. FAT16 is a close second (I think only one instance where the BIOS couldn't cope), while FAT12 is missing in a surprising number of implementations that's ever changing... I read the same text years ago that said all three are fine, but experience since then suggests more caution when setting the defaults for an installer. Warner > --Chris > > > > Warner > > > > On Fri, Mar 19, 2021 at 4:49 PM Toomas Soome via freebsd-current < > > freebsd-current@freebsd.org> wrote: >