Re: Panic while making buildlernel on RPi3

On 2022-Mar-5, at 11:11, Mark Millard <marklmi@yahoo.com> wrote:

> On 2022-Mar-5, at 07:37, bob prohaska <fbsd@www.zefox.net> wrote:
> 
>> On Fri, Mar 04, 2022 at 10:51:00PM -0800, Mark Millard wrote:
>>> On 2022-Mar-4, at 20:30, bob prohaska <fbsd@www.zefox.net> wrote:
>>> 
>>>> On Fri, Mar 04, 2022 at 05:36:20PM -0800, Mark Millard wrote:
>>> 
>>> Are you going to do the official-builds-on-microsd-card
>>> sorts of boot and try tests that I've suggested, such as a
>>> 13.1-PRERELEASE (snapshot) test? (This avoids your having
>>> built anything tested and all but whatever minimal
>>> configuration that you need to do to allow the test.)
>>> 
>> Yes, after stable/13 settles down a bit. This failure was on
>> -current. 

I recommended a temporary experiment on independent media.
Why would settling be important? If you want 13.1 to
address the issue (if it has it), the earlier the better
for discovering if it has the problem in official builds
with minimal local adjustments to allow the test.

Side note: stable/13 now has the greatly improved OOM
kill messaging and so is unlikely to be misleading in
notices about such.

> I had also recommended doing the same sort of thing
> with a 14-CURRENT snapshot: both tests.
> 
>>> Getting a failure from such an installation of official
>>> installation materials might be more likely to lead to
>>> getting help isolating the issue. 
> 
> That also applies to 14-CURRENT.
> 
>> Understood. At this point I have two RPI3 systems which
>> exhibit the same problem (faulty ping response). One has
>> followed stable/13 (which had the clang errors you helped
>> with), the other has tracked -current.  
>> 
>>> [Back to the Subject line's issue . . .]
>>> 
>>>> I've been using -DWITH_META_MODE as a default setting for buildworld and 
>>>> buildkernel. Might this be part of my  problems with the Pi3's ? 
>>> 
>>> NO_CLEAN is more likely to have the result messed up: it
>>> does less dependency checking and can miss more that should
>>> be rebuilt/relinked.
> 
> I should also have referenced WITHOUT_CLEAN these days.
> 
>>> WITH_META_MODE is likely to rebuild more than NO_CLEAN, and
>>> so, less likely to include stale material.
>>> 
>>> Without special knowledge of the details of what all needs to
>>> be rebuilt at the time, WITH_META_MODE is normally safer.
>> 
>> I note with interest that you say "safer", not safe.
> 
> The Makefiles themselves can still have problems. WITH_META_MODE
> notes more dependencies (for next time) than the Makefile is
> explicit about. But there can be other types of special handling
> at transition points that Makefiles are responsible for. That
> includes dealing with new dependencies that prior WITH_META_MODE
> activity could not have seen yet for future use and dependencies
> that existed before but that WITH_META_MODE has not yet recorded
> a new lack of a dependency yet. Frequently such is handled by
> extra clean-like activity that forces certain things to rebuild
> based on just the older dependency information or dependencies
> that Makefile* themselves would detect.
> 
> Also, files that are no longer intended to be used can hang
> around and potentially be accidentally used.
> 
>> How do the
>> various cleaning targets described in the build manpage compare?
>> There's clean, cleandir and cleandepend, along with rm -rf /usr/obj.
>> It appears cleandir run twice is equivalant to combined clean and
>> rm -rf /usr/obj. I've not tried cleandepend yet, might it help?
> 
> I happen to do rm -rf explicitly.
> 
> clean and cleandepend serve different purposes. cleandir done
> twice includes doing an effective clean and cleandepend at
> least once. There is also cleanworld and clean universe.
> 
> QUOTE
>     clean            Remove any files created during the build process.
> 
>     cleandepend      Remove the ${.OBJDIR}/${DEPENDFILE}* files generated by
>                      prior “make” and “make depend” steps.
> 
>     cleandir         Remove the canonical object directory if it exists, or
>                      perform actions equivalent to “make clean cleandepend”
>                      if it does not.  This target will also remove an obj
>                      link in ${.CURDIR} if that exists.
> 
>                      It is advisable to run “make cleandir” twice: the first
>                      invocation will remove the canonical object directory
>                      and the second one will clean up ${.CURDIR}.
> . . .
>     cleanworld           Attempt to clean up targets built by a preceding
>                          buildworld, or similar step built from this source
>                          directory.
> 
>     cleanuniverse        When WITH_UNIFIED_OBJDIR is enabled, attempt to
>                          clean up targets built by a preceding buildworld,
>                          universe, or similar step, for any architecture
>                          built from this source directory.
> END QUOTE
> 
> To my knowledge you do not build for all architectures,
> just aarch64 and armv7 . So cleanuniverse should be able to
> be ignored.
> 
> From Makefile.inc1 :
> 
> QUOTE
> # Make command line options:
> #       -DNO_CLEANDIR run ${MAKE} clean, instead of ${MAKE} cleandir
> #       -DNO_CLEAN do not clean at all
> . . .
> #       -DNO_KERNELCLEAN do not run ${MAKE} clean in ${MAKE} buildkernel
> END QUOTE
> 
> but the actual logic is:
> 
> .if defined(NO_CLEANDIR)
> CLEANDIR=       clean cleandepend
> .else
> CLEANDIR=       cleandir
> .endif
> 
> so cleandepend is also used for NO_CLEANDIR . This shows the
> relationship: clean cleandepend does less.
> 
> As for cleanworld ( from Makefile.inc1 ):
> 
> QUOTE
> # cleanworld
> # In the following, the first 'rm' in a series will usually remove all
> # files and directories.  If it does not, then there are probably some
> # files with file flags set, so this unsets them and tries the 'rm' a
> # second time.  There are situations where this target will be cleaning
> # some directories via more than one method, but that duplication is
> # needed to correctly handle all the possible situations.  Removing all
> # files without file flags set in the first 'rm' instance saves time,
> # because 'chflags' will need to operate on fewer files afterwards.
> #
> # It is expected that BW_CANONICALOBJDIR == the CANONICALOBJDIR as would be
> # created by bsd.obj.mk, except that we don't want to .include that file
> # in this makefile.  We don't do a cleandir walk if MK_AUTO_OBJ is yes
> # since it is not possible for files to land in the wrong place.
> END QUOTE
> 
> To my knowledge cleanworld is more extensive in its coverage than
> any clean , cleandepend , or cleandir usage combination.
> 
> cleanworld has some fall back logic that uses cleandir once for a
> particular type of context after its potenial rm -fr activities.
> 
> 
>> It sounds like an occasional clean start buildworld/buildkernel
>> would reduce uncertainty, if not problems. 
>> 
> 
> It can. At times UPDATING will report needing to have cleaned
> before a buildworld or buildkernel .
> 
> 


===
Mark Millard
marklmi at yahoo.com