On Sat, Jul 15, 2017 at 6:49 PM, Michael Butler <i...@protected-networks.net>
> On 07/15/17 20:39, Mark Millard wrote:
>> FYI for Michael B.: the incomplete kernel rebuild problem has a fix:
>> -r320919 .
>> See the fix (to the building problem that was created in -r320220 ):
>> If the KDE problem persists based on a -r320919 or later build, it would
>> be appropriate to report it again as a separate issue.
>> Unfortunately various odd problems have shown up over -r320220 through
>> -r320918 from incorrect rebuilds (and other oddities overlapping in the
>> time frame).
>> Of course if you built (or build) -r320844 based on a empty directory in
>> the first place so that it was a full-build but the KDE problem persisted
>> when using the rebuilt kernel then the above material does not apply. In
>> such a case reporting that about the context for the KDE problem would be
>> You may well have other things to be doing instead of what the above
>> suggests. If so, just take the above as background information.
> Prior to testing this, I did 'rm -rf /usr/obj/*' so it is a clean build. I
> can run with user-land at SVN r321021 but any kernel at or after r320844
> fails :-(
Right. We need to find out what, exactly, is failing to make progress. I
have exactly one guess as to what might be going on, and it's a long shot
at best. To gather more evidence, I need to know if the kde thing that's
segfaulting is accessing /dev/pass* or /dev/xpt*. If you can confirm that
it is, then we'll need to see how to fix that.
Also, you'll need an installworld as well as an installkernel so the new
headers are installed prior to running kde. If that fixes it, then my guess
goes from a long shot to close to a sure thing.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"