Date: Wed, 24 Feb 2021 13:03:44 -0600 From: Kyle Evans <kevans@freebsd.org> To: dweimer@dweimer.net Cc: Warner Losh <imp@bsdimp.com>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: 13-BETA3 installation from source problems. Message-ID: <CACNAnaGFcXHh5w=6Y9Q_aKVc5=ARwVsCBJ3U1nZgZgH%2BPh=6NQ@mail.gmail.com> In-Reply-To: <cbd20ea91b0c7dbc758ea4e4cee5dff5@dweimer.net> References: <b75040cf0985c0582dbe4d82143adc7b@dweimer.net> <CANCZdfor02pyBnYsPviqOuPKMLabUCczSf8Z--u2j6kU5jj%2BUQ@mail.gmail.com> <909bf509b35ec1cda7b70c749edc6b75@dweimer.net> <df551839bde8a440e2917779d949933c@dweimer.net> <0b5141137f69e2f86dd49edd4ffd1e78@dweimer.net> <CANCZdfpYnYsqwriuJUmXB1M5RMYMGB08hvQQZavyOaGuUDh0eg@mail.gmail.com> <CACNAnaHm-2cu4C2pOspG4eeCEP5Zmom_fTWMRgqL962tHoTw0A@mail.gmail.com> <CANCZdfpQUtPpyFYgVEke1jFpDJUne1LVS%2B0ncHFWozArfs2WQQ@mail.gmail.com> <CACNAnaF6_vXKEk-auxr_zvu=q6ywvY=ndhWkg0VyW66GGAc4pw@mail.gmail.com> <cbd20ea91b0c7dbc758ea4e4cee5dff5@dweimer.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 24, 2021 at 12:57 PM Dean E. Weimer <dweimer@dweimer.net> 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 <imp@bsdimp.com> 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 <kevans@freebsd.org> 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 <imp@bsdimp.com> 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 > >>> > > >>> <freebsd-stable@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaGFcXHh5w=6Y9Q_aKVc5=ARwVsCBJ3U1nZgZgH%2BPh=6NQ>