Date: Wed, 24 Feb 2021 20:58:53 +0100 From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: freebsd-stable@freebsd.org Subject: Re: 13-BETA3 installation from source problems. Message-ID: <95fdb726-7247-0d1a-3082-da1c2376ce1a@plan-b.pwste.edu.pl> In-Reply-To: <CACNAnaGFcXHh5w=6Y9Q_aKVc5=ARwVsCBJ3U1nZgZgH%2BPh=6NQ@mail.gmail.com> 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> <CACNAnaGFcXHh5w=6Y9Q_aKVc5=ARwVsCBJ3U1nZgZgH%2BPh=6NQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
W dniu 24.02.2021 o=C2=A020:03, Kyle Evans pisze:
> On Wed, Feb 24, 2021 at 12:57 PM Dean E. Weimer <dweimer@dweimer.net> 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 <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 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 <kevans@freebsd.org> 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 <imp@bsdimp.com> 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 <dweimer@dweimer.ne=
t> 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
>>>>>>>>>> <freebsd-stable@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?95fdb726-7247-0d1a-3082-da1c2376ce1a>