powerpc64 update from source kernel panic (11.0)

[Mark Millard]

On 2017-Jul-4, at 4:55 PM, Alan Braslau <braslau.list at comcast.net> wrote:

> On Tue, 4 Jul 2017 16:28:14 -0700
> Mark Millard <markmi at dsl-only.net> wrote:
> 
>> On 2017-Jul-4, at 3:52 PM, Alan Braslau <braslau.list at comcast.net>
>> wrote:
>> 
>>> . . .
>> 
>> There are two revisions for svn. If you explicitly use
>> update -r?????? the two will be equal, for example:
>> 
>> # svnlite info /usr/src | grep "Re[plv]" 
>> Relative URL: ^/head
>> Repository Root: svn://svn0.us-west.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 320570
>> Last Changed Rev: 320570
>> 
>> But if you just grab the most current without
>> specifying then the "Last Changed Rev" number
>> is what you want to reference.
>> 
>> The other number will reflect the global svn
>> state across branches and such and so frequently
>> will appear more recent than what is actually
>> checked out and also possibly pointing into
>> the wrong branch.
>> 
>>> (am I misusing svn?)
>>> 
>>> Also, I thought that I specified powerpc64.  
>> 
>> I agree that I likely should have taken
>> "freebsd 11.0 powerpc64" to mean:
>> 
>> TARGET_ARCH=powerpc64
>> 
>> But, with things already being odd, I wanted to
>> be sure it was just not the processor-type that
>> was being specified. (In head TARGET_ARCH=powerpc
>> recently has had extra problems that did not
>> show up for TARGET_ARCH=powerpc64 .)
>> 
>>> Indeed, the problem seems to be the loading of a kmod that does not
>>> get updated until installworld. My fault (or some missing
>>> information in the handbook).   
>> 
>> I've never used PORTS_MODULES or the like
>> so I'm unsure of the details for avoiding
>> compatibility issues.
>> 
>> 
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>> 
> 
> Thank you for the explanations.
> I had simply typed:
> 
> mv /usr/src /usr/src.bak
> svn co https://svn.freebsd.org/base/releng/11.0 /usr/src
> 
> I may have done an
> 
> svn up
> 
> the next day before buildworld.
> (I have never specified revisions, as I have usually used svn on an
> entire project repository.)

I update via:

svnlite update -r?????? /usr/src/

or for ports:

svnlite update -r????? /usr/ports/

(The ending "/"s are optional.)

I try to monitor enough to pick what I
hope will be stable/reliable versions
from what I've seen --and that will
have specific things of interest. I
rarely simply grab the most recent
version of the /usr/src/ tree, at least
for contexts in which I'm using head.

Note that this -r?????? based update
does update a whole project directory
tree.

If I establish a new /usr/src/ tree I use:

svnlite co -r?????? . . . /usr/src/

again being specific about which version
that I get.

But that is just me.

> By the way, the handbook does not suggest using "svn up -rXXXXXX" so I
> do not know that I did anything unusual.

https://www.freebsd.org/doc/en/articles/committers-guide/subversion-primer.html
does say:

5.3.4. Updating the Tree
To update a working copy to either the latest revision, or a specific revision:

% svn update
% svn update -r12345

To show local changes and files that are out-of-date do:

% svn status --show-updates

(This does presume one has cd'd to the top of the
directory tree to be updated since they
do not list the path on the command lines.)

> I still don't get the problem as I am not using any PORTS_MODULES.
> I see that /boot/kernel is a directory containing all of its modules,
> as is /boot/kernel.old

Lack of use of PORTS_MODULES would imply that
kernel builds end up with the older, none-updated
module being present. I expect that PORTS_MODULES
purpose is to keep modules from ports up to date
with system builds, being rebuilt based on updated
headers and such. But I do not know the details of
its use or what else may be required.

installkernel, delete-old, and the like do not
deal with removing modules that have been removed
from the newer system or are otherwise not being
installed any more.

I periodically do something like:

ls -lTt /boot/kernel/ | tail -20

to see if I've got something that is
not being updated as expected. (The
times are install times here, not
build times, so old dates mean "not
recently installed".)

But I do not add any modules to the defaults or
have any from ports. (My context is normally
some variant of head since around when clang
3.8 became a project.)

> The updated system is running, and I have moved the loading of the
> wireless module from /boot/loader.conf to /etc/rc.conf. Maybe this
> module is fussy about when it is loaded and perhaps it is not generally
> recommended to load modules via loader.conf. Note that the module
> loaded previous to the update of the kernel via loader.conf.

Interesting.

===
Mark Millard
markmi at dsl-only.net