From owner-freebsd-stable@freebsd.org Wed Feb 24 19:46:01 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 6402E5677BE for ; Wed, 24 Feb 2021 19:46:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 4Dm5y11d94z4Y89 for ; Wed, 24 Feb 2021 19:46:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82f.google.com with SMTP id s15so2391724qtq.0 for ; Wed, 24 Feb 2021 11:46:01 -0800 (PST) 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=UwKi9RM6qeN8pFgl/tSqMWpmfpxdAfZdQx7wUjkEapw=; b=cdzHvkdpgNhv+KR1IccKeMr1+lQI7WGUSXO5x/1qONp4rn2sSben73PZdjA74QRpFh 67AeSX1TShKgoBgGHSGyn2yI/P8vPrCrVf8JW4LRp+qldakfrAEsmxtSA3eLG0SP5dIk hP5julhkfCcNaeRyKxwcsQsz4EvD9Gu7lSn8ngiJMebdmJEb4ymCVHMfJ1NfSJ68qzAD LERmaaxEZSfj5lQ2b1ExwcvcyrkdUfG8k//8gt9/mOuFyVjGuxvg1nCzgYeDGI5u9WWK BhOs4OvUeo1kZv2faUiS3p8JDoIw8cEQvFlhYek1YgFhKzo8nJLG5SNUBrGqzon/57if 0HOA== 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=UwKi9RM6qeN8pFgl/tSqMWpmfpxdAfZdQx7wUjkEapw=; b=uPJnwXNb4OuWZIMRb4M1hv1dKcT0QWhGh5ZCvSuwh37+YDWmAHYdVXtopTjxMrMU9Q 3eNtL2JwF+7W3ohbZBqqY+XK4d4S10mt3S5KjCWgYgtRHNz5K2qS6iSYTyCG7+MSKIO6 JYNLtk4rOcXGZrBpomEuJYeAfzFK1JYb6v/2o+gwFW79A3LbxHScY7UUrkV9TOEUMvCY rMTN+DlI+C9VF4xGAZK7DX9w4zgUBSevCrJ/d/FancrstTDF7pMn8SbEkeOUrdT1o2aQ SvXOeTJPNeQO/0PGoDjp4KJmwhCLu5ywUJ2K38Xb7sNBx60SzW5up+pIS8cFvS0nPbie 9kzA== X-Gm-Message-State: AOAM533tsQjiXXajc1xTtyDZtXEaln5otr9dTGcjVKQg2brrdlWK2jo9 fnbNWSGrKB5O8FDQqK4Q9AN+MfKkM4m0dmda2mTsdw== X-Google-Smtp-Source: ABdhPJx1p6k5l5PHNoiAs5k+jzWs3qvHKQezeqHrVccHRJnwKafU5K6Nboaoyyrp5cGH2jLBlwQQXfgjyRw8CLKL8to= X-Received: by 2002:a05:622a:90:: with SMTP id o16mr29875867qtw.49.1614195959787; Wed, 24 Feb 2021 11:45:59 -0800 (PST) MIME-Version: 1.0 References: <909bf509b35ec1cda7b70c749edc6b75@dweimer.net> <0b5141137f69e2f86dd49edd4ffd1e78@dweimer.net> In-Reply-To: From: Warner Losh Date: Wed, 24 Feb 2021 12:45:48 -0700 Message-ID: Subject: Re: 13-BETA3 installation from source problems. To: Kyle Evans Cc: dweimer@dweimer.net, FreeBSD Stable X-Rspamd-Queue-Id: 4Dm5y11d94z4Y89 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-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:46:01 -0000 Also doing ls -lR from the obj sir for stand before and after installworld might preserve data that may help. Warner On Wed, Feb 24, 2021, 12:04 PM Kyle Evans wrote: > On Wed, Feb 24, 2021 at 12:57 PM Dean E. Weimer > wrote: > > > > 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 is > > > 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 to > > > 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 to > > >> 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 not > > >> 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 > wrote: > > >>> > > >>> 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/Makefile > > >>> > index ad95948ec50a..cbbe15bd1fc0 100644 > > >>> > --- a/stand/i386/loader/Makefile > > >>> > +++ b/stand/i386/loader/Makefile > > >>> > @@ -90,7 +90,8 @@ FILES+= ${LOADER} > > >>> > FILESMODE_${LOADER}= ${BINMODE} -b > > >>> > > > >>> > # XXX crt0.o needs to be first for pxeboot(8) to work > > >>> > -OBJS= ${BTXCRT} > > >>> > +# Can't add it to OBJS w/o pain and suffering > > >>> > +LDFLAGS+= ${BTXCRT} > > >>> > > > >>> > DPADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32} > > >>> > LDADD= ${LDR_INTERP32} ${LIBFIREWIRE} ${LIBI386} ${LIBSA32} > > >>> > > > >>> > Anything? > > >>> > > > >>> > Warner > > >>> > > > >>> > On Mon, Feb 22, 2021 at 4:17 PM Dean E. Weimer < > dweimer@dweimer.net> 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-stable > > >>> > > >>> wrote: > > >>> > > >>> > > >>> > > >>>> I was able to successfully build and install BETA2 from > source, > > >>> > > >>>> however > > >>> > > >>>> I am now attempting to upgrade the same machine to BETA3 > buildworld > > >>> > > >>>> and > > >>> > > >>>> buildkernel complete. installkernel also completes, but > installworld > > >>> > > >>>> fails, it appears to not find a file for i386 boot. > > >>> > > >>>> > > >>> > > >>>> > > >>> > > >>>> > > >>> > > > /jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/stand/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 > the > > >>> > > >>> 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 > installworld > > >>> > > >> > > >>> > > >> I do use env variables to change paths, as I install to a ZFS > clone of > > >>> > > >> the original system dataset then change boot setting on pool > and > > >>> > > >> 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=silvermont in > > >>> > > > make.conf, as attempt work around. It failed as well. I did > check and > > >>> > > > the path above exists on the system > > >>> > > > > > >>> > > > > > >>> > > > :/jails/devel/ROOT/usr/obj/jails/devel/ROOT/usr/src/amd64.amd64/stand/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 > logs. > > >>> > > > > >>> > > 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 > files. > > >>> > > 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@freebsd.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 patch. > > > > 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 >