From owner-freebsd-stable@freebsd.org Wed Feb 24 19:59:04 2021 Return-Path: Delivered-To: freebsd-stable@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 DD80D567B41 for ; Wed, 24 Feb 2021 19:59:04 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dm6F35hRgz4ZFG for ; Wed, 24 Feb 2021 19:59:03 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from fomalhaut.potoki.eu ([IPv6:2001:470:71:d47:3c27:87e8:7a8c:c2d5]) (authenticated bits=0) by plan-b.pwste.edu.pl (8.16.1/8.16.1) with ESMTPSA id 11OJwwtv097432 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 24 Feb 2021 20:58:59 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1614196739; bh=myYojVAYJf6ZLleuJhmvNm1Wc+9KWhe/Pk6uyRNs4BY=; h=To:References:From:Subject:Date:In-Reply-To; b=UTvb1Kum0d1ikMECKYTgHU5gyJrIGzedQXa6FbEiS5E9zfpfsV8Tbaud4du+zU7p0 HpNhai8zK6lSHjAd4W9QL9MiJvrIqzMvhWn1AxB5hhdx4zcop+73TUBj9K9CaeYzCC CW8+h3ew3BhNiv6wGVYUwBDL8n9O7hJf0jIXgpjq3qtpCNCIWrLIfejk0kIszKqMpo WjTjO5Jtld5i01g6mfeyoxEJ/1Q9FAIzaUKA2atqbYR4YZOotWMlBGCsgGJXWdZ11p MYx1wZ5InVdjkeHCrxUeth+D/Lu/yTYv5YZRChKJUvJTM9T3JzlR4+7Sx/rhKs/y9o Q48xrjBwcVbpg== X-Authentication-Warning: plan-b.pwste.edu.pl: Host [IPv6:2001:470:71:d47:3c27:87e8:7a8c:c2d5] claimed to be fomalhaut.potoki.eu To: freebsd-stable@freebsd.org References: <909bf509b35ec1cda7b70c749edc6b75@dweimer.net> <0b5141137f69e2f86dd49edd4ffd1e78@dweimer.net> From: Marek Zarychta Subject: Re: 13-BETA3 installation from source problems. Message-ID: <95fdb726-7247-0d1a-3082-da1c2376ce1a@plan-b.pwste.edu.pl> Date: Wed, 24 Feb 2021 20:58:53 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Rspamd-Queue-Id: 4Dm6F35hRgz4ZFG X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=plan-b.pwste.edu.pl header.s=plan-b-mailer header.b=UTvb1Kum; dmarc=pass (policy=none) header.from=plan-b.pwste.edu.pl; spf=none (mx1.freebsd.org: domain of zarychtam@plan-b.pwste.edu.pl has no SPF policy when checking 2001:678:618::40) smtp.mailfrom=zarychtam@plan-b.pwste.edu.pl X-Spamd-Result: default: False [-5.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[plan-b.pwste.edu.pl:+]; DMARC_POLICY_ALLOW(-0.50)[plan-b.pwste.edu.pl,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:678:618::40:from]; ASN(0.00)[asn:206006, ipnet:2001:678:618::/48, country:PL]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[plan-b.pwste.edu.pl:s=plan-b-mailer]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[pwste.edu.pl:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2001:678:618::40:from:127.0.2.255]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-stable] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2021 19:59:04 -0000 W dniu 24.02.2021 o=C2=A020:03, Kyle Evans pisze: > On Wed, Feb 24, 2021 at 12:57 PM Dean E. Weimer w= rote: >> On 2021-02-23 12:34 pm, Kyle Evans wrote: >>> The more I look at `make -dm` output, the less sense it makes. Your >>> patch is decidedly correct regardless of how this specific scenario i= s >>> playing out: >>> >>> 1.) As you noted, it's wrong to clean something that's built >>> elsewhere. You can reasonably expect `make clean all` to work pretty >>> much everywhere else. >>> >>> 2.) i386/loader cannot make an informed decision about whether it's >>> out-of-date, which is sufficient to tell that the existing addition t= o >>> OBJS was not the correct implementation in hindsight. >>> >>> 3.) The failure mode if it's *missing* is exactly the same before and= >>> after your patch; file can't be found, cannot build it. >>> >>> On Tue, Feb 23, 2021 at 12:09 PM Warner Losh wrote: >>>> I'm unsure of the mechanics as well. I do know that we shouldn't >>>> delete stuff in OTHER directories, though. the btx stuff is trying t= o >>>> do a bit of an end run around the link only with the installed stuff= >>>> here and using crt0.o as a library from the 'where it was built' >>>> directory which I think creates one too many dependencies... I've no= t >>>> yet puzzled through all of them to find out which one is causing us = to >>>> think we need to rebuild though. >>>> >>>> Warner >>>> >>>> On Tue, Feb 23, 2021 at 9:21 AM Kyle Evans wrot= e: >>>>> Hi, >>>>> >>>>> What I don't understand here is, why are these being considered >>>>> out-of-date? That seems like it is indicative of a larger problem >>>>> that >>>>> we'd surely fall over elsewhere on if not for here, that the source= >>>>> tree's timestamps are post-dated w.r.t. the objdir. >>>>> >>>>> Thanks, >>>>> >>>>> Kyle Evans >>>>> >>>>> On Mon, Feb 22, 2021 at 5:52 PM Warner Losh wrote:= >>>>>> What does this patch do for you? >>>>>> >>>>>> diff --git a/stand/i386/loader/Makefile b/stand/i386/loader/Makefi= le >>>>>> index ad95948ec50a..cbbe15bd1fc0 100644 >>>>>> --- a/stand/i386/loader/Makefile >>>>>> +++ b/stand/i386/loader/Makefile >>>>>> @@ -90,7 +90,8 @@ FILES+=3D ${LOADER} >>>>>> FILESMODE_${LOADER}=3D ${BINMODE} -b >>>>>> >>>>>> # XXX crt0.o needs to be first for pxeboot(8) to work >>>>>> -OBJS=3D ${BTXCRT} >>>>>> +# Can't add it to OBJS w/o pain and suffering >>>>>> +LDFLAGS+=3D ${BTXCRT} >>>>>> >>>>>> DPADD=3D ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32} >>>>>> LDADD=3D ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32} >>>>>> >>>>>> Anything? >>>>>> >>>>>> Warner >>>>>> >>>>>> On Mon, Feb 22, 2021 at 4:17 PM Dean E. Weimer wrote: >>>>>> >>>>>>> On 2021-02-22 10:53 am, Dean E. Weimer wrote: >>>>>>>> On 2021-02-22 9:38 am, Dean E. Weimer via freebsd-stable wrote: >>>>>>>>> On 2021-02-22 9:29 am, Warner Losh wrote: >>>>>>>>> >>>>>>>>>> On Mon, Feb 22, 2021 at 8:24 AM Dean E. Weimer via freebsd-sta= ble >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I was able to successfully build and install BETA2 from sourc= e, >>>>>>>>>>> however >>>>>>>>>>> I am now attempting to upgrade the same machine to BETA3 buil= dworld >>>>>>>>>>> and >>>>>>>>>>> buildkernel complete. installkernel also completes, but insta= llworld >>>>>>>>>>> fails, it appears to not find a file for i386 boot. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> /jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/st= and/i386/btx/btx/btx >>>>>>>>>>> -l boot2.ldr -o boot2.ld -P 1 boot2.bin >>>>>>>>>>> make[6]: exec(btxld) failed (No such file or directory) >>>>>>>>>> Does this happen every time, or only sometimes? Do you have th= e >>>>>>>>>> complete log? Why we're trying to run btxld and objcopy in the= >>>>>>>>>> *INSTALL* phase is likely why (paths are different between the= two) >>>>>>>>>> >>>>>>>>>> Warner >>>>>>>>>> >>>>>>>>>>> mail to "freebsd-stable-unsubscribe@freebsd.org" >>>>>>>>> Everytime, not sure why I am trying to run btxld and objcopy in= >>>>>>>>> install phase, I am simply running the command make installworl= d >>>>>>>>> >>>>>>>>> I do use env variables to change paths, as I install to a ZFS c= lone of >>>>>>>>> the original system dataset then change boot setting on pool an= d >>>>>>>>> reboot. >>>>>>>>> >>>>>>>>> Environment Variables used during build and install, been doing= this >>>>>>>>> process ever since I started using ZFS boot on FreeBSD 9.2. >>>>>>>>> >>>>>>>>> setenv MAKEOBJDIRPREFIX /jails/devel/ROOT/usr/obj >>>>>>>>> setenv DESTDIR /jails/devel/ROOT >>>>>>>>> setenv __MAKE_CONF /jails/devel/ROOT/etc/make.conf >>>>>>>>> setenv SRCCONF /jails/devel/ROOT/etc/src.conf >>>>>>>> I had already started a new build specifying CPUTYPE=3Dsilvermon= t in >>>>>>>> make.conf, as attempt work around. It failed as well. I did chec= k and >>>>>>>> the path above exists on the system >>>>>>>> >>>>>>>> >>>>>>> :/jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/s= tand/i386/btx/btx >>>>>>>> # ll >>>>>>>> total 10 >>>>>>>> -rw-r--r-- 1 root wheel 117B Feb 22 10:13 .depend.btx.o >>>>>>>> -rwxr-xr-x 1 root wheel 1.7K Feb 22 10:37 btx* >>>>>>>> -rw-r--r-- 1 root wheel 5.4K Feb 22 10:13 btx.o >>>>>>>> drwxr-xr-x 2 root wheel 4B Feb 22 10:13 include/ >>>>>>>> >>>>>>>> I have removed my CPU Type specification and will run a new make= and >>>>>>>> install capturing full logs so that I can post a link to full lo= gs. >>>>>>> I did a new build and capture output from full buildworld and >>>>>>> installworld, but first I cleared ccache same error was a result.= >>>>>>> >>>>>>> Here is the entire output along with my make.conf and src.conf fi= les. >>>>>>> https://nextcloud.dweimer.net/index.php/s/YYx6WX7KieatM9L >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks, >>>>>>> Dean E. Weimer >>>>>>> http://www.dweimer.net/ >>>>>>> >>>>>> _______________________________________________ >>>>>> freebsd-stable@freebsd.org mailing list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freeb= sd.org" >> Do you guys know which part of my configuration is triggering this >> issue, so I can work around it for now? My last build attempt with the= >> latest updates for the security fixes failed to install even with patc= h. >> > I've been able to reproduce it locally with a stock config twice or > so, but it's non-trivial and only seems to reproduce with at least a > nullfs objdir. A good data point would be to point your > MAKEOBJDIRPREFIX at /jails/devel/host-usr-obj (assuming that's not > null-mounted) -- as long as you're still operating out of > /jails/devel/ROOT/usr/src, the paths relative to it will work out the > same. > > Thanks, > > Kyle Evans > _______________________________________________ I am hitting this very often on stable/13. If you are building world=20 WITH_META_MODE, then it can be worked around by making world again with=20 only one make job. --=20 Marek Zarychta