Upcoming release of V 12

[Jeffrey Bouquet]

I'm running v12 as HEAD [ 12.0-CURRENT]

And am at a loss as to how to change it to 12.0-STABLE vs one day
running  a non-rebuilt 13.0-CURRENT  

Without risking a scenario such as:
   svn up 12.0, fail for some reason to be able to build the GPU driver, so I 
should
   have stuck with svn up 13.0 ??? 
As I've no second machine setup as backup.  due to moving issues. 
 
Background
At present I've various OSVERSION and UNAME_ENV set in make.conf
to work around some type of kernel mismatch issue which prevents otherwise
many ports building.

However it is working seamlessly and I wish it to continue to do so
after the day CURRENT changes from 12 to 13... 

The system was crafted from a thumbdrive ISO so still has 
/mnt/usr/freebsd-dist/base.txz ... 

Otherwise it is all good. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

just a FYI

[Jeffrey Bouquet]

 /usr/ports/security/lockdown [ sorry if this is a PR or for ports- ]
altered fstab, login.conf and ttys locking me out of my main machine, probably 
due
to the password hash, but only a daily backup helped me login again and fix the 
damages, with a few files "hardened" maybe but at a cost of uncertainty 
as to whether the net benefit was good/bad once the system is back up, as
it is now.
  It fortunately only took me about an hour.  This would have been much more 
problematic if I had not had 14 years experience in FreeBSD.
  Can someone alter the port to log its actions, create backups, ask permission 
for
each block of edits it is about to undertake, etc, so someone with critical 
server data
or less of a backup doesn't suffer the same? Something like a mergemaster 
would... 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: just a FYI

[Jeffrey Bouquet]

On Wed, 19 Sep 2018 09:58:19 -0400, Ed Maste  wrote:

> On 19 September 2018 at 09:28, Jeffrey Bouquet
>  wrote:
> >  /usr/ports/security/lockdown [ sorry if this is a PR or for ports- ]
> 
> Unfortunately this port has no maintainer, so fixing this is going to
> need someone to take an interest in the port. I had a quick look at
> the script and it looks like it sets obsolete flags that would result
> in an unbootable system.
> 
> In any case, would you kindly submit a PR for the issue to track it?
> I'll try to get it marked FORBIDDEN (or similar) for now.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Bug # 231489 submitted. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Digest re-ordering?

[Jeffrey Bouquet]

  This may not be the proper list, but it may get more traction here... 
 .
  There may be at least some developers who get the list(s) in digest format.
.
Thus, rather than the ordering that is done now, they may be able to comprehend
posts they can contribute toward a resolvation of, if the digest was via some 
software preprocessed:

 now 
**
 msg: 1
blah blah
 subject:  RFC "a"
blah blah
  [msg text ] 
__
msg:  2
blah blah
 subject: RE: bug "bar"
blah blah
  [msg text] 
___
msg:  3
blah blah
 subject: RE: RFC "a"
blah blah
  [msg text ] 
  
***

 proposed:

 
 subject: RE: bug "bar"
msg: 1 
blah blah
blah blah
   [msg text]
 .
 

subject: RFC 'a"
msg: 2
blah blah 
blah blah
  [ msg text]

subject: RE: RFC "a" 
msg: 3
blah blah
blah blah
  [msg text] 

.
...

**

Seems like it would save digest readers half the time they use to review
the topics, and enable them to read the topics they do read sequentially,
thus not getting distracted mid-read and becoming not interested in 
input.
.

And/or it requires a huge rewrite of someone else's mailman software??? As in,
an upgrade to it would revert changes we made...



Thanks

J. Bouquet 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

pkg-devel-1.4.0-a3 works good so far

[Jeffrey Bouquet]

Built with clang... none of the problems (so far) from the previous builds 
appear to exist from
initial testing of pkg and of a port install.
v9 
had to use -DFORCE_PKG_REGISTER though...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: RE: reducing the size of the ports tree

[Jeffrey Bouquet]

Not initially welcoming this new effort... 
explanation and other PKG problems taking precedence...


I've a few scripts which use the smaller files, and have used them
extensively in pipes.  Syntax within the Makefile would make those
counterintuitive.I would wonder also if it would break port
infrastructure like the Mk and Tools and "make search" and
portsearch (etc -- ports )... essentially breaking more things than
would be solved.  Indeed, I've many ideas for MORE small
files for people crafting shell scripts that would be of more use
down the road, and incorporated someday into additional port tools,
portmasters, portupgrades, etc...

So as far as this particular suggestion, maybe if someone wants it
bad enough one should build a prototype and test locally several
years with many ports and upgrades to determine what it breaks... and
how to write new tools.

But I conjecture that effort would be better spent with PR backlogs,
fixing pkg2ng (which fails here on one machine ) etc... and
making pkg more robust... (complete recovery if the database is
hosed, with a something local_sqlite_hosed_reuild_sh.sh etc etc
And the documentation.  Many many more examples of everyday usage
over the course of a year and UPDATING scenarious would be 
appreciated...


and also streamlining pkg so it works better on  low power machines with
many ports installed.  Including less segfaults...

As an aside, I am now on a machine which never had the problem before,
after a failed pkg2ng conversion, 

A... pkg install -f nettle
   wants to install csound!   what file is telling it that?  The database ???
... and seven others I had just deinstalled

B... make install ( proceeds with "Child process terminated abnomally...
segmentation fault) before the install.  Not known if anything was running
beforehand.  Not problems with the install.  But it keeps occuring...
What process?  Something in the background wanting that nettle >>
csound dependency?  Pkg working before the make command? Part
of the make command infrastructure now more buggy?

Thankfully that machine is not the primary one here, and all the programs
installed still work on it as far as I know. But its registration data is 
not exact and pkg-devel as installed on it could be debugged more... as
well as pkg2ng retested to work on v9 more precisely...  It failed three times
to convert that machine.  (not installed unless desinstalling direct from
the port, so could not upgrade.. or pkg info the port)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] pkg 1.4.0 rc2

[Jeffrey Bouquet]

On 12/06/14 04:40, Baptiste Daroussin wrote:
> Hi,
>
> We have released a new 1.4.0 rc2 version of pkg (available in
> ports-mgmt/pkg-devel) since first beta it has received tons of bug fixes and
> should be now way more reliable and able to handle ootb without mistakes
> upgrades like the gettext one and the perl one.
>
> All reported issues should have been fixed since.
>
> Please test that new version I would like to make it the final release if
> possible.
>
> Best regards,
> Bapt
The upgrade of pkg-devel went slightly more without problems.  Did not test
a direct deinstall/reinstall though.

OTOH "pkg install xorriso xombrero" still wants to remove w3m-img , install
w3m, guile 1.8, x246,  along with the reinstall of those two.

For which I "n" and
pkg delete xorriso xombrero
cd ../cache/pkg
pkg clean
pkg install xorr[tab] xomb[tab] to complete and install manually
Works, but a few more commands in the way.

I seem to have no guile installed (was using v2 for mcron) and libx264
installed.
Just ignoring guile for now probably.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

"make distribution," but more than one filesystem at destination?

[Jeffrey Bouquet]

UPDATING from what I have read does not go into detail in the case that the 
destination has separate /var
etc partitions.  A variable to set, or procedure, or one should rsync the 
contents onto the filesystems after install?

Experiences welcomed.  Also maybe into the UPDATING file(s) [ usual one; v11 
one...]  ... unless it is not
recommended.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[SOLVED] Re: "make distribution," but more than one filesystem at destination?

[Jeffrey Bouquet]

On Sat, 17 Jan 2015 04:06:34 -0800 (PST), "Jeffrey Bouquet" 
 wrote:

> UPDATING from what I have read does not go into detail in the case that the 
> destination has separate /var
> etc partitions.  A variable to set, or procedure, or one should rsync the 
> contents onto the filesystems after install?
> 
> Experiences welcomed.  Also maybe into the UPDATING file(s) [ usual one; v11 
> one...]  ... unless it is not
> recommended.
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


mount -t ufs -o union [partition not root in dev]  /mnt/var#etc  in DESTDIR 
installworld, installkernel, distribution.
unmount and mount regularly the new filesystems.  

Seems to have produced CURRENT r277276 running fine here, but a very many 
haven't-done-in-years 
mergemaster-related not-a-direct upgrade tasks cropped up...not to mention 
the one or two errors 
(coded vt, meant to code sc in loader.conf...)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: default pager (csh)

[Jeffrey Bouquet]

On Wed, 18 Feb 2015 23:45:27 -0800, Kevin Oberman  wrote:

> On Wed, Feb 18, 2015 at 10:46 PM, Franco Fichtner 
> wrote:
> 
> >
> > > On 19 Feb 2015, at 02:27, Davide Italiano  wrote:
> > >
> > > On Wed, Feb 18, 2015 at 5:18 PM, Adam McDougall 
> > wrote:
> > >> The PAGER was less for about half a year and reverted.  Please see:
> > >>
> > >> https://svnweb.freebsd.org/base?view=revision&revision=242643
> > >> ___
> > >> freebsd-current@freebsd.org mailing list
> > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > >> To unsubscribe, send any mail to "
> > freebsd-current-unsubscr...@freebsd.org"
> > >
> > > OK, I think this ends the discussion =)
> >
> > Nope, not good enough.  The way I see it we achieved nothing
> > despite the fact that several bugs are on the table.
> >
> > Now that we all agree more(1) is the way to go, can we please fix
> > colouring and the pager quit issue for man pages using sensible
> > options in more(1)?
> >
> > Other's should speak up for their woes with the FreeBSD defaults
> > too.  The defaults are supposed to be the best we can do.  Right
> > now, we can actually do better.  :)
> >
> >
> > Cheers,
> > Franco
> >
> 
> I want my bikeshed to be purple with yellow stars.
> 
> I want my PAGER to be Jim Davis's most(1). Does a LOT more than more or
> less. (Does have the annoying te/ti thing, though.) Displays binary.
> Auto-decompresses compressed files. Allows moving my line or percentage.
> Whole raft of neat stuff. Usually the second port (after portmaster) I
> install on a system since my finger type "most" even when I want them to
> type "more" because the system does not have most installed.
> 
> I don't expect anyone else to agree and don't expect it to ever be in the
> base, let alone the default. Still, it's a much better pager then less,
> whether it's called more or not. Started using it at least 25 years ago on
> VMS.
> --
> Kevin Oberman, Network Engineer, Retired
> E-mail: rkober...@gmail.com
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Here:  (.zshrc)...

PAGER='cat'
alias man='env PAGER=lookat man $1'

That bottom one is so useful for the 's' search key... EXAMPLES for instance.  
Same on all keyboards...
[ seems easier to read with default colors, also... ]
However in some instances (screen, dvtm, tmux... ) it may have onscreen 
artifacts
one can simply then 'sh' (untested) first... for  usual 'man' instance of PAGER.
/usr/ports/sysutils/lookat...

[ Just re-noticed that 'cat' entry today.  No idea of the difference to a 
default... ]
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy"

[Jeffrey Bouquet]

On Wed, 25 Feb 2015 18:52:35 -0800, Garrett Cooper  
wrote:

> 
> > On Feb 25, 2015, at 18:08, Kevin Oberman  wrote:
> > 
> >> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper  
> >> wrote:
> >> On Feb 25, 2015, at 14:19, Miguel Clara  wrote:
> >> 
> >> ...
> >> 
> >> > I noticed this too, but in that case why doesn't it affect all users? 
> >> > (or all the ones using dnscrypt+local_unbound) maybe something changed 
> >> > in "NETWORKING" recently?
> >> >
> >> > Hum:
> >> > https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299&r2=278704
> >> >
> >> > Interesting, as I am using the most recent version which does not 
> >> > REQUIRE local_unbound
> >> >
> >> > I'm even more confused now :|
> >> >
> >> >
> >> > So it has to come after SERVERS but before local_unbound. But NETWORKING 
> >> > depends on local_unbound they are both dependent on NEWORKING which has 
> >> > to be after SERVERS. Can you say fubar! Clearly broken. And this means 
> >> > that removing SERVERS will re-shuffle the order more appropriately.
> >> >
> >> > It seems that the behavior of rcorder is not as documented as well as 
> >> > being undefined when circular dependencies occur. The man page says that 
> >> > rcorder aborts when it encounters a circular dependency, but that is not 
> >> > the case. It probably is best that it not die, but that leaves things in 
> >> > an unknown and inconsistant state, which is also a very bad idea. I 
> >> > guess when a circular dependency is encountered, a dichotomy occurs.
> >> 
> >> Now you know why I’m so curious about all of this stuff.
> >> 
> >> When I was working on ^/projects/building-blocks, I was able to move most 
> >> of these pieces around by changing REQUIRE: to BEFORE:, but I noticed that 
> >> it changes the rcorder a bit, so I haven’t been super gung ho in 
> >> implementing my change.
> >> 
> >> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT:
> >> 
> >> - Things go awry if named is removed/not installed.
> >> - Things go awry if local_unbound is removed (which would have been the 
> >> case if the rc.d script was removed from your system, which existed before 
> >> my changes).
> >> - Other rc.d scripts not being present might break assumptions.
> >> 
> >> I need to create dummy providers for certain logical stages (DNS is one of 
> >> them) to solve part of this problem and provide third parties with a 
> >> mechanism that can be depended on (I wish applications were written in a 
> >> more robust manner to fail gracefully and retry instead of failing flat on 
> >> their face, but as I’ve seen at several jobs, getting developers to fail, 
> >> then retry is hard :(…).
> >> 
> >> Another short-term hack:
> >> 
> >> Install dummy/no-op providers so the ordering is preserved, then remove 
> >> the hacks after all of the bugs have been shaken out.
> >> 
> >> Thanks!
> > 
> > Garret, 
> > 
> > Also undocumented (except in rcorder.c) is that the lack of a provider is 
> > not an error. This effectively makes a list of providers into an OR. So, 
> > for name service the normal list is "named local_unbound unbound" and any 
> > will work for ordering and having none is a no-op, so if you don't run any 
> > nameserver (or kerberos or whatever provider), it is not an issue. As long 
> > as rcorder finds a provider, it will be used to set the order, but the lack 
> > of any or all providers just means that the specified provider is ignored 
> > and if a REQUIRES or BEFORE lists no existing providers, the statement is 
> > simply ignored.
> > 
> > The real problem is that there is no defined rule for behavior in the event 
> > of a circular dependency and any change to any decision point in the 
> > ordering process may change the way the ordering flips. That is why these 
> > things are such a royal pain to debug. A change in any rc.d script may 
> > cause the ordering of seemingly unrelated scripts to change, perhaps 
> > drastically, and the error messages, while not misleading, is only a 
> > starting point in tracking this down. This means there may be time bombs 
> > that break working ports without their being touched or even re-installed. 
> > And the triggering change my, itself be correct.
> 
> Or etc/rc.d/named...
> 
> PROVIDES: DNS
> 



I don't know if this is adding not-relevancy to this thread or not... I've a 
long persistent "dbus-daemon*" "*uuid*"
(names approximate, not saved during boot) two "start ..." failures during 
rc...  despite reinstalling the ports
and dependencies, particularly the .so. files mentioned (not included here...  

uuidd_enable="YES"   (e2fsprogs* )
dbus_enable="YES"  (*dbus*) 

beginning v9 OR v10 ( not recollecting enough...) and persisting thenceforth.

Maybe those two could also be similarly fixed to this thread's one
Despite not being in use day-to-day... nor particularly relevant... installed 
only conventionally.

___
freebsd-current@freebsd.org mailing list
ht

"proper way" or "unworkable idea" ?

[Jeffrey Bouquet]

If I've a spare /mnt/usr/src , it seems buildworld quite
soon fails, where it otherwise may succeed in /usr/src. Any CLI parameters or 
the build system is hardcoded enough so that there will always be problems? 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

llvm boostrap? Clang failures.

[Jeffrey Bouquet]

The "update clang" messages in UPDATING seem to not fix...
 ...llvm/include/llvm/ADT/StringRef.h: fatal error:
 'algorithm' file not found
make stopped in /usr/src/lib/clang/lib/libllvmsupport...
The entire build fails similarly,
also in any subtree I try to start from (clang, lib/clang... etc etc)

Previously, the system was upgraded from another successful installworld by 
rsync'ing the
/obj IIRC... 
Also I've tried parameters such as CPP=/usr/local/bin/clang-cpp36   to no 
avail...

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: llvm boostrap? Clang failures.

[Jeffrey Bouquet]

On Fri, 10 Jul 2015 14:50:22 +0200, Dimitry Andric  wrote:

> On 10 Jul 2015, at 03:54, Jeffrey Bouquet  wrote:
> > 
> > The "update clang" messages in UPDATING seem to not fix...
> > ...llvm/include/llvm/ADT/StringRef.h: fatal error:
> > 'algorithm' file not found
> > make stopped in /usr/src/lib/clang/lib/libllvmsupport...
> 
> Do you have the 'algorithm' file on your system, in /usr/include/c++/v1?
> And is the rest of libc++ correctly installed?  You should have the
> following libraries:
> 
> /usr/lib/libc++.a
> /usr/lib/libc++.so
> /usr/lib/libc++.so.1
> /usr/lib/libc++_p.a

Were missing.

> 
> 
> > The entire build fails similarly,
> > also in any subtree I try to start from (clang, lib/clang... etc etc)
> > 
> > Previously, the system was upgraded from another successful installworld by 
> > rsync'ing the
> > /obj IIRC...
> > Also I've tried parameters such as CPP=/usr/local/bin/clang-cpp36   to no 
> > avail...
> 
> Another possibility is that you are assigning to CFLAGS and/or CXXFLAGS
> incorrectly.  Can you please post your make.conf and src.conf files?
> 
> Last but not least, from which version of FreeBSD are you building?  An
> older copy of -CURRENT, or some -STABLE branch?
> 
> -Dimitry

make CC=/usr/local/bin/clang36 CXX=/usr/local/bin/clang++36 
CPP=/usr/local/bin/clang-cpp36 -NO_PROFILE
  -DALWAYS_CHECK_MAKE -DNOPROFILE buildworld...

Fails in the same way.

Aside from rsync'ing over from another CURRENT that buildworld works on, which 
may happen soon,
for an installworld, I wonder why some invocation of the above line, or one 
with gcc49, would not
suffice...

[ Tried several things in UPDATING and 'man build', but since even
  /usr/bin/clang here is missing [1], things are not what they should be,
  everything except buildworld works...   ]
[1] I may be able to copy it over today using a thumbdrive, however... 

Sorry to waste anyone's time.  This problem is of low priority here...  but 
thanks to 
the replies, appears to be solvable sooner than later.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: llvm boostrap? Clang failures. [ more info add to post ]

[Jeffrey Bouquet]

On Fri, 10 Jul 2015 12:12:57 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> 
> 
> On Fri, 10 Jul 2015 14:50:22 +0200, Dimitry Andric  wrote:
> 
> > On 10 Jul 2015, at 03:54, Jeffrey Bouquet  wrote:
> > > 
> > > The "update clang" messages in UPDATING seem to not fix...
> > > ...llvm/include/llvm/ADT/StringRef.h: fatal error:
> > > 'algorithm' file not found
> > > make stopped in /usr/src/lib/clang/lib/libllvmsupport...
> > 
> > Do you have the 'algorithm' file on your system, in /usr/include/c++/v1?
> > And is the rest of libc++ correctly installed?  You should have the
> > following libraries:
> > 
> > /usr/lib/libc++.a
> > /usr/lib/libc++.so
> > /usr/lib/libc++.so.1
> > /usr/lib/libc++_p.a
> 
> Were missing.
> 
> > 
> > 
> > > The entire build fails similarly,
> > > also in any subtree I try to start from (clang, lib/clang... etc etc)
> > > 
> > > Previously, the system was upgraded from another successful installworld 
> > > by rsync'ing the
> > > /obj IIRC...
> > > Also I've tried parameters such as CPP=/usr/local/bin/clang-cpp36   to no 
> > > avail...
> > 
> > Another possibility is that you are assigning to CFLAGS and/or CXXFLAGS
> > incorrectly.  Can you please post your make.conf and src.conf files?
> > 
> > Last but not least, from which version of FreeBSD are you building?  An
> > older copy of -CURRENT, or some -STABLE branch?
> > 
> > -Dimitry
> 
> make CC=/usr/local/bin/clang36 CXX=/usr/local/bin/clang++36 
> CPP=/usr/local/bin/clang-cpp36 -NO_PROFILE
>   -DALWAYS_CHECK_MAKE -DNOPROFILE buildworld...
> 
> Fails in the same way.
> 
> Aside from rsync'ing over from another CURRENT that buildworld works on, 
> which may happen soon,
> for an installworld, I wonder why some invocation of the above line, or one 
> with gcc49, would not
> suffice...
> 
> [ Tried several things in UPDATING and 'man build', but since even
>   /usr/bin/clang here is missing [1], things are not what they should be,
>   everything except buildworld works...   ]
> [1] I may be able to copy it over today using a thumbdrive, however... 


I've a CURRENT r281990 that won't complete buildworld, nor installworld from

 an obj rsynced from r285019. 
 and a src r285239
 IOW former won't install
 latter won't build...

 ( missing files, etc... error varies)

 Just a slight chance anyone has run into a similar situation...

 Current error is in /usr/src/lib/clang/libllvmsupport (file not found) 
 during buildworld



 elsewhere, 
 "don't know how to make auto.obj.mk"
 (usr/src/contrib/llvm/include) "make install" -- the above error occurs

 I don't suspect a mismatch between src and obj (former not building, latter 
already
 built); only a few days apart as to upgrades. 



 Hopefully stated clearly enough. 
 Not that important now, but may eventually be a showstopper.

 I've checked "man build" and UPDATING and not really sure how to proceed.


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: "proper way" or "unworkable idea" ? > [SOLVED]

[Jeffrey Bouquet]

On Tue, 30 Jun 2015 20:54:07 +0200, Willem Jan Withagen  
wrote:

> On 30/06/2015 17:32, Simon J. Gerraty wrote:
> > Jeffrey Bouquet  wrote:
> > 
> >> If I've a spare /mnt/usr/src , it seems buildworld quite soon fails,
> >> where it otherwise may succeed in /usr/src. Any CLI parameters or> the
> >> build system is hardcoded enough so that there will always be
> >> problems?
> > 
> > The only thing hard coded is the default MAKEOBJDIRPREFIX (it isn't
> > called that but it works the same way), but even that should work for any
> > location. I always have MAKEOBJDIRPREFIX when doing buildworld etc,
> > and have never used /usr/src.
> > 
> > Is there perhaps something interesting about /mnt/usr/src (like
> > ancient?)
> 
> On some of the systems where I use different versions, I have
>   /usr/srcs
> mounted of the NFS-server. in which I have.
>   /usr/srcs/src8/src
>   /usr/srcs/src9/src
>   /usr/srcs/src10/src
>   /usr/srcs/head/src
> 
> Then also have /usr/objs mounted, with the same setup
> 
> And on the remote systems link /usr/src -> /usr/srcs/src??/src and same
> for obj
> 
> I have yet to run into trouble when I do the normal things. It gets
> messy if I'd like to build both i386 and amd64 in the same obj-tree.
> That does not always work, but adding a differentiating i386 and amd64
> to the hierarchy seemed to fix it. But I retired all but one i386, and
> that is soon to follow.
> 
> --WjW
> 
> 
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Using a r285418 (july 12), rsynced /usr/obj and /usr/src  ( precise howto
found in the motd where I store stuff... cp -Rp that is) 

# cp -Rp /mnt_usr/obj/usr/src /usr/obj/usr  # /usr as a seperate filesystem
  ... note 4 > 3
# cp -Rp /mnt_usr/src /usr # /usr as a seperate filesystem
 ... note  2 > 1 

the MAKEOBJDIRPREFIX seems to be working for the first time ever.  Cntl-c'd it 
since
the installkernel/installworld did the upgrade...  so something was fixed.  
Could probably
comtinue with the MAKEOBJDIRPREFIX  buildworld if I was sure (doubly sure) 
how to install from
the "different" location to the "usual" one...  without a hitch.  So that may 
come later this
year... unless something else breaks the specific build environment which 
caused this
thread, which appears SOLVED...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

sendmail errors upon partial upgrade

[Jeffrey Bouquet]

gateway sm-mta[1533]: NOQUEUE: SYSERR(root):
opendaemonsocket: daemon Daemon0: cannot find: Can't assign requested address
gateway sm-mta[1533]: daemon Daemon0: problem creating SMTP socket

root is not getting any usual emails.
I tried mergemaster again, same result
service sendmail start; stop; start

still nothing.

Web searches turned up the term but in only a few posts and in edge cases not 
particularly
FreeBSD...

Not that the root emails are all that important in the short term but I'd like 
them resumed if at all possible
without a full buildworld cycle...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sendmail errors upon partial upgrade

[Jeffrey Bouquet]

On Thu, 10 Sep 2015 18:04:52 -0700, Claus Assmann  
wrote:

> On Thu, Sep 10, 2015, Jeffrey Bouquet wrote:
> > opendaemonsocket: daemon Daemon0: cannot find: Can't assign requested 
> > address
> 
> What's your mc file?
> What's the output of:
> fgrep Daemon0 /etc/mail/sen*.cf
> and maybe
> grep '^O DaemonPortOptions' /etc/mail/sen*.cf
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Hmmm... three times I've composed a half page and the webmail erases it all  
upon
attempting to paste in any file.
So short snippets...   until I learn webmail better

relevant parts freebsd.mc
 2009
 mailertable, `hash -o /etc/mail/mailtertable`
 smat host is defined
 MAILER(local)
 MAILER(smtp)

rc.conf
sendmail_enable="NO"
sendmail_flags="-q1m"

I've run mailq, verbose sendmail,  mtree, rebuilt base sendmail and the 
/etc/mail rebuild/resinstalls...

Perhaps  a  recent change requires the network active before sendmail starts or
ipv6 defined somewhere or some other recent development in CURRENT,  or
smtp somehow was configured back in 2004 and this week overwritten somehow...

I've /var/log/maillog, attached as files, parts of when it was working and
now when it isnt...


Sorry to not proivde more information and not having the time right now to do a 
buildworld cycle
instead...


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sendmail errors upon partial upgrade [SOLVED]

[Jeffrey Bouquet]

On Thu, 10 Sep 2015 21:38:40 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> On Thu, 10 Sep 2015 18:04:52 -0700, Claus Assmann  
> wrote:
> 
> > On Thu, Sep 10, 2015, Jeffrey Bouquet wrote:
> > > opendaemonsocket: daemon Daemon0: cannot find: Can't assign requested 
> > > address
> > 
> > What's your mc file?
> > What's the output of:
> > fgrep Daemon0 /etc/mail/sen*.cf
> > and maybe
> > grep '^O DaemonPortOptions' /etc/mail/sen*.cf
> > 
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 
> Hmmm... three times I've composed a half page and the webmail erases it all  
> upon
> attempting to paste in any file.
> So short snippets...   until I learn webmail better
> 
> relevant parts freebsd.mc
>  2009
>  mailertable, `hash -o /etc/mail/mailtertable`
>  smat host is defined
>  MAILER(local)
>  MAILER(smtp)
> 
> rc.conf
> sendmail_enable="NO"
> sendmail_flags="-q1m"
> 
> I've run mailq, verbose sendmail,  mtree, rebuilt base sendmail and the 
> /etc/mail rebuild/resinstalls...
> 
> Perhaps  a  recent change requires the network active before sendmail starts 
> or
> ipv6 defined somewhere or some other recent development in CURRENT,  or
> smtp somehow was configured back in 2004 and this week overwritten somehow...
> 
> I've /var/log/maillog, attached as files, parts of when it was working and
> now when it isnt...
> 
> 
> Sorry to not proivde more information and not having the time right now to do 
> a buildworld cycle
> instead...
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Found an old pdf describing buildworld on v7.  noticed m4 - mtree run as the 
last step.
Rebooted to single-user

On a hunch, I 
found files in /usr/src/etc that had not been updated along with the 
/usr/src/etc/rc.d which had (one or two or three files... network.subr etc)
copied those few over,
Maybe another fix or two... similar...
reinstalled sendmail single user for good measure,

Upon reboot all is back to as it was before, save a few errant not important 
misconfigurations which crept in that should resolve during the next year or
so during usual port upgrades and buildworld cycles.

Immediately logged on here, although it is late, so no one wastes anymore time
on this problem... 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Depreciate and remove gbde

[Jeffrey Bouquet]

On Thu, 29 Oct 2015 16:24:00 -0700, John-Mark Gurney  wrote:

> Lyndon Nerenberg wrote this message on Mon, Oct 26, 2015 at 19:06 -0700:
> > On Oct 24, 2015, at 12:06 PM, John-Mark Gurney  wrote:
> > 
> > > The thing I like most about encryption is that when I RMA a bad
> > > drive, I don't have to worry about my data leaking if I am unable
> > > to overwrite all the data...
> > 
> > You are optimistic if you believe that.  We ($WORK) factor the cost of 
> > DOA/warranty drives into our operational budget.  They never get RMAed.  We 
> > drill them when they die.
> 
> Being a personal user, and having close to a 10% RMA rate on recent
> hard drives, that would be a bit costly...
> 
> I consider a HD defective if it's under waranty and it's performance
> drops below 80% of new, i.e. 130MB/sec normal sequential write drops
> below 100MB/sec..
> 
> The weekest point is the passphrase/passfile protecting the master
> key... In my case, I use a random passfile for these drives...  If
> someone is able to break the passfile, or the AES-256 encryption, then
> they must really want my data...  It'd be easier, even for governments,
> to do a black bag job than recover partial data (it's one drive of a
> RAIDZ array)...
> 
> -- 
>   John-Mark GurneyVoice: +1 415 225 5579
> 
>  "All that I will do, has been done, All that I have, has not."
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


FWIW I've several WD eide that corrupt with twed0... fix them with
dosdlg.exe on floppy (long test, an hour...) and they work fine as primary
eide drives a long while thereafter (not secondary on twed0...)   
in case that saves anyone some time/money...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Cannot installworld, don't expect to...Workaround?

[Jeffrey Bouquet]

I've a not-complete-installworld from today, dumped core halfway through 
despite single-user mode...

began with an install of libc++... which was fine.

i can restore
/lib
/libexec
/bin
/sbin
/usr/bin
/usr/sbin
from an earlier backup

and most binaries work again, but nowhere near
full functionality...   wanting to restore browser
functionality... which mysteriously broke (all segfault) which
prompted the buildworld.

setting COMPILER_TYPE results later in
sh: cc; not found  during the installworld.  
OTOH some buildworld 
produced files may have been lost during the fsck to lost+found

I noticed a few clang files ended up in lost+found during one of the many fsck.

So as an aside of any usual question...
Is there any documentation 
where make installs should proceed?
for instance libc++ first, then ...

and/or how to run the installworld segment-at-a-time to find the
specific failure?  OR it is too complex

Assuming "no" to each of the above...  is there a best
practice to 
copy a greater number of the /lib, libexec from 
backup to completely restore, or is it necc. to
do a reinstall to an ENTIRELY new disk... given that
the existing disk for some reason does not want to
complete it.

Maybe even someone has an easier way... or procedure.

Thanks.

...
As an aside, a wanted feature:

during one disk crash recently, the pass* in /etc wound up in lost+found.
No login resulted.  Restored from backup by luck... was clueless.
Would it be wise to build redundancy into the base, so that for example
if /etc/fstab has vanished, its shadow copy in  /etc/shadow/...
or even enough binaries, (similar /rescue ) to complete a complete svn
buildworld installworld as a sort of /rescue/usr/src with all binaries and
libraries contained therein.

Maybe...


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Cannot installworld, don't expect to... part 2...

[Jeffrey Bouquet]

On Sat, 07 Nov 2015 19:14:47 -0800 (PST), "Jeffrey Bouquet" 
 wrote:

> I've a not-complete-installworld from today, dumped core halfway through 
> despite single-user mode...
> 
> began with an install of libc++... which was fine.
> 
> i can restore
> /lib
> /libexec
> /bin
> /sbin
> /usr/bin
> /usr/sbin
> from an earlier backup
> 
> and most binaries work again, but nowhere near
> full functionality...   wanting to restore browser
> functionality... which mysteriously broke (all segfault) which
> prompted the buildworld.
> 
> setting COMPILER_TYPE results later in
> sh: cc; not found  during the installworld.  
> OTOH some buildworld 
> produced files may have been lost during the fsck to lost+found
> 
> I noticed a few clang files ended up in lost+found during one of the many 
> fsck.
> 
> So as an aside of any usual question...
> Is there any documentation 
> where make installs should proceed?
> for instance libc++ first, then ...
> 
> and/or how to run the installworld segment-at-a-time to find the
> specific failure?  OR it is too complex
> 
> Assuming "no" to each of the above...  is there a best
> practice to 
> copy a greater number of the /lib, libexec from 
> backup to completely restore, or is it necc. to
> do a reinstall to an ENTIRELY new disk... given that
> the existing disk for some reason does not want to
> complete it.
> 
> Maybe even someone has an easier way... or procedure.
> 
> Thanks.
> 
> ...
> As an aside, a wanted feature:
> 
> during one disk crash recently, the pass* in /etc wound up in lost+found.
> No login resulted.  Restored from backup by luck... was clueless.
> Would it be wise to build redundancy into the base, so that for example
> if /etc/fstab has vanished, its shadow copy in  /etc/shadow/...
> or even enough binaries, (similar /rescue ) to complete a complete svn
> buildworld installworld as a sort of /rescue/usr/src with all binaries and
> libraries contained therein.
> 
> Maybe...
> 
> 

Crash recovered.   All /root/.* directories had vanished also... so I was 
thinking, maybe if
fsck_ffs were more elaborate when placing the files in lost+found it would 
place metadata as to
where it came from, and then lost+found-replace.sh or binary could recover FROM 
lost+found...
I could be just wishing though.

But the reason for this reply-followup rather than a new post (the paragraph 
above) with
apologies...
Now that the recovery here has been done, ( files between nov 3 and nov 7 
copied from
/mnt where the crashed disk(s) and backups were mounted)...
WHAT is the best practice if *this* working r288246 (11.0-CURRENT) builds 
world, then
core dumps during installworld, rendering login and/or paths upon login and/or
segfaults of nano, etc after login and/or all working but browsers segfaulting 
after
fixup... since this is a principal desktop ... 
... the best practice for "if this installworld hoses, simply copy files from 
..." recovery?
OR,  no one else knows either, which I think is more likely, in which case I 
apologize for even stating the question.

Thanks.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Cannot installworld, don't expect to...Workaround?

[Jeffrey Bouquet]

On Mon, 9 Nov 2015 16:10:55 -0800, Bryan Drewery  wrote:

> On 11/7/2015 7:14 PM, Jeffrey Bouquet wrote:
> > I've a not-complete-installworld from today, dumped core halfway through 
> > despite single-user mode...
> 
> Did you use -j to installworld?
> 
> -- 
> Regards,
> Bryan Drewery

No.   May have used -j 2 to buildworld...

Just then reading Makefile and Makefile.inc1 I was wondering (for lack of
which way to proceed... install to /tmp and rsync back over the system...)
Since the build tree appears to be too complex (Makefiles too numerous) to
test each command in installworld in advance before completion to be sure
the whole lot would complete,   I wonder which of the targets in those two
files are most complete in making installworld complete, at the cost of a
longer buildworld.
Something like tinderbox; toolchain; > buildworld  or whatever ensures that
all binaries, libraries etc used or referenced in the buildworld/installworld 
cycle
can complete a CLI without error; and that all target directories exist...
[I've had installworld fail due to missing target directories in 
/usr/share for example..  which I patched up with a make -k ...]



A slight chance the installworld failed because of a drive bios quirk, though 
the
chance is only slight
Another slight chance it was due to EIDE rather than SATA cabling...

Another slight chance it ran "too fast" and if slowed down (twenty Makefiles 
one starts
manually.   sh Makefile.1 sh Makefile.2 ... ) may complete or at least be 
scrutinized
better.
...
Just so reading this post doesn't entirely anyone's time, here is an alias to 
try
possibly...
[ most recent files in the current directory listed last]  ... which I could 
use daily.

/usr/local/bin/gnuls -halstir |grep -v drw | awk '{print $11}'
...easier to read than the plain gnuls command above.

that I figured out today. Maybe duplicate of another "ls" alias
I've already crafted, but here too many to count... so I seldom remember
more than a few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: freebsd-current compile with clang & ccache [tacking on an idea]

[Jeffrey Bouquet]

On Tue, 24 Nov 2015 10:31:37 +0100, M&S - Krasznai András 
 wrote:

> Good morning!
> 
> I experience the following errors:
> 
> 
> after setting up ccache according to the howto I tried to compile world and 
> kernel.
> 
> 
> 
> make buildworld
> 
> 
> 
> runs correctly, takes appr. 3 hours to finish for the first run. Repeating it 
> finishes in a little less than 1 hour.
> 
> 
> 
> Make -j5 buildworld
> 
> 
> 
> also finishes correctly and takes about 23 minutes.
> 
> 
> 
> After finishing the kernel compile
> 
> 
> 
> Make installkernel
> 
> Reboot
> 
> 
> 
> Then
> 
> 
> 
> make installworld
> 
> 
> 
> gives a lot of error messages:
> 
> 
> 
> ccache: error: Could not find compiler "cc" in PATH
> 
> 
> 
> but finishes, and the system appears to be working, but I think there must be 
> some problem what I could not find.
> 
> 
> 
> 
> 
> Compilation and installation finishes correctly if i do not use ccache but 
> rather slow.
> 
> 
> 
> The system has been reinstalled from scratch, source tree was downloaded on 
> Friday and updated few minutes before compile on Monday.
> 
> The kernel config is a stripped down GENERAL (I left out those drivers and 
> kernel modules which handle hardware not present in my laptop).
> 
> I use src.conf to eliminate compiling such components which I do not use 
> (BLUETOOTH, IPX/SPX, etc). COMPILER_TYPE is set in my .cshrc to clang.
> 
> 
> 
> What can I do to eliminate the ccache error during installworld apart from 
> not using ccache?
> 
> 
> 
> 
> 
> Best regards
> 
> 
> 
> András Krasznai
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[sorry if duplicate, keyboard error... tab key or something with the webmail]

Having experienced similar errors during single user mode installword, I was
wondering if a FLAG or --switch could be added to "make installworld" so that
all the $cc >> actual binary [precheck] and all the expected directories that 
are destinations
exist and are not files [precheck] , and optionally even a 
trial-run-install-to-elsewhere "check
for such errors" pre-install runthough, like "-n" in other cli [binaries].

OR a section in UPDATING with a proven [iow, tested on
several and many ... mfsBSD... DESTDIR... cdr... etc ] procedure to accomplish 
the same...

The lack of which is precluding upgrading very often now, as opposed to other 
years, 
since CURRENT... 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: freebsd-current compile with clang & ccache

[Jeffrey Bouquet]

On Tue, 24 Nov 2015 10:31:37 +0100, M&S - Krasznai András 
 wrote:

> Good morning!
> 
> I experience the following errors:
> 
> 
> after setting up ccache according to the howto I tried to compile world and 
> kernel.
> 
> 
> 
> make buildworld
> 
> 
> 
> runs correctly, takes appr. 3 hours to finish for the first run. Repeating it 
> finishes in a little less than 1 hour.
> 
> 
> 
> Make -j5 buildworld
> 
> 
> 
> also finishes correctly and takes about 23 minutes.
> 
> 
> 
> After finishing the kernel compile
> 
> 
> 
> Make installkernel
> 
> Reboot
> 
> 
> 
> Then
> 
> 
> 
> make installworld
> 
> 
> 
> gives a lot of error messages:
> 
> 
> 
> ccache: error: Could not find compiler "cc" in PATH
> 
> 
> 
> but finishes, and the system appears to be working, but I think there must be 
> some problem what I could not find.
> 
> 
> 
> 
> 
> Compilation and installation finishes correctly if i do not use ccache but 
> rather slow.
> 
> 
> 
> The system has been reinstalled from scratch, source tree was downloaded on 
> Friday and updated few minutes before compile on Monday.
> 
> The kernel config is a stripped down GENERAL (I left out those drivers and 
> kernel modules which handle hardware not present in my laptop).
> 
> I use src.conf to eliminate compiling such components which I do not use 
> (BLUETOOTH, IPX/SPX, etc). COMPILER_TYPE is set in my .cshrc to clang.
> 
> 
> 
> What can I do to eliminate the ccache error during installworld apart from 
> not using ccache?
> 
> 
> 
> 
> 
> Best regards
>

Having something similar after an installworld in single user mode, I was 
wondering if
a FLAG 
> 
> 
> András Krasznai
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Unstable kernel (dumbbell) crashes

[Jeffrey Bouquet]

On Sun, 20 Dec 2015 20:04:20 +0200, Beeblebrox  wrote:

> Hello.
> 
> I have been away from my FreeBSD system for over 7 months. The first on my 
> return was to update world/kernel then do a full poudriere run for all my 
> packages. The process had many problems; I'm reporting items below as FYI.
> I'm tracking https://github.com/dumbbell/freebsd.git for my Radeon card.
> 
> 1. installworld ran into same problem as below and I got around it by 
> following the prescription therein: 
> https://lists.freebsd.org/pipermail/freebsd-testing/2015-September/001094.html
> Reviewing the questions asked in the thread, I find nothing of significance 
> in my particular case. Thus, still a mystery.
> 
> 2. The pkgng DB has become buggy & inconsistent. I am preparing to "pkg 
> delete -a" and re-install all from a list after the poudriere run finishes.
> 
> 3. The newly built kernel keeps crashing and re-booting unpredictably. The 
> poudriere run seems to have something to do with triggering this.
> 
> 4. Service dbus still fails to start from /etc/rc.conf (which prevents xorg 
> login) and must be started manually.
> 
> 5. I built and booted into a DEBUG kernel. The system quickly becomes 
> unstable and eventually the simplest commands (ls or cat) take over 60 secs 
> to respond. File containing dmesg output and memory status is attached. 
> However, Memory status seems to be a symptom and not a cause. 
> 
> Regards.
> 
> -- 
> FreeBSD_amd64_11-Current_RadeonKMS
> Please CC my email when responding, mail from list is not delivered.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Yesterday I updated most packages from a v11 that had not been updated in many 
months.  Strange pkg messages
were solved by wholesale deleting of particular mentions in the "pkg upgrade" 
output and deleting orphaned packages/ports
from the output of "pkg version -vRL=  " (or -vIL)" after make fetchindex and 
portsdb -u...

pkg wanting to remove files I was prepared for by running it all via
script log1 pkg upgrade
script log2 pkg upgrade
until it all was done.
One setback was continually wanting to download tex* (an hour download for one 
package) that I did not want
installed and the manpages are still terse as to how to prevent that.
Not a big concern; that is not my principal BSD machine. 

All that is sort of aside.

The reason for this reply is I was wondering if an UPDATING entry in /usr/src 
at the bottom, under COMMON ITEMS...
could be (something to the
effect that if an installworld fails, one could download a month-old .txz or 
.tar or something  ) and recover
by in effect rolling back all the system binaries and libraries.   )

That is somewhat easier than...
... the more-difficult
Even better if some script could be crafted ascertaining which files within the 
system may be at fault. 

Apologies for not answering anything in the mail above.  I've no recollection 
of any answer I could reply to each/any
of the questions...  sort of like a "me too" but only for a troubled 
installworld (often) when it builds fine.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Q about fsck_ffs usage detail...

[Jeffrey Bouquet]

After trial and error ( not easily crafted from the man page)
crafting the "mount" command below...

I've on a todo list a  once-in-a-while fsck_ffs  ( in single user mode
or init 1), each filesystem ( eventually ) so that journalling is double checked
as accurate (ufs2)

"mount -t ufs -o rw /dev/gtp/root /  "
( ^^ that, not easily crafted from the man page examples, unless it works
sometimes and does not work other times, or needs some precise
order.  This command worked today...)

So much for documentation.
On to the question.

The 'task' would be to run fsck_ffs -y on each filesystem once in a while.
However, after remounting root or some other filesystem rw, the
(NO_WRITE) still appears in fsck_ffs ... appearing to make the effort
moot.   (Since it also answers (No) to its resulting ?repair? questions...)

Fault of "init 1" rather than safe mode at boot, or some unintended 
not-working-yet
fault of fsck_ffs, or some easier way to accomplish the stated task?  

Apologies for not asking it elsewhere... seems like one or two persons reading
this list may know more than others and/or sometimes do the same
commands, every once in a while or after a crash to the debugger instance.

Thanks.
( Not really urgent that anyone answers.  More of an inquiry than a problem... 
at least at
r288246...  )
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: clang/3.7.1/include/ does not exist?

[Jeffrey Bouquet]

On Mon, 28 Dec 2015 18:39:59 -0800 (PST), Roger Marquis  
wrote:

> Anyone else seeing these buildworld errors?
> 
>===> lib/clang/include (install)
>sh /usr/src/tools/install.sh -C -o root -g wheel -m 444
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/__stddef_max_align_t.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/__wmmintrin_aes.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/__wmmintrin_pclmul.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/adxintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/altivec.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/ammintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/arm_acle.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx2intrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx512bwintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx512cdintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx512dqintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx512erintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx512fintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx512vlbwintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx512vldqintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avx512vlintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/avxintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/bmi2intrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/bmiintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/cpuid.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/cuda_builtin_vars.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/emmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/f16cintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/fma4intrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/fmaintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/fxsrintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/htmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/htmxlintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/ia32intrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/immintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/lzcntintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/mm3dnow.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/mm_malloc.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/mmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/module.modulemap
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/nmmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/pmmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/popcntintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/prfchwintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/rdseedintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/rtmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/s390intrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/shaintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/smmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/tbmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/tmmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/vadefs.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/vecintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/wmmintrin.h
>
> /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/lib/Headers/x86intrin.h
>
> /usr/src/lib/clang/include/../../../

UPDATING revision and seperate edge-case question(s)

[Jeffrey Bouquet]

Having unexpectedly built world and kernel GENERIC on 3-8 Current, that is not
the principal system [1] ... browsing its UPDATING at the bottom the method(s) 
are
not so precise and/or informative [follows...]

[make world]
make kernel
installworld
 where is installkernel
 
make buildworld
make kernel
mm...
make installworld
mm...
 where is installkernel

but in motd where I save howtos

backups
check nosuid gone
make buildworld
make buildkernel
single user
mm...  [take good notes]
installworld

... and for a lack of time, have to put it all on paper (several draft revisions
within motd )

and in another /usr/src-old

svn sources
move make.conf
check nosuid
buildworld
buildkernel [ compare GENERICS assumed], add compatN etc
installkernel
mergemaster first type, using /usr/src/.../mergemaster.sh
single-user (yet)
installworld
mergemaster (complete )
install newly needed compatNif necc.
make delete-old  ( and sometimes a pipe y | make... or something)
restore nosuid
restore make.conf
rebuild nvidia-driver etc if necc.

AND steps I often take that I've not listed...

So, the latter example is more complete than the ones before it
However, I think other things may be missing
what if it should include a 2a make distribution  2b... make release etc 
which I have no 
  experience with...

/ end of requested another section in UPDATING with commented more-complete 
steps from
someone with more knowledge than I...
.
[1]

Edge case...
buildworld/kernel on another machine that is/was backup except that it ran out 
of space
on a few filesystems, so is NOT backup...
wishing for a foolproof method to script its expected 
installkernel/installworld onto an
attached main-os disk,  something with rsync... to expedite recovery from the 
main-os
disk installworld that fails at some point midway, meaning 
directory-by-directory fixes
using cp, gcp, rsync until the hosed installworld is usable again (I've done it 
before, that
is why I am asking for a feature that will preclude the installworld failure, 
something like
/work/ /stage/ in ports, where the /stage-installworld/ has been tested every 
which way
so that if the stage-installworld completes, the regular installworld is 
guaranteed to 
complete.  
Seeming about a half-years work on someone's part, just adding this edge case in
case someone has perchance crafted something similar, would jumpstart something
similar as a feature, and/or explain an equivalent methodology, to increase the
reliability of updating a system, say upon a critical security advisory 
happening to
every os on the web all at once...

...
ASKING NO RESPONSE to this email to here, do not wish to waste anyone's time, 
just
to put forth a few ideas...
..
Thanks for reading.

J. Bouquet

 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fwd: Re: UPDATING revision and seperate edge-case question(s)

[Jeffrey Bouquet]

Sorry, sent it to this same email originally, on to the list...

- Start Forwarded Message -
Sent: Sat, 12 Mar 2016 17:33:31 -0800 (PST)
From: "Jeffrey Bouquet" 
To: "jbtakk" 
Subject: Re: UPDATING revision and seperate edge-case question(s)

Just for completeness, the buildworld draft section
I wrote below..., three were missing at least... though still
a rough draft... Approximately seven lines added/revised... 

On Sat, 12 Mar 2016 08:10:22 -0800 (PST), "Jeffrey Bouquet" 
 wrote:

> Having unexpectedly built world and kernel GENERIC on 3-8 Current, that is not
> the principal system [1] ... browsing its UPDATING at the bottom the 
> method(s) are
> not so precise and/or informative [follows...]
> 
> [make world]
> make kernel
> installworld
>  where is installkernel
>  
> make buildworld
> make kernel
> mm...
> make installworld
> mm...
>  where is installkernel
> 
> but in motd where I save howtos
> 
> backups
> check nosuid gone
> make buildworld
> make buildkernel
> single user
> mm...  [take good notes]
> installworld
> 
> ... and for a lack of time, have to put it all on paper (several draft 
> revisions
> within motd )
> 
> and in another /usr/src-old
> 
READ UPDATING
> svn sources
> move make.conf
> check nosuid
> buildworld
COMPARE NEWEST GENERIC WITH PRIOR GENERIC IF CUSTOM AND/OR NOT KERNEL
> buildkernel [ compare GENERICS assumed], add compatN etc
> installkernel
sh /usr/src/usr.sbin/mergemaster/mergemaster -vipPc (-F?)# revised
> reboot single-user (yet)
mount -t ufs -u -o rw /dev/gpt/label   /(or whatever) # new
mount -va
#new
df# new
> installworld
> another mergemaster  if necc   # revised
> install newly needed compatNif necc.
> yes | make delete-old  # 
> revised
  yes | make delete-old-libs# 
revised
> restore nosuid
> restore make.conf
> rebuild nvidia-driver etc if necc.
> 
> AND steps I often take that I've not listed...  # some in 
> revision
> 
> So, the latter example is more complete than the ones before it
> However, I think other things may be missing   # see 
> revisions for example
> what if it should include a 2a make distribution  2b... make release etc 
> which I have no 
>   experience with...
> 
> / end of requested another section in UPDATING with commented more-complete 
> steps from
> someone with more knowledge than I...
> .
> [1]
> 
> Edge case...
> buildworld/kernel on another machine that is/was backup except that it ran 
> out of space
> on a few filesystems, so is NOT backup...
> wishing for a foolproof method to script its expected 
> installkernel/installworld onto an
> attached main-os disk,  something with rsync... to expedite recovery from the 
> main-os
> disk installworld that fails at some point midway, meaning 
> directory-by-directory fixes
> using cp, gcp, rsync until the hosed installworld is usable again (I've done 
> it before, that
> is why I am asking for a feature that will preclude the installworld failure, 
> something like
> /work/ /stage/ in ports, where the /stage-installworld/ has been tested every 
> which way
> so that if the stage-installworld completes, the regular installworld is 
> guaranteed to 
> complete.  
> Seeming about a half-years work on someone's part, just adding this edge case 
> in
> case someone has perchance crafted something similar, would jumpstart 
> something
> similar as a feature, and/or explain an equivalent methodology, to increase 
> the
> reliability of updating a system, say upon a critical security advisory 
> happening to
> every os on the web all at once...
> 
> ...
> ASKING NO RESPONSE to this email to here, do not wish to waste anyone's time, 
> just
> to put forth a few ideas...
> ..
> Thanks for reading.
> 
> J. Bouquet
> 
>  
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"




- End Forwarded Message -

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: how to recycle Inact memory more aggressively?

[Jeffrey Bouquet]

rsync... see bottom posting

On Tue, 15 Mar 2016 07:43:46 +0100, olli hauer  wrote:

> On 2016-03-14 15:19, Ian Lepore wrote:
> > On Sun, 2016-03-13 at 19:08 -0700, Adrian Chadd wrote:
> >> On 13 March 2016 at 18:51, Mark Johnston  wrote:
> >>> On Sun, Mar 13, 2016 at 06:33:46PM -0700, Adrian Chadd wrote:
>  Hi,
> 
>  I can reproduce this by doing a mkimage on a large destination
>  file
>  image. it looks like it causes all the desktop processes to get
>  paged
>  out whilst it's doing so, and then the whole UI freezes until it
>  catches up.
> >>>
> >>> mkimg(1) maps the destination file with MAP_NOSYNC, so if it's
> >>> larger
> >>> than RAM, I think it'll basically force the pagedaemon to write out
> >>> the
> >>> image as it tries to reclaim pages from the inactive queue. This
> >>> can
> >>> cause stalls if the pagedaemon blocks waiting for some I/O to
> >>> complete.
> >>> The user/alc/PQ_LAUNDRY branch helps alleviate this problem by
> >>> using a
> >>> different thread to launder dirty pages. I use mkimg on various
> >>> desktop
> >>> machines to build bhyve images and have noticed the problem you're
> >>> describing; PQ_LAUNDRY helps quite a bit in that case. But I don't
> >>> know
> >>> why this would be a new problem.
> >>>
> >>
> >> That's why I'm confused. I just know that it didn't used to cause the
> >> whole UI to hang due to paging.
> >>
> > 
> > I've been noticing this too.  This machine runs 10-stable and this use
> > of the swap began happening recently when I updated from 10-stable
> > around the 10.2 release time to 10-stable right about when the 10.3
> > code freeze began.
> > 
> > In my case I have no zfs anything here.  I noticed the problem bigtime
> > yesterday when rsync was syncing a ufs filesystem of about 500GB from
> > one disk to another (probably 70-80 GB actually needed copying).  My
> > desktop apps were noticibly unresponsive when I activated a window that
> > had been idle for a while (like it would take a couple seconds for the
> > app to begin responding).  I could see lots of swap In happening in top
> > during this unresponsiveness, and noticible amounts of Out activity
> > when nothing was happening except the rsync.
> > 
> > This is amd64, 12GB ram, 16GB swap, a tmpfs had about 400MB in it at
> > the time.  Prior to the update around the 10.3 freeze, this machine
> > would never touch the swap no matter what workload I threw at it (this
> > rsync stuff happens every day, it's the usual workload).
> > 
> 
> I'm not sure if it is the same problem, or port related.
> 
> On two systems without zfs but with many files e.g. svn servers I see now
> from time to time they are running out of swap.
> 
>  kernel: swap_pager_getswapspace(9): failed
>  kernel: swap_pager_getswapspace(16): failed
>  ...
> 
> It also happened on one system during the nightly periodic tasks holding
> only millions of backup files.
> 
> $ freebsd-version -ku
>   10.2-RELEASE-p9
>   10.2-RELEASE-p13
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Just a point I've bought up elsewhere...
I've, if I recall, wrecked several filesystems (although EIDE) using rsync at 
the normal bus rate, and sometimes
thumbdrives with whatever filesystem type on them.

I settled on --bwlimit=1500,  max for unattended  rsync usage and almost every 
day
use --bwlimit=700.

The latter enables several resource-intensive processes ( music, classical 
music videos, svn, pkg, browsing, etc) to
proceed apace concurrently on the desktop (SATA not EIDE) with nary a hang nor 
slowdown.

If I recall, the usual speed is 1 so that is less than ten percent, if I 
recall, of the usual speed.

YMMV.

J.

PS as an afterthough, it would be useful if that were more prominent on the man 
page somewhere or even
in the port's pkg-message or pkg-description.  
The SATA more robust than EIDE on FreeBSD that I've come across, though I 
prefer not to hint at because I
believe it to be the fault of EIDE firmware rather than FreeBSD code. FWIW.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] packaging the base system with pkg(8)

[Jeffrey Bouquet]

On Tue, 15 Mar 2016 08:53:10 +0100, José Pérez  wrote:

> El 2016-03-03 11:27, Matthew Seaman escribió:
> > On 03/02/16 23:54, Glen Barber wrote:
> >> Also note (as repeated below), running 'pkg delete -a' will implicitly
> >> remove base system packages after they are installed.
> > 
> > This has the potential for many feet to be shot, given that up to now,
> > 'pkg delete -a' would always leave you with a viable system.
> 
> Agreed.
> 
> Suggested workaround (a las *grep): create two pkg binaries with 
> different names:
> - "pkg" does what it does now and works on non-base packages by default. 
> Need an extra
>arg to work on base system
> - "syspkg" (or something) works by default on base system
> 
> We'd need way less crutches.
> 
> Regards,
> 
> ---
> José Pérez
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Hmm... 
To reiterate this point..  (1)
As a wish here is for more code within pkg-install so that I do not encounter a 
situation such
as late last night whereupon I had to spend an extra half hour or so figuring 
out that hplip installed
a large number of unwanted additional qt4 ports alongside the cups upgrade with 
pkg, ... so
that a parameter or usual output would show NEW PORTS TO BE INSTALLED alongside 
each
one from WHICH port is the request to install the new dependency...
as a backdrop for this that I just thought of (2)...
  what if pkg on the base system deletes SOONER THAN THE USUAL 
make-delete-old
that PREVENTS/HALTS the successful completion of the pkg updating base?  
Something
critical to pkg itself proceeding?  As a typo or bug?..Maybe another 
cluster of testing 
machines and weeks of testing before each pkg-release-avail or pkg-stable-avail 
became 
known to FreeBSD users in emails... and that would maybe preclude pkg OF BASE 
from
being useful for CURRENT installs due to a lack of testing, and/or make current 
upgrades more
risky.  Unless of course pkg of base is NOT relevant to CURRENT builds.  In 
which case
please pardon the additional text slipping into this two-part food for 
thought... little time to
keep current on FreeBSD details vs FreeBSD ordinary usage cases.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: how to recycle Inact memory more aggressively?

[Jeffrey Bouquet]

On Tue, 15 Mar 2016 09:30:11 -0600, Ian Lepore  wrote:

> On Tue, 2016-03-15 at 07:20 -0700, Jeffrey Bouquet wrote:
> > rsync... see bottom posting
> > 
> > On Tue, 15 Mar 2016 07:43:46 +0100, olli hauer  wrote:
> > 
> > > On 2016-03-14 15:19, Ian Lepore wrote:
> > > > On Sun, 2016-03-13 at 19:08 -0700, Adrian Chadd wrote:
> > > > > On 13 March 2016 at 18:51, Mark Johnston 
> > > > > wrote:
> > > > > > On Sun, Mar 13, 2016 at 06:33:46PM -0700, Adrian Chadd wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I can reproduce this by doing a mkimage on a large
> > > > > > > destination
> > > > > > > file
> > > > > > > image. it looks like it causes all the desktop processes to
> > > > > > > get
> > > > > > > paged
> > > > > > > out whilst it's doing so, and then the whole UI freezes
> > > > > > > until it
> > > > > > > catches up.
> > > > > > 
> > > > > > mkimg(1) maps the destination file with MAP_NOSYNC, so if
> > > > > > it's
> > > > > > larger
> > > > > > than RAM, I think it'll basically force the pagedaemon to
> > > > > > write out
> > > > > > the
> > > > > > image as it tries to reclaim pages from the inactive queue.
> > > > > > This
> > > > > > can
> > > > > > cause stalls if the pagedaemon blocks waiting for some I/O to
> > > > > > complete.
> > > > > > The user/alc/PQ_LAUNDRY branch helps alleviate this problem
> > > > > > by
> > > > > > using a
> > > > > > different thread to launder dirty pages. I use mkimg on
> > > > > > various
> > > > > > desktop
> > > > > > machines to build bhyve images and have noticed the problem
> > > > > > you're
> > > > > > describing; PQ_LAUNDRY helps quite a bit in that case. But I
> > > > > > don't
> > > > > > know
> > > > > > why this would be a new problem.
> > > > > > 
> > > > > 
> > > > > That's why I'm confused. I just know that it didn't used to
> > > > > cause the
> > > > > whole UI to hang due to paging.
> > > > > 
> > > > 
> > > > I've been noticing this too.  This machine runs 10-stable and
> > > > this use
> > > > of the swap began happening recently when I updated from 10
> > > > -stable
> > > > around the 10.2 release time to 10-stable right about when the
> > > > 10.3
> > > > code freeze began.
> > > > 
> > > > In my case I have no zfs anything here.  I noticed the problem
> > > > bigtime
> > > > yesterday when rsync was syncing a ufs filesystem of about 500GB
> > > > from
> > > > one disk to another (probably 70-80 GB actually needed copying). 
> > > >  My
> > > > desktop apps were noticibly unresponsive when I activated a
> > > > window that
> > > > had been idle for a while (like it would take a couple seconds
> > > > for the
> > > > app to begin responding).  I could see lots of swap In happening
> > > > in top
> > > > during this unresponsiveness, and noticible amounts of Out
> > > > activity
> > > > when nothing was happening except the rsync.
> > > > 
> > > > This is amd64, 12GB ram, 16GB swap, a tmpfs had about 400MB in it
> > > > at
> > > > the time.  Prior to the update around the 10.3 freeze, this
> > > > machine
> > > > would never touch the swap no matter what workload I threw at it
> > > > (this
> > > > rsync stuff happens every day, it's the usual workload).
> > > > 
> > > 
> > > I'm not sure if it is the same problem, or port related.
> > > 
> > > On two systems without zfs but with many files e.g. svn servers I
> > > see now
> > > from time to time they are running out of swap.
> > > 
> > >  kernel: swap_pager_getswapspace(9): failed
> > >  kernel: swap_pager_getswapspace(16): failed
> > >  ...
> > > 
> > > It also happened on one system during the 

Re: [CFT] packaging the base system with pkg(8)

[Jeffrey Bouquet]

On Tue, 19 Apr 2016 20:18:40 +0300, Lev Serebryakov  wrote:

> On 19.04.2016 19:28, Nathan Whitehorn wrote:
> 
> > 3. Have ~10 meta packages that just depend on sets of the 755 packages
> > and hide the internal details. This gives the user experience of (1)
> > with the implementation of (2), and is marginally more complex than either.
>   How does it help Slawa with his broken system when "pkg upgrade"
> replace only half of "base" packages?
> 
>  Meta-packages as they are now: "no files, only dependencies" doesn't
> help here at all.
> 
>   Really, if I want "base but no sendmail" I want easy way to see it
> after 5 years after installation, and 755 packages, covered or not by
> meta-packages, will need me to read all list of 754 packages to see,
> that there is no sendmail, for example. It is trivial example, but it is
> completely valid. And there are many other such corner cases, which is
> common for administrators and ops, but not for developers.
> 
>  Please, consider ops and admins, who must support old installations,
> often made by other, not-reachable, people, and stuff like this,
> 
> -- 
> // Lev Serebryakov


Thoughts PRO pkg base from here:

 it can fix a broken installworld that breaks midway rendering the system no 
able to login, not
 able to compile or install futher, or some other event... Can those failures 
be crafted purposely
 to show how the could be readily  per procedure if a usual installworld fails?

Thoughts ANTI pkg base from here:
 Several, but I have thought of more work required for developers who have 
custom kernels and
  a large amount of code that is BETA and not READY yet and are slowed down by 
conforming
 to additional pkg-base requirements.. hindering creativity
 ...
 Sparse initial documentation or at some time not upto par
 ...
 *FLOWCHART" demonstrating precisely the relationship between a pure-pkg-base 
and  pure-svn-base
 system, a mixture of the two, how to migrate parts/all of one to the other, 
one edge a desired install
  or several types of same, the other (two) edges where one starts out from... 
that could be updated
 over the years for a comprehensive overview.
 
[ AS AN ASIDE,  ] I always tend to think that as missing already in pkg, 
svn, synth, poudriere, jails,
 chroot, wpa_supplicant, ndisalator, linux-c6, binutils >> << gcc , zfs, 
ssh_config, ipfw, pf, geli,
 gpart, UEFI, xorg.conf, some individual ports, [ I should stop typing 
here, because even as I
 type more things come to mind... problem with a port ? pr OR maintainer OR 
documentation OR...
 flowchart... etc ]
 stuff-to-leave-out-or-include-in-a-kernel, buildworld/installworld, 
ppp.conf, NOT AS CRITICISM but
 as "Why is it not at least as good for newbies to each concept or better 
than a WIKI !!!  as
 not only the simplified explanation sometimes can be made more apparent of 
which cli to issue next,
 but time spent reading stuff NOT specific to the task at hand is saved. 
 
  Adequate testing? some breakage bound to happen... fixing such breakage 
procedures in place?
  A UPDATING for pkg-base specifically? 

Again, not wishing to waste one's time, just writing down what I've thought of 
so far, freely simply file
it away rather than reply online...  my answers to any reply could simply 
re-iterate the background to the
above (I am NOT well versed in many topics of FreeBSD, just in the more useful 
ones at the
installs that I use daily... ).
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

jpg attached, unsure if will go though... libc build error, svn of today

[Jeffrey Bouquet]

unistd


/usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function body 
after function declarator
intexecl(  .
 332:46:
same...

stops libc
otherwise clang36 seems to be building so far, if it builds unsure about 
installworld
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[WAS:libc build error] installworld result not satisfactory yet...

[Jeffrey Bouquet]

On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude  wrote:

> On 2016-04-20 12:06, Jeffrey Bouquet wrote:
> > unistd
> > 
> > 
> > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function 
> > body after function declarator
> > intexecl(  .
> >  332:46:
> > same...
> > 
> > stops libc
> > otherwise clang36 seems to be building so far, if it builds unsure about 
> > installworld
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> 
> The mailing list strips attachments. Can you upload it somewhere and
> provide a link
> 
> -- 
> Allan Jude
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Well, it is now r298350 Wed Apr 20...
However several problems

SINGLE-USER BOOT PROBLEMS
1... usual boot fails, this is single-user adjusted, but I cannot add swap 
(swapon? swapctl?)
1a...  the last time, it was fixed with using the old /kernel ... 

multi-user boot problems

2... the last usual boot dumped with vm_pager or something,  verbose boot times 
out with xpt_config not completing.
2a could be a wrong setting is loader.conf, the nvidia.ko not yet updated 
(which it now is ) for the latter
  case I have yet to reboot to test
  2b...   Reboot to test takes longer, /rescue/mount each filesystem 
individually... 


As one might surmise, I'd rather see buildworld made more foolproof than other 
recent improvements 
(pkg, zfs, ...)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [WAS:libc build error] it is HALF solved bw-iw cycle

[Jeffrey Bouquet]

On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> 
> 
> On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude  wrote:
> 
> > On 2016-04-20 12:06, Jeffrey Bouquet wrote:
> > > unistd
> > > 
> > > 
> > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function 
> > > body after function declarator
> > > intexecl(  .
> > >  332:46:
> > > same...
> > > 
> > > stops libc
> > > otherwise clang36 seems to be building so far, if it builds unsure about 
> > > installworld
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > > 
> > 
> > The mailing list strips attachments. Can you upload it somewhere and
> > provide a link
> > 
> > -- 
> > Allan Jude
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 
> Well, it is now r298350 Wed Apr 20...
> However several problems
> 
> SINGLE-USER BOOT PROBLEMS
> 1... usual boot fails, this is single-user adjusted, but I cannot add swap 
> (swapon? swapctl?)
> 1a...  the last time, it was fixed with using the old /kernel ... 
> 
> multi-user boot problems
> 
> 2... the last usual boot dumped with vm_pager or something,  verbose boot 
> times out with xpt_config not completing.
> 2a could be a wrong setting is loader.conf, the nvidia.ko not yet updated 
> (which it now is ) for the latter
>   case I have yet to reboot to test
>   2b...   Reboot to test takes longer, /rescue/mount each filesystem 
> individually... 
> 
> 
> As one might surmise, I'd rather see buildworld made more foolproof than 
> other recent improvements 
> (pkg, zfs, ...)

>From backup, I have r288246 kernel and nvidia.ko  (v11)
from source, I have world and all except those TWO files at r298350 )(v11), 
nvidia (newer) won't load with older kernel
A few at-boot scripts no longer work as expected... but no other major problems 
(swap is present again)
(multi-user boot works) 

Best practice maybe to update the kernel?  It is a custom one from way back in 
2004 initially
without sound drivers and without debug symbols...  and many esoteric lines 
added which I cobbled
together at first then changed per diffs of GENERIC over the years...

Thanks for any known methods

J. Bouquet
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: limits: setrlimit umtxp: Invalid argument

[Jeffrey Bouquet]

On Thu, 10 Mar 2016 07:16:05 +0900, Brendan Sechter  wrote:

> > Subject: Re: limits: setrlimit umtxp: Invalid argument
> > From: florian.ermi...@alumni.tu-berlin.de
> > Date: Wed, 9 Mar 2016 18:45:37 +0100
> > To: e...@vangyzen.net; sg...@hotmail.com; freebsd-current@freebsd.org
> >
> > Am 9. März 2016 16:59:47 MEZ, schrieb Eric van Gyzen :
> >> On 03/09/2016 09:49, Brendan Sechter wrote:
> >>> I am running an 11.0-CURRENT VM.
> >>> After recently updating, the following appears on startup and
> >>> dhclient fails to start.
> >>>
> >>> Starting dhclient.
> >>> limits: setrlimit umtxp: Invalid argument
> >>> /etc/rc.d/dhclient: WARNING: failed to start dhclient
> >>>
> >>> Similar messages appear for the following.
> >>>
> >>> devd pflog syslogd ntpd powerd sshd sendmail_submit
> >>> sendmail_msp_queue cron
> >>>
> >>> Reverting to the previous kernel did not resolve the issue.
> >>> I can manually start dhclient and ntp, but not sshd.
> >>>
> >>> I do not trust that my uname information is being updated with
> >>> with build, but here it is.
> >>>
> >>> $ uname -vm
> >>> FreeBSD 11.0-CURRENT #0 r287598: Thu Sep 10 14:45:48 JST 2015
> >>> root@:/usr/obj/usr/src/sys/MIRAGE_KERNEL amd64
> >>
> >> This information comes directly from the running kernel, so it looks
> >> like your kernel is not getting updated. This seems consistent
> >> with the above error messages, although I haven't tested this
> >> case. The userland tools are aware of the newly added umtxp
> >> limit, but the kernel is not aware.
> >>
> >> Eric
> >
> > I got this problem on my laptop, too. I somehow managed not to
> > install the kernel during a recent update so my userland is slightly
> > newer than my 11-CURRENT r292755 kernel (and also forgot to
> > make proper ZFS snapshots…).
> >
> > While I can build a newer kernel but when I boot i.e. r296556
> > `zfs(8)' coredumps and I can't mount anything but the rootfs…
> > I guess I need to get kernel & userland back in sync to fix this.
> >
> > I will try to build the userland matching my kernel first as
> > I know its revision from `uname -a`.
> > If anyone has a better approach or tips, please let me know.
> 
> My userland was up to date.  This is what I did to get the kernel
> in sync enough to resolve the issue.
> 
> svn up /usr/src # omit if want to use the exact same version as world
> cd /usr/src
> make buildkernel KERNCONF=MYKERNEL
> make installkernel KERNCONF=MYKERNEL
> 
> I found a problem with my kernel configuration in the process.
> The plan is to rebuild everything after the configuration issue is
> sorted out.  You may wish to use GENERIC just to get things up
> and running again.
> 
> Regards,
> -Brendan
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


I've a working pf.ko kernel and nvidia.ko from r288246 Sep 26 2015 and an 
installed
buildworld from yesterday Apr 20 2016.  The kernel is custom and I've also a 
large-ish
loader.conf.  I've no wish to run GENERIC with either debugging symbols nor 
sound enabled.

sendmail_submit is broken, not a showstopper but root gets none of his mail.
cron is broken, not a showstopper but one cron I've setup does not run
Per this thread which narrowed down the issue of out of sync problems,
dhclient devd pflog syslogd ntpd and sshd  *if I had them used* would be
not functional.   Unsure in each case.

Given a 2004-ish custom kernel, a GENERIC from this month, and a GENERIC from 
Sept 2015, is there
any not time consuming way to do a diff between two or three of them and bring 
the custom
kernel upto par with the GENERIC as far as bootability, considering the 
possibility that it is
a loader.conf setting that is at fault?

something like /sbin/kernel-too-old
^^^

" please check foo foo from loader conf " or "please check bar bar from 
CUSTOM-K " or even
" foo bar from CUSTOM-K is missing... "  

...a utility that would lessen the need for adding/subtracting blocks
of  (custom ) kernel stuff to/from generic and recompiling one-by-one,
or vice-versa, to/from the custom kernel config,
 seems like a 40 day project UNLESS someone
has run into a similar custom -vs- generic situation as a matter of course and 
has a workflow to
lessen whatever time and compilation effort it takes, which is basically what I 
am asking here unless
a summer of code expert coder of FreeBSD fame knows that the hypothetical 
binary above could
be crafted more easily than not and be a tool for developers as well as simple 
FreeBSD users such
as myself...

Thanks
PS I encourage anyone with a readily helpful answer to add it to UPDATING as a 
resource for
persons other than myself who encounter the same difficulty...
___
freebsd-current@freebsd.org mailing li

[Solved] [WAS:libc build error] Mostly all solved bw-iw-ik from 4-20-2016

[Jeffrey Bouquet]

On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> 
> 
> On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" 
>  wrote:
> 
> > 
> > 
> > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude  
> > wrote:
> > 
> > > On 2016-04-20 12:06, Jeffrey Bouquet wrote:
> > > > unistd
> > > > 
> > > > 
> > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected 
> > > > function body after function declarator
> > > > intexecl(  .
> > > >  332:46:
> > > > same...
> > > > 
> > > > stops libc
> > > > otherwise clang36 seems to be building so far, if it builds unsure 
> > > > about installworld
> > > > ___
> > > > freebsd-current@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to 
> > > > "freebsd-current-unsubscr...@freebsd.org"
> > > > 
> > > 
> > > The mailing list strips attachments. Can you upload it somewhere and
> > > provide a link
> > > 
> > > -- 
> > > Allan Jude
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> > 
> > Well, it is now r298350 Wed Apr 20...
> > However several problems
> > 
> > SINGLE-USER BOOT PROBLEMS
> > 1... usual boot fails, this is single-user adjusted, but I cannot add swap 
> > (swapon? swapctl?)
> > 1a...  the last time, it was fixed with using the old /kernel ... 
> > 
> > multi-user boot problems
> > 
> > 2... the last usual boot dumped with vm_pager or something,  verbose boot 
> > times out with xpt_config not completing.
> > 2a could be a wrong setting is loader.conf, the nvidia.ko not yet 
> > updated (which it now is ) for the latter
> >   case I have yet to reboot to test
> >   2b...   Reboot to test takes longer, /rescue/mount each filesystem 
> > individually... 
> > 
> > 
> > As one might surmise, I'd rather see buildworld made more foolproof than 
> > other recent improvements 
> > (pkg, zfs, ...)
> 
> From backup, I have r288246 kernel and nvidia.ko  (v11)
> from source, I have world and all except those TWO files at r298350 )(v11), 
> nvidia (newer) won't load with older kernel
> A few at-boot scripts no longer work as expected... but no other major 
> problems (swap is present again)
> (multi-user boot works) 
> 
> Best practice maybe to update the kernel?  It is a custom one from way back 
> in 2004 initially
> without sound drivers and without debug symbols...  and many esoteric lines 
> added which I cobbled
> together at first then changed per diffs of GENERIC over the years...
> 
> Thanks for any known methods
> 
> J. Bouquet
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Updated to a slightly-less-than-full GENERIC.  Still dumped core.  Moved 
loader.conf out of
the way, works fine.  What will take some time now is moving loader.conf back 
piece by piece
[until/if there is/ever was a utility to do it for us... ] to find the 
problematic line or two, then
resume testing of the install of the custom kernel that also is 'fail' status 
at this point... unless/until
I decide to also test it, THEN resume the loader.conf line-by-line back in...

tl;dr   loader.conf problematic line and maybe an additional unknown in either 
kernel text file.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Re: Installworld, BW, IK fixed, here are the in > out loader.conf lines

[Jeffrey Bouquet]

On Thu, 21 Apr 2016 13:29:59 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> 
> 
> On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" 
>  wrote:
> 
> > 
> > 
> > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" 
> >  wrote:
> > 
> > > 
> > > 
> > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude  
> > > wrote:
> > > 
> > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote:
> > > > > unistd
> > > > > 
> > > > > 
> > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected 
> > > > > function body after function declarator
> > > > > intexecl(  .
> > > > >  332:46:
> > > > > same...
> > > > > 
> > > > > stops libc
> > > > > otherwise clang36 seems to be building so far, if it builds unsure 
> > > > > about installworld
> > > > > ___
> > > > > freebsd-current@freebsd.org mailing list
> > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > > To unsubscribe, send any mail to 
> > > > > "freebsd-current-unsubscr...@freebsd.org"
> > > > > 
> > > > 
> > > > The mailing list strips attachments. Can you upload it somewhere and
> > > > provide a link
> > > > 
> > > > -- 
> > > > Allan Jude
> > > > ___
> > > > freebsd-current@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to 
> > > > "freebsd-current-unsubscr...@freebsd.org"
> > > 
> > > 
> > > Well, it is now r298350 Wed Apr 20...
> > > However several problems
> > > 
> > > SINGLE-USER BOOT PROBLEMS
> > > 1... usual boot fails, this is single-user adjusted, but I cannot add 
> > > swap (swapon? swapctl?)
> > > 1a...  the last time, it was fixed with using the old /kernel ... 
> > > 
> > > multi-user boot problems
> > > 
> > > 2... the last usual boot dumped with vm_pager or something,  verbose boot 
> > > times out with xpt_config not completing.
> > > 2a could be a wrong setting is loader.conf, the nvidia.ko not yet 
> > > updated (which it now is ) for the latter
> > >   case I have yet to reboot to test
> > >   2b...   Reboot to test takes longer, /rescue/mount each filesystem 
> > > individually... 
> > > 
> > > 
> > > As one might surmise, I'd rather see buildworld made more foolproof than 
> > > other recent improvements 
> > > (pkg, zfs, ...)
> > 
> > From backup, I have r288246 kernel and nvidia.ko  (v11)
> > from source, I have world and all except those TWO files at r298350 )(v11), 
> > nvidia (newer) won't load with older kernel
> > A few at-boot scripts no longer work as expected... but no other major 
> > problems (swap is present again)
> > (multi-user boot works) 
> > 
> > Best practice maybe to update the kernel?  It is a custom one from way back 
> > in 2004 initially
> > without sound drivers and without debug symbols...  and many esoteric lines 
> > added which I cobbled
> > together at first then changed per diffs of GENERIC over the years...
> > 
> > Thanks for any known methods
> > 
> > J. Bouquet
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 
> Updated to a slightly-less-than-full GENERIC.  Still dumped core.  Moved 
> loader.conf out of
> the way, works fine.  What will take some time now is moving loader.conf back 
> piece by piece
> [until/if there is/ever was a utility to do it for us... ] to find the 
> problematic line or two, then
> resume testing of the install of the custom kernel that also is 'fail' status 
> at this point... unless/until
> I decide to also test it, THEN resume the loader.conf line-by-line back in...
> 
> tl;dr   loader.conf problematic line and maybe an additional unknown in 
> either kernel text file.
> ___
> fr

new content: [ buildworld fixed ] now network drops out daily

[Jeffrey Bouquet]

- Start Forwarded Message -
Sent: Thu, 21 Apr 2016 14:10:40 -0700 (PDT)
From: "Jeffrey Bouquet" 
To: "current" 
Subject: Re: Re:  Installworld, BW, IK fixed, here are the in > out
 loader.conf lines



On Thu, 21 Apr 2016 13:29:59 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> 
> 
> On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" 
>  wrote:
> 
> > 
> > 
> > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" 
> >  wrote:
> > 
> > > 
> > > 
> > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude  
> > > wrote:
> > > 
> > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote:
> > > > > unistd
> > > > > 
> > > > > 
> > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected 
> > > > > function body after function declarator
> > > > > intexecl(  .
> > > > >  332:46:
> > > > > same...
> > > > > 
> > > > > stops libc
> > > > > otherwise clang36 seems to be building so far, if it builds unsure 
> > > > > about installworld
> > > > > ___
> > > > > freebsd-current@freebsd.org mailing list
> > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > > To unsubscribe, send any mail to 
> > > > > "freebsd-current-unsubscr...@freebsd.org"
> > > > > 
> > > > 
> > > > The mailing list strips attachments. Can you upload it somewhere and
> > > > provide a link
> > > > 
> > > > -- 
> > > > Allan Jude
> > > > ___
> > > > freebsd-current@freebsd.org mailing list
> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to 
> > > > "freebsd-current-unsubscr...@freebsd.org"
> > > 
> > > 
> > > Well, it is now r298350 Wed Apr 20...
> > > However several problems
> > > 
> > > SINGLE-USER BOOT PROBLEMS
> > > 1... usual boot fails, this is single-user adjusted, but I cannot add 
> > > swap (swapon? swapctl?)
> > > 1a...  the last time, it was fixed with using the old /kernel ... 
> > > 
> > > multi-user boot problems
> > > 
> > > 2... the last usual boot dumped with vm_pager or something,  verbose boot 
> > > times out with xpt_config not completing.
> > > 2a could be a wrong setting is loader.conf, the nvidia.ko not yet 
> > > updated (which it now is ) for the latter
> > >   case I have yet to reboot to test
> > >   2b...   Reboot to test takes longer, /rescue/mount each filesystem 
> > > individually... 
> > > 
> > > 
> > > As one might surmise, I'd rather see buildworld made more foolproof than 
> > > other recent improvements 
> > > (pkg, zfs, ...)
> > 
> > From backup, I have r288246 kernel and nvidia.ko  (v11)
> > from source, I have world and all except those TWO files at r298350 )(v11), 
> > nvidia (newer) won't load with older kernel
> > A few at-boot scripts no longer work as expected... but no other major 
> > problems (swap is present again)
> > (multi-user boot works) 
> > 
> > Best practice maybe to update the kernel?  It is a custom one from way back 
> > in 2004 initially
> > without sound drivers and without debug symbols...  and many esoteric lines 
> > added which I cobbled
> > together at first then changed per diffs of GENERIC over the years...
> > 
> > Thanks for any known methods
> > 
> > J. Bouquet
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 
> 
> Updated to a slightly-less-than-full GENERIC.  Still dumped core.  Moved 
> loader.conf out of
> the way, works fine.  What will take some time now is moving loader.conf back 
> piece by piece
> [until/if there is/ever was a utility to do it for us... ] to find the 
> problematic line or two, then
> resume testing of the install of the custom kernel that also is 'fail' status 
> at this point... unless/until
> I decide to als

Re: new content: [ buildworld fixed ] now network drops out daily

[Jeffrey Bouquet]

On Fri, 22 Apr 2016 06:22:04 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> 
> 
> - Start Forwarded Message -
> Sent: Thu, 21 Apr 2016 14:10:40 -0700 (PDT)
> From: "Jeffrey Bouquet" 
> To: "current" 
> Subject: Re: Re:  Installworld, BW, IK fixed, here are the in > out
>  loader.conf lines
> 
> 
> 
> On Thu, 21 Apr 2016 13:29:59 -0700 (PDT), "Jeffrey Bouquet" 
>  wrote:
> 
> > 
> > 
> > On Wed, 20 Apr 2016 18:37:45 -0700 (PDT), "Jeffrey Bouquet" 
> >  wrote:
> > 
> > > 
> > > 
> > > On Wed, 20 Apr 2016 17:37:16 -0700 (PDT), "Jeffrey Bouquet" 
> > >  wrote:
> > > 
> > > > 
> > > > 
> > > > On Wed, 20 Apr 2016 12:28:29 -0400, Allan Jude  
> > > > wrote:
> > > > 
> > > > > On 2016-04-20 12:06, Jeffrey Bouquet wrote:
> > > > > > unistd
> > > > > > 
> > > > > > 
> > > > > > /usr/src/lib/libc/../../include/unistd.h:330:45: error: expected 
> > > > > > function body after function declarator
> > > > > > intexecl(  .
> > > > > >  332:46:
> > > > > > same...
> > > > > > 
> > > > > > stops libc
> > > > > > otherwise clang36 seems to be building so far, if it builds unsure 
> > > > > > about installworld
> > > > > > ___
> > > > > > freebsd-current@freebsd.org mailing list
> > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > > > To unsubscribe, send any mail to 
> > > > > > "freebsd-current-unsubscr...@freebsd.org"
> > > > > > 
> > > > > 
> > > > > The mailing list strips attachments. Can you upload it somewhere and
> > > > > provide a link
> > > > > 
> > > > > -- 
> > > > > Allan Jude
> > > > > ___
> > > > > freebsd-current@freebsd.org mailing list
> > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > > To unsubscribe, send any mail to 
> > > > > "freebsd-current-unsubscr...@freebsd.org"
> > > > 
> > > > 
> > > > Well, it is now r298350 Wed Apr 20...
> > > > However several problems
> > > > 
> > > > SINGLE-USER BOOT PROBLEMS
> > > > 1... usual boot fails, this is single-user adjusted, but I cannot add 
> > > > swap (swapon? swapctl?)
> > > > 1a...  the last time, it was fixed with using the old /kernel ... 
> > > > 
> > > > multi-user boot problems
> > > > 
> > > > 2... the last usual boot dumped with vm_pager or something,  verbose 
> > > > boot times out with xpt_config not completing.
> > > > 2a could be a wrong setting is loader.conf, the nvidia.ko not yet 
> > > > updated (which it now is ) for the latter
> > > >   case I have yet to reboot to test
> > > >   2b...   Reboot to test takes longer, /rescue/mount each filesystem 
> > > > individually... 
> > > > 
> > > > 
> > > > As one might surmise, I'd rather see buildworld made more foolproof 
> > > > than other recent improvements 
> > > > (pkg, zfs, ...)
> > > 
> > > From backup, I have r288246 kernel and nvidia.ko  (v11)
> > > from source, I have world and all except those TWO files at r298350 
> > > )(v11), nvidia (newer) won't load with older kernel
> > > A few at-boot scripts no longer work as expected... but no other major 
> > > problems (swap is present again)
> > > (multi-user boot works) 
> > > 
> > > Best practice maybe to update the kernel?  It is a custom one from way 
> > > back in 2004 initially
> > > without sound drivers and without debug symbols...  and many esoteric 
> > > lines added which I cobbled
> > > together at first then changed per diffs of GENERIC over the years...
> > > 
> > > Thanks for any known methods
> > > 
> > > J. Bouquet
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listin

nfe0 connection not as reliable; a few questions...

[Jeffrey Bouquet]

Updated current  { from Sept last year } to this week... and nfe0 now seems to 
require a reboot 
daily at least { no access to beyond-the-lan ... } 

Is there maybe some tunable (net.inet... ) related  or sysctl { kern.ipc... } 
similar, that
could be a cause?  New code of ifconfig or the network stack within the last 
seven
months or so? Usual fixes of MTU size to set? 

The coincidence of the daily network stack loss with the installkernel/world 
r298350 would
at first glance rule out hardware issues... Hadn't seen that type of network  
issue before
{ I can connect to the gateway, but the modem  { comtrend } in bridge mode seems
to fail.  }.I checked some of the n...@freebsd.org list to no avail...   
The modem had worked
fine for about two weeks previously... at least.

Apologies for wasting anyone's time; there are tests I could run with more 
machines on the
lan, but though to ask here first.   And did not think of those setups until 
after I had half-completed
this email...

Thanks.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: nfe0 connection not as reliable; a few questions...

[Jeffrey Bouquet]

On Sat, 23 Apr 2016 19:48:46 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> Updated current  { from Sept last year } to this week... and nfe0 now seems 
> to require a reboot 
> daily at least { no access to beyond-the-lan ... } 
> 
> Is there maybe some tunable (net.inet... ) related  or sysctl { kern.ipc... } 
> similar, that
> could be a cause?  New code of ifconfig or the network stack within the last 
> seven
> months or so? Usual fixes of MTU size to set? 
> 
> The coincidence of the daily network stack loss with the installkernel/world 
> r298350 would
> at first glance rule out hardware issues... Hadn't seen that type of network  
> issue before
> { I can connect to the gateway, but the modem  { comtrend } in bridge mode 
> seems
> to fail.  }.I checked some of the n...@freebsd.org list to no avail...   
> The modem had worked
> fine for about two weeks previously... at least.
> 
> Apologies for wasting anyone's time; there are tests I could run with more 
> machines on the
> lan, but though to ask here first.   And did not think of those setups until 
> after I had half-completed
> this email...
> 
> Thanks.
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Progress [still unsure].  On a hunch I ran a small .sh to ping a site 
periodically
[ not constantly and  within terms of its
usage of course.]  That .sh was set up some years back to keep a wifi 
connection up [laptop].
On this desktop, which had a network disconnect at under two hours and under 4 
hours, within
the last twenty-four hours or so, it has
now, at least once, had the network reliable for over six hours.  

I've yet to do two other tests ( outage wholly across the lan and a different 
driver ) but hoping for
this workaround to be feasible...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Issues to maybe prioritize before pkg-base

[Jeffrey Bouquet]

Main disk would not boot cleanly.
could not fsck_ffs, cannot find inode
files went missing from /etc (make.conf, pf.conf, firewall*, 
file went missing from rc.d
files went missing from /etc/X11
shell history file remained locked.
find suddenly could not find /usr/local/lib/*/libc.so.5
freecolor could not find its libraries
Xorg could not find lib* in /usr/local/lib


etc
somewhat fixed those from backup.
Which hosed the latest pkg install * upgrades (byobu bump, etc) which I 
reinstalled
Put the disk on backup, latter mountroot, ran fsck_ffs on the failing disk 
/root and /usr, multiple times,
..
Inexplicably got all libraries back, working, and files restored AS FAR AS I 
KNOW
but as usual in this case, which happens at least twice a year, although I 
restore
the desktop and programs (usually) to a working state, with adequate backups,
.
Why is there not some feature to build more resilency into the operating 
system, so that
it could at least detect (spare copies of .so. in the background, auto check 
etc...)
no matter if it takes more time upon boot, how to self-repair (for newbies or 
INSTALLWORLD fixes)
rather than repair piecemeal by *experienced users* (2004 here) that cannot be 
retold
without complaint, in other words, document failures and retool base tools for 
more
reliability upon inode-disappearing loss of files and directories, especially 
in the case of
/etc /boot etc which are critical to booting to a non-single-user environment.

Why is there ^^^, I suspect, not enough coders, time...
which is why I feel the need to post this issue here, as long as there IS NOT 
enough
coders, time, maybe before pkg-base is fully implemented "pkg-base" could be 
made
resilient to the above type errors. ( sudden missing .so. during a pkg base 
upgrade, for
example...)  
Just as a sort of feature request,  delay it a year or so to make the binaries 
BIGGER and
more capable, static not dynamic, etc...

No real contributing input above... I apologize in advance, if you will allow 
me to do so, just
a freebsd end-user here, no time to contribute due to other issues. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Hdwe UEFI upgrade report...some ??? to maybe ignore

[Jeffrey Bouquet]

I had the main desktop DDR2 mysteriously lose video ( still don't know if it is 
just needing reseating
memory or if the onboard video no longer works or if one of the four bad 
capacitors went too var
awry to still work... lack of time to test..)

Sorry for the formatting

newddr3 msi board FX-8320E..old ddr2 gigabyte ? amd
newusb mouse, had to use usm0  .oldusb mouse > legacy 
mouse adaptor, used psm0
newvt so can exit X (not tested yet)  oldsc
newvidcontrol to set resolution NOT   .   old vidcontrol 
MODE_276 brown black
newonboard EUFI/LEGACY mode  disabled sound   ...   oldgame 
theatre sound card again working
newno parallel port, card on order, ALL SLOTS FULL probably   . 
   oldparallel port onboard
newtwo pcie so Areca and Video card work ..  old
Areca, OR video, used the former
newcost $99 motherboard 
 .oldsecond hand board, probably more than $99
newnfe0 not working, none is WINDOWS strange "gaming" ...  old nfe0
  E2205   fixed with a axe/ue0 usb to ethernet box which I had
  sometimes problems with as to the novice one would try axe0 in wpa_  
etc
  ignoring the instead ue0...
new   msi nvidia 750ti 2gb no PCIE adaptor necc  old  onboard 
video
new  nvidia-driver, had to build from ports.   old  
 nvidia-driver-304   
new  8g 
.   old   2g ddr2

If one prefers DDR2 for a two-cpu-on-lan setup, anyone knows of a very reliable 
source for a pair of mobo/CPU  ?
Not important that anyone answers

Might-be-working-if-reassembled-enough-times-with-legacy-parts pentium 4  and 
DDR2 ( gigabyte amd) motherboards,
... e-waste or send to a FreeBSD developer for test and reuse somewhere?  (each 
run but no video though, amd board
is disassembled... ) 

The only question here I feel the need to address sooner not later is whether 
to duplicate the DDR3 amd system for
in-case-Xorg-crashes-at-dawn backup, or discard the DDR2 board and build/buy 
two DDR2 systems to recreate what
was working about twenty days ago flawlessly... bad capacitors on the 
motherboard notwithstanding.  ( DDR2 amd,
main was gigabyte, backup was msi...  although each without a full range of 
slots vs ATX full size and costlier) 

At any rate is is cathartic to have a fully working v11 vt desktop with sound 
that I had no clue if would work without
RMA, assistance, ... 

One or two items may be omitted from the list above... a 3x5 card has gone 
missing here since yesterday... too much
paperwork in progress. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

[Jeffrey Bouquet]

Will/could there be some kind of UPDATING announcement re which files 
explicitly to 
switch out/remove/replace/checkfor etc the deprecated lines and precisely the 
steps
to replace with new or some other suitable action? Action required for both the 
sshd and
client? Subdirectories involved? etc...  Unclear here, but I don't use SSH 
hardly yet...
despite having bought the book.

On Mon, 8 Aug 2016 14:57:05 -0700, Devin Teske  wrote:

> 
> > On Aug 8, 2016, at 12:39 PM, Bernard Spil  wrote:
> > 
> > Hi Devin,
> > 
> > This resource documents the choices pretty well I think
> > https://stribika.github.io/2015/01/04/secure-secure-shell.html 
> > 
> > Author has made some modifications up to Jan 2016
> > https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md
> >  
> > 
> > 
> > The short answer then is ed25519 or rsa4096, disable both dsa and ecdsa.
> > 
> > Even 6.5p1 shipped with 9.3 supports ed25519.
> > 
> > Cheers,
> > 
> > Bernard.
> > 
> 
> Thanks for confirming, Bernard!
> -- 
> Cheers,
> Devin
> 
> 
> > On 2016-08-08 19:56, Devin Teske wrote:
> >> Which would you use?
> >> ECDSA?
> >> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 
> >> 
> >>  >> >
> >> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover
> >> operation", cryptography experts have also expressed concern over the
> >> security of the NIST recommended elliptic curves,[31]
> >>  >> >
> >> suggesting a return to encryption based on non-elliptic-curve groups.
> >> ""
> >> Or perhaps RSA? (as des@ recommends)
> >> (not necessarily to Glen but anyone that wants to answer)
> >> --
> >> Devin
> >>> On Aug 4, 2016, at 6:59 PM, Glen Barber  wrote:
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
> >>> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
> >>> Please see r303716 for details on the relevant commit, but upstream no
> >>> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
> >>> keys as soon as possible, otherwise there will be issues when upgrading
> >>> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
> >>> 11.0-RELEASE build.
> >>> Glen
> >>> On behalf of: re@ and secteam@
> >>> -BEGIN PGP SIGNATURE-
> >>> Version: GnuPG v2
> >>> iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb
> >>> kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK
> >>> rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl
> >>> GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR
> >>> TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u
> >>> c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs
> >>> 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c
> >>> QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8
> >>> 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r
> >>> mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL
> >>> kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx
> >>> bLbbH2fh5bxDmDXDMdCF
> >>> =LLtP
> >>> -END PGP SIGNATURE-
> >>> ___
> >>> freebsd-annou...@freebsd.org mailing list
> >>> https://lists.freebsd.org/mailman/listinfo/freebsd-announce
> >>> To unsubscribe, send any mail to 
> >>> "freebsd-announce-unsubscr...@freebsd.org"
> >> ___
> >> freebsd-sta...@freebsd.org  mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable 
> >> 
> >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org 
> >> "
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

UPDATING up for an inclusion?

[Jeffrey Bouquet]

Possible man 7 development could be included in /usr/src/UPDATING
 carefully... by someone way more skilled/versed than I. [  Twelve
years and the first I've seen of that man page... today.  ]

Howsoever, I may have read recent forum or freebsd-questions  posts
that could update the man page with newer information, or
caveats.  Unsure. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Just a pair of no-urgency questions...

[Jeffrey Bouquet]

I check freshports.org and freshsource.org daily,  so I can read new features, 
UPDATING etc
without svn usage, and would have been maybe dealt problematic buildworlds etc 
without such.
...
Additionally, I learn the bits and pieces of developer skills, very slowly.

Not a developer here, ever, but for others and here convenience
...
1...   could freshports.org and freshsource.org be officially part of FreeBSD 
so their continued 
existence is assured as the OS progresses?
2...  [the reason primary for this email]  It would be less distracting if 
while I browsed the
pages, a bar [set by cookies, probably] in a unique color, would notify me if I 
had read the
subsequent text, like a forum ' the posts by here are not net' line, and would 
save
time daily.  Can that be easily backported to each of the two sites???  I'd 
even value that
to be an annual fee product I would pay for...
Not a webcoder, obviously...  out of time.

Thanks.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Xorg driver update question

[Jeffrey Bouquet]

I've the aspeed tyan video drivers for V9, but using v11 from when it was 
CURRENT.
What chances of 
xf86-video-astformulated?
the .la and .so working out of the box if placed in the filesystem?  I usually 
have to upgrade those in -nv- etc..
 Anyone using a server board with IPMI and a pcie slot for "usual" GPU and 
running BSD that
  way rather than serial port (like an upgrade ?)  OR do the voltages not match 
in that kind
  of serverboard (tyan in this instance , Xeon ) for aftermarket GPU? 
...
Would not ask here, but I spent a whole lot of time today learning IPMI and I'd 
rather learn about a
hardware workaround...  I've spent years around IPMI hardware but not in an 
administrative capacity.
.
Also, the hardware is not physically onsite yet so no chance to test / 
configure it that way.
...
Thanks in advance for any insight.

Jeff
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg on old current - library woes

[Jeffrey Bouquet]

On Mon, 26 Dec 2016 17:27:06 +0100, Marc UBM Bocklet 
 wrote:

> 
> Hi list,
> 
> I'm writing this as an reminder for others who might be in a similar
> situation. Don't blindly (like me) use pkg on an old current or you'll
> (understandably) run into tons of library / linking issues.
> 
> I update my current only very belatedly and thus was running current
> from around March 2016. pkg correctly detected ABI =
> "FreeBSD:11:amd64"; and installed the requested packages, but of course
> I was missing all kinds of recent library versions (libssl, libpam,
> fopencookie problems in mod_php, among others). This caused me quite a
> headache at first, but then I went from my ancient current to 11-release
> and now everything works like a charm. 
> 
> Searching online, I found only one reference to the situation I had been
> in:
> 
> https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-June/000271.html.
> 
> Maybe pkg could print some kind of warning if you're behind too far on
> current, though admittedly this is very likely some edge case and
> updating to a release version fixed everything. 
> 
> pkg itself is really great, it's just so much faster and simpler than
> portmaster or the old package system. Props to all the people who made
> that possible!
> 
> Cheers,
> Marc
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


I used to use IIRC pkgdb -F : "pkgdb -F is not supported with PKGNG yet. Use 
'pkg check' directly."
I also used to use -b IIRC with portmaster to save .so. files, and nowadays 
proactively check UPDATING to copy .so. files
to /usr/local/lib/compat manually so pkg updates don't go awry hardly ever.
...
using 11.0-CURRENT so I may get bitten by this one, but I've less trust in IW 
once BW completes so
tend to delay upgrading fwiw, also a lack of time.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ISO image: where is the CLANG compiler?

[Jeffrey Bouquet]

On Sat, 21 Jan 2017 16:47:56 -0600, Benjamin Kaduk  wrote:

> On Thu, Jan 19, 2017 at 07:38:30PM +, Glen Barber wrote:
> > 
> > Random thought:
> > 
> > Brought up out-of-band, can you try this from a memstick.img and your
> > already-built userland/kernel to do what you had originally tried to
> > install the system?
> > 
> >  # make -C /usr/src WITHOUT_SYSTEM_COMPILER=1 DESTDIR=/wherever installworld
> > 
> > I think this is why cc(1)/clang(1) is not being used from /usr/obj, and
> > you don't have a compiler to compile the compiler.
> 
> Sorry for jumping in late, and thanks for bringing this up -- I was surprised
> that we had gone so long without someone making the claim that a compiler
> should not be necessary for installworld/installkernel (as was my 
> understanding).
> If indeed a compiler is necessary for those (perhaps only under certain
> circumstances such as those experienced by Oliver) it would be good to 
> understand
> why.
> 
> -Ben
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


That may be a reason to develop the not-specific (sorry...) idea that 
installworld
should install to a small duplicate of  where it Does, and  complete, before 
the Actual
installworld so that if the latter cannot complete, a small rescue shell with 
rsync
embedded or an equivalent can copy the bare-minimum set of files over the 
mixture of new and old... which I have had to several times do more or less
piecemeal, and more often than not sufficed to bring the system back whole. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

command line environment and port to equal CURRENT clang?

[Jeffrey Bouquet]

... that may work in /usr/src/sbin for example?
make clang=[/usr/ports/lang/??]clang-foo clang+ depend;   make;   # so that a 
buildworld is not needed?
or that would have to be created as a feature..
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: command line environment and port to equal CURRENT clang?

[Jeffrey Bouquet]

On Mon, 23 Jan 2017 20:18:18 +0100, Dimitry Andric  wrote:

> On 23 Jan 2017, at 05:32, Jeffrey Bouquet  wrote:
> > 
> > ... that may work in /usr/src/sbin for example?
> > make clang=[/usr/ports/lang/??]clang-foo clang+ depend;   make;   # so that 
> > a buildworld is not needed?
> > or that would have to be created as a feature..
> 
> The following appears to work:
> 
> pkg install llvm39
> export CC=/usr/local/bin/clang39
> export CXX=/usr/local/bin/clang++39
> export CPP=/usr/local/bin/clang-cpp
> cd /usr/src/sbin
> make obj
> make depend
> make
> 
> Note that this may pick up the wrong versions of libraries, so do not
> be amazed if stuff blows up.
> 
> Also note that clang in base has a few patches which might not be in the
> port, so you could also run into unexpected bugs in the port.
> 
> -Dimitry


Thanks.
pkg fetch is on the fourth 'timeout' to fetch the file, though, I emailed
the p...@freebsd.org list... wget -c -nd in this case did not help either, 
unless
that is more tricks to learn.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: command line environment and port to equal CURRENT clang?

[Jeffrey Bouquet]

On Mon, 23 Jan 2017 20:18:18 +0100, Dimitry Andric  wrote:

> On 23 Jan 2017, at 05:32, Jeffrey Bouquet  wrote:
> > 
> > ... that may work in /usr/src/sbin for example?
> > make clang=[/usr/ports/lang/??]clang-foo clang+ depend;   make;   # so that 
> > a buildworld is not needed?
> > or that would have to be created as a feature..
> 
> The following appears to work:
> 
> pkg install llvm39
> export CC=/usr/local/bin/clang39
> export CXX=/usr/local/bin/clang++39
> export CPP=/usr/local/bin/clang-cpp
> cd /usr/src/sbin
> make obj
> make depend
> make
> 
> Note that this may pick up the wrong versions of libraries, so do not
> be amazed if stuff blows up.
> 
> Also note that clang in base has a few patches which might not be in the
> port, so you could also run into unexpected bugs in the port.
> 
> -Dimitry

Works! on 9 out of ten binaries at least. [1] Even so good from here that 
someone
may wish to put it in /usr/src/UPDATING but with an additional reference to how
to find the most likely llvm since that may change over time...

Tested in /usr/src/bin, sbin, usr.sbin, usr.bin...

[1] some build but do not install 'no such file or directory' so maybe did not 
build...

Made it into a .sh or .zsh that placed in another location and then run from the
location that is being reinstalled, /fsck_ffs/ for example... with the latter
as the $1 coded into the script, as the full path on the command line as a
parameter.  May need improvement... or more coding...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Seamonkey update

[Jeffrey Bouquet]

On Sun, 5 Feb 2017 20:05:51 -0500, roberth...@rcn.com wrote:

> 
> Jeffrey Bouquet writes:
> 
> >  pkg today updated seamonkey, now it segfaults, 
> >  every which way I try to run it.
> 
>   I am running SeaMonkey 2.46_5 (compiled today) under:
>   
>   FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03 UTC 2016 amd64
> 
>   .
>   So far, indistinguishable from _4.
> 
> 
> 
>   Respectfully,
> 
> 
>   Robert Huff


More progress but not so encouraging.

Rebuilt the machine on which seamonkey segfaulted, to v12-CURRENT 
..
seamonkey still segfaults
after _4 _5   [ a showstopper for the v11 OR v12 desktop on that disk ] 

/usr/bin/cc segfaults, prohibiting port building
after installworld  [ a showstopper for v12 on that disk ]

pkg -vv reports v11

FreeBSD.conf 
   containing FreeBSD:12:x86:32,
   containing /${ABI}/,
   containing FreeBSD:12:i386
each error out in some manner or another, making package not usable.
[a showstopper for pkg usage on that disk ]

Firefox prohibits 2 entry anywhere, so I cannot log into the forums as
jb_fvwm2 on the newer machine to inquire there, not use most any
search query containing the numeric digit(s) 2 and at least two others.
[ a showstopper for firefox usage on that disk ]

.
None of these 4 problems were present on Feb 4 vs by the morning of today Feb 
6...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

12-CURRENT won't configure to download packagesite.txz yet

[Jeffrey Bouquet]

All the files

/etc/FreeBSD.conf
/usr/local/etc/pkg/repos/FreeBSD.conf
/usr/local/etc/pkg.conf

I edit time after time for
{$ABI}  which gives FreeBSD:11:i386  but I am on 12-CURRENT i386
Anytime I try to attune to
freebsd:12:x86:32or
FreeBSD:12:i386   ...
it downloads the packagesite again, as it does in the ABI example, but a terse
error of wrong architecture, etc, and a fail to do anything to upgrade to  
Pkg-12.

Can the proper file be rename upstream to what its architecture in simpler 
terms:
like packagesite-i386-12.txz and a message printed upon de-TXZ the file so that
the proper nomenclature is given to put into each of those three files above
so that the generic packagesite.txz will not error out upon download?
Or, put the instructions in /usr/src/UPDATING ?? since it is part of base? 


Or some other way to de-showstopper this v11 April 2016 CURRENT to v12 Feb 2017 
CURRENT
upgrade which still has failed to enable seamonkey-2.46_5 to run non-segfault [ 
ie cannot run ]
vs seamonkey-2.46_4 which four days ago ran without EVER segfaulting??  And 
cannot build
from ports for obscure .h clang-header file related reasons? 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 12-CURRENT won't configure to download packagesite.txz yet

[Jeffrey Bouquet]

On 02/ 6/17 09:59 PM, Allan Jude wrote:

On February 7, 2017 2:35:16 AM GMT+01:00, Jeffrey Bouquet 
 wrote:

All the files

/etc/FreeBSD.conf
/usr/local/etc/pkg/repos/FreeBSD.conf
/usr/local/etc/pkg.conf

I edit time after time for
{$ABI}  which gives FreeBSD:11:i386  but I am on 12-CURRENT i386
Anytime I try to attune to
freebsd:12:x86:32or
FreeBSD:12:i386   ...
it downloads the packagesite again, as it does in the ABI example, but
a terse
error of wrong architecture, etc, and a fail to do anything to upgrade
to  Pkg-12.

Can the proper file be rename upstream to what its architecture in
simpler terms:
like packagesite-i386-12.txz and a message printed upon de-TXZ the file
so that
the proper nomenclature is given to put into each of those three files
above
so that the generic packagesite.txz will not error out upon download?
Or, put the instructions in /usr/src/UPDATING ?? since it is part of
base?


Or some other way to de-showstopper this v11 April 2016 CURRENT to v12
Feb 2017 CURRENT
upgrade which still has failed to enable seamonkey-2.46_5 to run
non-segfault [ ie cannot run ]
vs seamonkey-2.46_4 which four days ago ran without EVER segfaulting??
And cannot build

>from ports for obscure .h clang-header file related reasons?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"

Please provide the output of:
uname -a

machine on which firefox, thunderbird, seamonkey, cc, pkg work:
...
11.0-CURRENT  #2
R298350
Wed Apr 20 2016
I386
1100105
1100105
DEC22KRNL10 ( not GENERIC )
...
machine on which firefox has broken numeric input [ I cannot log into
the FreeBSD forum as my nickname has a "2" within it...
nor use browser search in firefox that searches for terms with
a "2" within the text field... jumps to another tab..., cc MAY be fixed, 
pkg still works only at v11,
seamonkey segfaults, thunderbird segfaults, otter-browser has bus 
error,  seamonkey won't build

due to maybe clang header files:
..
12.0-CURRENT #3
R313305
Mon Feb 6 2017
i386
1200020   ( guess from strings on the kernel) ... (forgot to run uname 
when booted into the system)

1200020   ( guess from strings on the kernel)   "
DEC22KRNL10 (not GENERIC)
and per pkg -vv, still v11...

uname -K
uname -U

Again, maybe a ${ABI} set of three files (FreeBSD.conf (2) , pkg.conf ) 
that I could use as a template
may fix the package issue and if that is fixed, could fix the 
seamonkey/thunderbird/firefox issues...
Precise documentation is lacking in the limited time I have to test 
solutions in forum and mailing

list posts.
.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r313305 libevent2 problem and workaround NEED FIXING...

[Jeffrey Bouquet]

A huge six-day fix of seamonkey breakage on 11-CURRENT of april 2016, upgraded
finally last night to pkg 12-CURRENT feb 2017 working and etc by base.txz 
overwrite etc...
...
I've many many hours to restore the desktop to full how-it-was-before, but as it
is working, now, a wholesale 3xxx reinstall of ports by pkg (which had to
occur OUT OF Xorg for stall issues... and lack of granularity in the
use of "pkg upgrade"  (ie thirty-by-thirty) or lack of code in
"pkg install" (terse deinstalls necc. where reinstalls were needed)
as of this date
.
Mostly fixed as I write from the fixed system, but the only reason I am using 
seamonkey
now, and also fixed firefox, just then, is the series of commands... which I 
expect to
maybe re-break when v12 upgrades _4 seamonkey to _5 which broke (segfaults) here
from ports the port... but in the meantime
..
cp -iv /[backup mount}/usr/local/lib/libevent-2.0.so.5.10 
/usr/local/lib/compat/libevent-2.0.so.5
cp -iv /usr/local/lib/compat/libevent-2.0.so.5 
/usr/ports/www/seamonkey/libevent-2.0.so.5-NECC-FOR-SEAMONKEY
..
backup restored a newly overnight broken seamonkey AND firefox, the former not 
as of a day or
so from ports being able to run.
.
This is quite the showstopper here... almost forced a reinstall of 2004-2017 ( 
this desktop)
to a 2016-STABLE v11 new disk which I may have to revert to if seamonkey 
breaks again or
the next iteration of libevent/seamonkey/firefox does not fix up with CLI such 
as this time.

Out of time for a PR or bug report offically, and hope to gain more
pressing urgency to this problem than might be attained, that way... out of 
time also.
...
Thanks for reading, and thanks for putting up with interim list messages in the 
last few
days which still had a bit of almost PBKAC combined with lack of documentation 
combined with
newbie-ness here which had yet to resolve... 
and thanks for the forum post(s) which helped resolve the seemingly-lost-cause 
issue of the
v11-CURRENT upgrade to  v12-CURRENT which appears to have worked today vs 
several
days ago, IF seamonkey continues to be fixable locally.

J. Bouquet 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r313487 recovered. Thanks and details.

[Jeffrey Bouquet]

r313487 feb 9  i386 1200020
...
Without the details for the thank-you, thanks for the recovery assistance.
...
I found ABI in /usr/local/etc/pkg.conf which fix the :11 :12 issue at least for 
now, upgrading 
11-CURRENT to 12-CURRENT to fix seamonkey, and 2.46_4 working again maybe until
2.46_5 serious breakage, libevent2 probably relevant.  Until then...
...
Small concern many tweaks 2004-2016 were reversed to new-install by base.txz 
which was
needed to restore system functionality.   I've backup files... nothing out of 
the
ordinary I see though.

The main issue now is one, two, OR  14 hour ( or similar ) lockups of Xorg.
Repeatable:  [ I've yet to savecore when the stuff happens ]
>
links -g cannot be clicked upon, xterm can
Leaving Xorg, the interface ue0 cannot be bought up [ means no use restarting X 
without reboot]
Reboot fixes it[  Xorg usage] [ ue0 axe0 usage ]

One in four times, it is a crash to reboot from Xorg.  [ approximate ] at least 
until the
next Xorg update happens by pkg in about three days or less. as it is in ports.

The only question unless valid hints at the above, is Xorg crashing ue0 or ue0 
crashing
Xorg, or some common denominator in CURRENT that affects both like SCHED_ULE or
missing compat10x or a delete-old-libs not done recently?  Just in case some
more expert than I  [ who should have maybe stayed on 11-STABLE or even 
11-RELEASE
so as not to write too many emails tying up persons' time... ] has more clues
than I as to the coding behind the .so internals and all.
..
Thanks for reading. 
PS nano yudit lookat gnuls xvt roxterm rsync gcp xclip feh xv gs text2pdf 
terminator urxvt  scrotall useful day-to-day here...

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

GDB question [ at least at first... ]

[Jeffrey Bouquet]

I've a custom kernel r313487 without, and
another with, debugging lines re-added.
[ i386 ] 

With daily vmcore in /var/crash from the 
former, can the latter be used with GDB
[ the larger kernel ] to evaluate the 
core file from the  non-debugging, thinner
kernel?

And if so, better to learn GDB here or
send it off as an attachment to an
expert ??

The crashes almost uniformly
[ 3/4 of them ] happen during
seamonkey or links -g,  and also
after the
recent seamonkey upgrade
VS before,  which almost 
wrecked the install... if it matters any.
OR, the fixes I did to the almost-wrecked
install made it unstable to run
a browser within. OR, some sysctl
is not tuned to the recent hardware...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Lock order reversal [ newbie ] report

[Jeffrey Bouquet]

#0 #16 follow:
jotted down :

1. ufs /usr/src/sys/kern/vfs_syscalls.c:3364
2. bufwait /usr/src/sys/ufs/ffs/ffs_vnops.c:280
3. ufs /usr/src/sys/kern/vfs_subr.c:2600

[ took roxterm out of the xinitrc, system stable seems more than yesterday...  
too
early to tell, which is/was a 2nd issue...  put in urxvt and st... based on TOP 
memory... ] 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal [ newbie ] report [2nd one]

[Jeffrey Bouquet]

This one at boot:
#0 to #10
bufwait
/usr/src/sys/kern/vfs_bio.c:3500
dirhash
/usr/src/sys/ufs/ufs/ufs_dirhash.c:201

r313487   12.0-CURRENT Feb 13 2017 
1200020  FWIW 
both the above and the below reports...




On Wed, 22 Feb 2017 15:37:21 -0800 (PST), "Jeffrey Bouquet" 
 wrote:

> #0 #16 follow:
> jotted down :
> 
> 1. ufs /usr/src/sys/kern/vfs_syscalls.c:3364
> 2. bufwait /usr/src/sys/ufs/ffs/ffs_vnops.c:280
> 3. ufs /usr/src/sys/kern/vfs_subr.c:2600
> 
> [ took roxterm out of the xinitrc, system stable seems more than yesterday... 
>  too
> early to tell, which is/was a 2nd issue...  put in urxvt and st... based on 
> TOP memory... ] 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Lock order reversal [ newbie ] report [2nd one> more of ]

[Jeffrey Bouquet]

On Wed, 22 Feb 2017 21:06:32 -0600, Benjamin Kaduk  wrote:

> Hi Jeffrey,
> 
> Thank you for your enthusiasm in reporting these.
> Unfortunately, it is very likely that these two are "well-known" and
> believed to be harmless, so you have not discovered something
> terribly exciting.
> 
> An old and no-longer particularly maintained listing of these and
> other LORs is at: http://sources.zabbadoz.net/freebsd/lor.html
> 
> -Ben
> 
> On Wed, Feb 22, 2017 at 06:20:08PM -0800, Jeffrey Bouquet wrote:
> > This one at boot:
> > #0 to #10
> > bufwait
> > /usr/src/sys/kern/vfs_bio.c:3500
> > dirhash
> > /usr/src/sys/ufs/ufs/ufs_dirhash.c:201
> > 
> > r313487   12.0-CURRENT Feb 13 2017 
> > 1200020  FWIW 
> > both the above and the below reports...
> > 
> > 
> > 
> > 
> > On Wed, 22 Feb 2017 15:37:21 -0800 (PST), "Jeffrey Bouquet" 
> >  wrote:
> > 
> > > #0 #16 follow:
> > > jotted down :
> > > 
> > > 1. ufs /usr/src/sys/kern/vfs_syscalls.c:3364
> > > 2. bufwait /usr/src/sys/ufs/ffs/ffs_vnops.c:280
> > > 3. ufs /usr/src/sys/kern/vfs_subr.c:2600
> > > 
> > > [ took roxterm out of the xinitrc, system stable seems more than 
> > > yesterday...  too
> > > early to tell, which is/was a 2nd issue...  put in urxvt and st... based 
> > > on TOP memory... ] 
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> > 
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Found a few more in a debug custom kernel that has  9h 54m uptime as of now,
using nextboot, so are maybe not important... just a toy maybe to examine if
anyone has free time and/or has less than 9h uptime issues to remove a few
lock order reversals, in, say, amd64 (i386 here)  if they are common to both but
would crash amd64 more reliably than the good uptime I have as of this
morning...  r318487  Feb 13 2017 12.0-CURRENT 1200020

Thought to email them only because different 'subsystem' messages occur
during the boot verbose process... like 2016, 2017, 2016, 2015... 

Maybe just newbie stuff. Thanks...  ignore the 'speaker' stuff in it... 

Jeff  kernel log messages:
+subsystem 100
+   vm_mem_init(0)... done.
+   vm_page_init(0)... done.
+subsystem 180
+   sysctl_register_all(0)... done.
+   mallocinit(0)... done.
+   malloc_init(&M_ACPICA)... done.
+   malloc_init(&M_KBDMUX)... done.
+   malloc_init(&M_LED)... done.
+   malloc_init(&M_MALODEV)... done.
+   malloc_init(&M_MD)... done.
+   malloc_init(&M_MDSECT)... done.
+   malloc_init(&M_MFIBUF)... done.
+   malloc_init(&M_MPR)... done.
+   malloc_init(&M_MPRSAS)... done.
+   malloc_init(&M_MPRUSER)... done.
+   malloc_init(&M_MPT2)... done.
+   malloc_init(&M_MPSSAS)... done.
+   malloc_init(&M_MPSUSER)... done.
+   malloc_init(&M_ACPITASK)... done.
+   malloc_init(&M_MPTUSER)... done.
+   malloc_init(&M_MRSAS)... done.
+   malloc_init(&M_ACPISEM)... done.
+   malloc_init(&M_CAMCCBQ)... done.
+   malloc_init(&M_ACPIDEV)... done.
+   malloc_init(&M_MVS)... done.
+   malloc_init(&M_MWLDEV)... done.
+   malloc_init(&M_NETMAP)... done.
+   malloc_init(&M_PPBUSDEV)... done.
+   malloc_init(&M_PSTIOP)... done.
+   malloc_init(&M_PSTRAID)... done.
+   malloc_init(&M_PUC)... done.
+   malloc_init(&M_CAMSIM)... done.
+   malloc_init(&M_ENTROPY)... done.
+   malloc_init(&M_CAMXPT)... done.
+   malloc_init(&M_CAMDEV)... done.
+   malloc_init(&M_CAMCCB)... done.
+   malloc_init(&M_CAMPATH)... done.
+   malloc_init(&M_SIIS)... done.
+   malloc_init(&M_CAMPERIPH)... done.
+   malloc_init(&M_SNP)... done.
+   malloc_init(&M_ACPICMBAT)... done.
+   malloc_init(&M_AC97)... done.
+   malloc_init(&M_FEEDER)... done.
+   malloc_init(&M_MIXER)... done.
+   malloc_init(&M_MIDI)... done.
+   malloc_init(&M_TWA)... done.
+   malloc_init(&M_TWE)... done.
+   malloc_init(&M_TWS)... done.
+   malloc_init(&M_ACPIPERF)... done.
+   malloc_init(&M_ACP

daily periodic supplies backtrace. Debuggable?

[Jeffrey Bouquet]

+Expensive timeout(9) function: 0xb55a7b40(0xbe877000) 0.030583914 s

+Expensive timeout(9) function: 0xb5609ad0(0xbe55b000) 0.479816638 s

+SMP: AP CPU #3 Launched!
+SMP: AP CPU #4 Launched!
+SMP: AP CPU #2 Launched!
+   init_TSC_tc(0)... Timecounter "TSC-low" frequency 1600033566 Hz quality 1000

+ 1st 0xddc1a538 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3500
+ 2nd 0xbf76f200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281
+GEOM_SCHED: Loading: mp = 0xc01f0084, g_sched_class = 0xc01f0084.
+acquiring duplicate lock of same type: "os.lock_mtx"
+ 1st os.lock_mtx @ nvidia_os.c:824
+ 2nd os.lock_mtx @ nvidia_os.c:824

+stack backtrace:

+#0 0xb5c22421 at witness_debugger+0x81
+#1 0xb5c22342 at witness_checkorder+0xd12
+#2 0xb5ba4e85 at __mtx_lock_flags+0x95
+#3 0xb752b1dc at os_acquire_spinlock+0x2c
+#4 0xb7262374 at _nv011973rm+0x190

+nvidia-modeset: Allocated GPU:0 (GPU-7838b48e-55e4-f04d-8659-f0d638eef7aa) @ 
PCI::01:00.0
+nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device VGA-0

+ 1st 0xc2b584a4 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3364
+ 2nd 0xddd15de8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:280
+ 3rd 0xc2d3b6dc ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2600
+#9 0xb5eafc55 at softdep_sync_buf+0xb55
+#11 0xb5ebe4b4 at ffs_fdatasync+0x24
+#12 0xb6192057 at VOP_FDATASYNC_APV+0xd7
+#13 0xb5c9868d at kern_fsync+0x21d
+#14 0xb5c98762 at sys_fdatasync+0x22
+#15 0xb6155fa5 at syscall+0x3b5
+#16 0xb6140ede at Xint0x80_syscall+0x2e

Sometimes is up 24hours.  Often, though, with certain browsers/web pages/ 
multiple
tabs, complete freeze, in X, or with the 3am periodic scripts, or with an rsync 
in
an xterm --bwlimit=700 using resources. 

No time to learn GDB vs someday upgrade to amd64... or 12.0-RELEASE or both. 
I've
small non-RSI exercises which make the reboots not unwelcome... but lose time 
otherwise. 

12.0-CURRENT
r313487
Feb 13 2017 
i386
1200020


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

how to SVN regenerate [ man awk ]

[Jeffrey Bouquet]

For $giggles$ I svn up /usr/src/usr.bin/awk  or wherever, then
man awk displays not the newer import per a recent SVN but
the older 2015 [ it says ] one.  Stale file, or not all parts of
the man page updated to include latest revision dat, or some
other command to [g]unzip or whatever, besides 320.whatis
in periodic--weekly, update the compressed latest installed
files from /usr/obj to what one expects when one has just
recompiled the  man page?

This crops up quite a lot on this machine, so I am unschooled in
some principle of updating this operating system.  

If it matters, I receive a 

WARNING manpath environment variable set

when starting an additional
xterm & ... 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: how to SVN regenerate [ man awk ]

[Jeffrey Bouquet]

On Thu, 9 Mar 2017 08:43:29 -0800, David Wolfskill  wrote:

> On Thu, Mar 09, 2017 at 07:00:13AM -0800, Jeffrey Bouquet wrote:
> > For $giggles$ I svn up /usr/src/usr.bin/awk  or wherever, then
> > man awk displays not the newer import per a recent SVN but
> > the older 2015 [ it says ] one.  Stale file, or not all parts of
> > the man page updated to include latest revision dat, or some
> > other command to [g]unzip or whatever, besides 320.whatis
> > in periodic--weekly, update the compressed latest installed
> > files from /usr/obj to what one expects when one has just
> > recompiled the  man page?
> 
> If you intend to use "svn up", you should probably review, and
> follow the instructions in, /usr/src/UPDATING.

but just for one binary?  and one man page update? 
As in, it is only two files, how to update singly if does not require a 
buildworld...

> 
> > This crops up quite a lot on this machine, so I am unschooled in
manpath
(Warning: MANPATH environment variable set)

/usr/share/man:/usr/local/man:/usr/share/openssl/man:/usr/local/lib/node_modules/npm/man:/usr/local/lib/perl5/site_perl/man:/usr/local/lib/perl5/5.24/perl/man:/usr/local/share/xpdf/man



> > some principle of updating this operating system.  
> > 
> > If it matters, I receive a 
> > 
> > WARNING manpath environment variable set
> > 
> > when starting an additional
> > xterm & ... 
> 
> You may have code in your login shell's initialization file that sets
> MANPATH
> 

MANPATH="`manpath`"

> Peace,
> david
> -- 
> David H. Wolfskillda...@catwhisker.org
> How could one possibly "respect" a misogynist, racist, bullying con-man??!?
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

info.0 dump good

[Jeffrey Bouquet]

Seems to happen when Xorg has a large webpage or a page idle for a time

Dump header from device: /dev/gpt/WDswap
  Architecture: i386
  Architecture Version: 2
  Dump Length: 285376512
  Blocksize: 512
  Dumptime: Mon Mar 13 12:12:37 2017
  Hostname: [redacted]com
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 12.0-CURRENT #5 r313487: Thu Feb  9 17:32:03 PST 2017
com:/usr/obj/usr/src/sys/[custom kernel]
  Panic String: page fault
  Dump Parity: 1127850006
  Bounds: 0
  Dump Status: good

Viable to send the bounds, info.0 and vmcore.0 to somewhere where someone not
a comlete novice can find a bug somewhere?Unsure what email attachment 
allows
a 273MB file, an ftp server upstream ??  No time  to use kdbg for a few months 
anyway...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: info.0 dump good

[Jeffrey Bouquet]

On Mon, 13 Mar 2017 14:04:23 -0700, John Baldwin  wrote:

> On Monday, March 13, 2017 12:28:44 PM Jeffrey Bouquet wrote:
> > Seems to happen when Xorg has a large webpage or a page idle for a time
> > 
> > Dump header from device: /dev/gpt/WDswap
> >   Architecture: i386
> >   Architecture Version: 2
> >   Dump Length: 285376512
> >   Blocksize: 512
> >   Dumptime: Mon Mar 13 12:12:37 2017
> >   Hostname: [redacted]com
> >   Magic: FreeBSD Kernel Dump
> >   Version String: FreeBSD 12.0-CURRENT #5 r313487: Thu Feb  9 17:32:03 PST 
> > 2017
> > com:/usr/obj/usr/src/sys/[custom kernel]
> >   Panic String: page fault
> >   Dump Parity: 1127850006
> >   Bounds: 0
> >   Dump Status: good
> > 
> > Viable to send the bounds, info.0 and vmcore.0 to somewhere where someone 
> > not
> > a comlete novice can find a bug somewhere?Unsure what email attachment 
> > allows
> > a 273MB file, an ftp server upstream ??  No time  to use kdbg for a few 
> > months anyway...
> 
> Do you have a core.txt.0 file?  If so it should contain a stack trace from
> kgdb which is the first thing that would be useful to obtain.
> 
> -- 
> John Baldwin


Sent the core.text.8 question, 
as not a kgbd expert, pending, earlier today, not to the list:


Now to the list, one of several daily backtraces, 
and/or lock order reversals, in dmesg, starting X, 
mounting or unmounting 2nd disks... this
from /var/log/messages...


kernel: lock order reversal:  
kernel: 1st 0xc21ebd84 ufs (ufs) @
kernel: 2nd 0xc2ca126c syncer (syncer) @
kernel: stack backtrace:   
kernel: #0 0xb5c22421 at witness_debugger+0x81 
kernel: #1 0xb5c22342 at witness_checkorder+0xd12 
kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64 
kernel: #3 0xb5c784ad at vop_stdlock+0x4d 
kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 
kernel: #5 0xb5c9c137 at _vn_lock+0xb7 
kernel: #6 0xb5c8b00a at vputx+0x16a 
kernel: #7 0xb5c8286c at dounmount+0x5 
kernel: dc
kernel: #8 0xb5c82185 at sys_unmount+0x315 
kernel: #9 0xb6155fa5 at syscall+0x3b5 
kernel: #10 0xb6140ede at Xint0x80_syscall+0x2e 
kernel: lock order reversal:  
kernel: 1st 0xc21ebd84 ufs (ufs) @
kernel: 2nd 0xc0175150 devfs (devfs) @
kernel: stack backtrace:   
kernel: #0 0xb5c22421 at witness_debugger+0x81 
kernel: #1 0xb5c22342 at witnes 
kernel: s_checkorder+0xd12
kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64 
kernel: #3 0x   
kernel: b5c784ad at vop_stdlock+0x4d  
kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 
kernel: #5 0xb5c9c137 at _vn_lock+0x 
kernel: b7
kernel: #6 0xb5eb9617 at ffs_flushfiles+0x157 
kernel: #7 0xb5e9d9aa at soft 
kernel: dep_flushfiles+0x17a
kernel: #8 0xb5ebc04c at ffs_unmount+0x7c 
kernel: #9 0xb5   
kernel: c8299b at dounmount+0x70b  
kernel: #10 0   
kernel: xb5c82185 at sys_unmount+0x315  
kernel: #11 0xb6155fa5 at syscall+0x3b5 
kernel: 
kernel: #12 0xb6140ede at Xint0x80_syscall+0x2e 
 
from the following two files:

1st 0xc21ebd84 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277
2nd 0xc2ca126c syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2762


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

backtrace within dmesg

[Jeffrey Bouquet]

from /var/log/messages  OR the periodic run OR both
Still daily lockups in Xorg when browsers open, sometimes when not. 


+   __stack_chk_init(0)... random: unblocking device.
+done.
+#3 0xb752ad7e at os_acquire_mutex+0x3e
+#4 0xb7434583 at _nv019165rm+0xb
+Expensive timeout(9) function: 0xb55a7b40(0xbe67c000) 0.031685381 s
+Expensive timeout(9) function: 0xb5609ad0(0xbe55b000) 0.779665921 s
+SMP: AP CPU #4 Launched!
+SMP: AP CPU #2 Launched!
+SMP: AP CPU #5 Launched!
+   init_TSC_tc(0)... Timecounter "TSC-low" frequency 1600025054 Hz quality 1000


+WARNING: / was not properly dismounted

+ 1st 0xddc38f04 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3500
+ 2nd 0xbf533200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281
+GEOM_SCHED: Loading: mp = 0xbffb1084, g_sched_class = 0xbffb1084.
+#3 0xb752b1dc at os_acquire_spinlock+0x2c
+#4 0xb7262374 at _nv011973rm+0x190
+ 1st 0xc1191a30 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3364
+ 2nd 0xddc506e8 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:280
+ 3rd 0xc2abfc68 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2600
+#9 0xb5eafc55 at softdep_sync_buf+0xb55
+#11 0xb5ebe4b4 at ffs_fdatasync+0x24
+#12 0xb6192057 at VOP_FDATASYNC_APV+0xd7
+#13 0xb5c9868d at kern_fsync+0x21d
+#14 0xb5c98762 at sys_fdatasync+0x22
+#15 0xb6155fa5 at syscall+0x3b5
+#16 0xb6140ede at Xint0x80_syscall+0x2e
+Expensive timeout(9) function: 0xb5bd5c90(0xc01f3000) 2.169794100 s

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fwd: Re: info.0 dump good

[Jeffrey Bouquet]

- Start Forwarded Message -
Sent: Fri, 17 Mar 2017 12:47:30 -0700
From: John Baldwin 
To: jbt...@iherebuywisely.com
Subject: Re: info.0 dump good

On Thursday, March 16, 2017 05:32:13 AM Jeffrey Bouquet wrote:
> 
> On Wed, 15 Mar 2017 16:10:43 -0700, John Baldwin  wrote:
> 
> > On Monday, March 13, 2017 06:49:05 PM Jeffrey Bouquet wrote:
> > > 
> > > On Mon, 13 Mar 2017 14:04:23 -0700, John Baldwin  wrote:
> > > 
> > > > On Monday, March 13, 2017 12:28:44 PM Jeffrey Bouquet wrote:
> > > > > Seems to happen when Xorg has a large webpage or a page idle for a 
> > > > > time
> > > > > 
> > > > > Dump header from device: /dev/gpt/WDswap
> > > > >   Architecture: i386
> > > > >   Architecture Version: 2
> > > > >   Dump Length: 285376512
> > > > >   Blocksize: 512
> > > > >   Dumptime: Mon Mar 13 12:12:37 2017
> > > > >   Hostname: [redacted]com
> > > > >   Magic: FreeBSD Kernel Dump
> > > > >   Version String: FreeBSD 12.0-CURRENT #5 r313487: Thu Feb  9 
> > > > > 17:32:03 PST 2017
> > > > > com:/usr/obj/usr/src/sys/[custom kernel]
> > > > >   Panic String: page fault
> > > > >   Dump Parity: 1127850006
> > > > >   Bounds: 0
> > > > >   Dump Status: good
> > > > > 
> > > > > Viable to send the bounds, info.0 and vmcore.0 to somewhere where 
> > > > > someone not
> > > > > a comlete novice can find a bug somewhere?Unsure what email 
> > > > > attachment allows
> > > > > a 273MB file, an ftp server upstream ??  No time  to use kdbg for a 
> > > > > few months anyway...
> > > > 
> > > > Do you have a core.txt.0 file?  If so it should contain a stack trace 
> > > > from
> > > > kgdb which is the first thing that would be useful to obtain.
> > > > 
> > > 
> > > Dump header from device: /dev/gpt/WDswap
> > >   Architecture: i386
> > >   Architecture Version: 2
> > >   Dump Length: 229535744
> > >   Blocksize: 512
> > >   Dumptime: Wed Mar  1 18:10:06 2017
> > >   Hostname: .com
> > >   Magic: FreeBSD Kernel Dump
> > >   Version String: FreeBSD 12.0-CURRENT #0 r313487: Mon Feb 13 16:58:53 
> > > PST 2017
> > > root@ .com:/usr/obj/usr/src/sys/[custom]
> > >   Panic String: vm_fault: fault on nofault entry, addr: deadc000
> > >   Dump Parity: 3513472583
> > >   Bounds: 8
> > >   Dump Status: good
> > > 
> > > Only one of the  core's has a .txt. file... this is .8 but lacks the 4th 
> > > " bounds " file...
> > > I just renamed them to capitallized [ the .8 that is ] for safekeeping.
> > 
> > So the .txt files generally have much more useful information (such as the 
> > stack
> > trace from kgdb).  If you have a .txt file and it contains a stack trace, 
> > can
> > you follow up on the list with the stack trace?
> > 
> 
> 
> Don't know about the .text. file, 

Some versions of FreeBSD will generate a /var/crash/core.txt.N file alongside
the /var/crash/vmcore.N and /var/crash/info.N files.  If you have one, it will
contain things like the backtrace from kgdb which are more useful than the
info.N file.
 
> Command: kgdb /boot/test/kernel VMCORE.8
> 
> some version of the output [below] from the above  [core.text.8  also ? ]  
> 
> 
> 
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> Waiting (max 60 seconds) for system process `vnlru' to stop... done
> Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
> Waiting (max 60 seconds) for system process `syncer' to stop... 
> Syncing disks, vnodes remaining... 5 1 0 0 done
> All buffers synced.
> lock order reversal:
>  1st 0xbf8ce26c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277
>  2nd 0xbfb90150 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2762
> stack backtrace:
> #0 0xb5c22421 at witness_debugger+0x81
> #1 0xb5c22342 at witness_checkorder+0xd12
> #2 0xb5b9b5d4 at __lock

Duplicate? dmesg backtrace, ignore if useless please.

[Jeffrey Bouquet]

A.M. security periodic output:  
hostname, pkg audit etc,  redacted...

backtrace-17-dmesg-maybe-i386-r313487-12C-1200020.txt

the above filename explains the build, platform... sort of...

 kernel log messages:
+Expensive timeout(9) function: 0xb55a7b40(0xbe67c000) 0.034612848 s
+Expensive timeout(9) function: 0xb5609ad0(0xbe55b000) 0.792115478 s
+SMP: AP CPU #7 Launched!
+SMP: AP CPU #5 Launched!
+SMP: AP CPU #3 Launched!
+   init_TSC_tc(0)... Timecounter "TSC-low" frequency 1600024599 Hz quality 1000
+ 1st 0xddc34aac bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3500
+ 2nd 0xbe4eac00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281
+GEOM_SCHED: Loading: mp = 0xc0005084, g_sched_class = 0xc0005084.
+lock order reversal:
+ 1st 0xc2993914 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2600
+ 2nd 0xddd208c4 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:280
+ 3rd 0xc2c9b5c0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2600
+stack backtrace:
+#0 0xb5c22421 at witness_debugger+0x81
+#1 0xb5c22342 at witness_checkorder+0xd12
+#2 0xb5b9b5d4 at __lockmgr_args+0xa64
+#3 0xb5ebe317 at ffs_lock+0x87
+#4 0xb618e7f7 at VOP_LOCK1_APV+0xd7
+#5 0xb5c9c137 at _vn_lock+0xb7
+#6 0xb5c8a894 at vget+0x64
+#7 0xb5c7c421 at vfs_hash_get+0xd1
+#8 0xb5eb9704 at ffs_vgetf+0x44
+#9 0xb5eaf5d4 at softdep_sync_buf+0x4d4
+#10 0xb5ebf02f at ffs_syncvnode+0x2df
+#11 0xb5eae7ea at softdep_fsync+0x46a
+#12 0xb5ebe1f1 at ffs_fsync+0x71
+#13 0xb618d671 at VOP_FSYNC_APV+0xd1
+#14 0xb5c9863e at kern_fsync+0x1ce
+#15 0xb5c98732 at sys_fsync+0x22
+#16 0xb6155fa5 at syscall+0x3b5
+#17 0xb6140ede at Xint0x80_syscall+0x2e


comments welcome.  Cannot kgbd if ever still... 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: how to SVN regenerate [ man awk ]

[Jeffrey Bouquet]

On Wed, 22 Mar 2017 12:55:58 +, Jamie Landeg-Jones  
wrote:

> "Jeffrey Bouquet"  wrote:
> 
> > > If you intend to use "svn up", you should probably review, and
> > > follow the instructions in, /usr/src/UPDATING.
> >
> > but just for one binary?  and one man page update? 
> > As in, it is only two files, how to update singly if does not require a 
> > buildworld...
> 
> I've no idea what is causing your current problem, but it's perfectly fine to 
> do:
> 
> cd /usr/src/usr.bin/awk (for example)
> make
> make install
> make clean
> make cleandepends
> 
> I do this kind of thing all the time. Obvious caveats apply:
> 
> 1) You are no longer tracking a "standard" installation.
> 2) You may create a problem with mismatched versions of things.
> 3) Relating to 2), some things may not compile or work as intended due
>to changes elsewhere that would need to also be applied to the system.
> 
> But other than that, things should work (to use your example, awk should work 
> fine)
> 
> Are you doing the 'make install' rather than installing manually?
> 
> cheers, Jamie


Hmm... I crafted a reply, then noticed the email was to me.
I've been using
cd /usr/src/usr.sbin/[someplace]
svn up .   [indent so not as to appear in history]
make cleandepend
make depend
make obj
and if that fails
mmv /etc/make.conf / [ not precisely that but same thing ]
zsh /tmp/llvm39.sh

#/bin/sh
export CC=/usr/local/bin/clang39  
export CXX=/usr/local/bin/clang++39  
export CPP=/usr/local/bin/clang-cpp 
cd  $1  # /usr/src/usr.sbin/pw
make cleandepend
make obj
make depend
make install

...
to make the build with a new clang that may work better.
..
I've more or less given up until a new buildworld/installworld
risky at here, installworld sometimes fails though, and only hope
that the many migrating to BSD I see on linux.reddit.com and
elsewhere don't pick up on ZFS so much as improvements and
robust current fails-installworld-less-often,  reinvoke/reinvigorate
portmanager [of old], pkgdb -F  [long since forgotten],
portmaster, portupgrade, etc to be again 2004 style seamlessly
integrated into/with packages and the other wish-list stuff
I once wrote about [parallel pkg-fetch for production machines
depending upon a flat-file /var/db/pkg 'local.sqlite3' that can
be awked sed'ed into temporary forgiveness upon a hosed 
pkg upgrade, then switched back to the newer pkg commands
in a duplicate-pkg-methodology on same-production machine
framework that would stand far above anything debian arch
ubuntu centos etc could do,  
...
but mystified still by terse not upto newbie speed in 
/usr/src/UPDATING to cover all the edge cases, mfsbsd
methodologies  etc, that people detail in the forums, and
on blog posts, that never actually make it into local
new-install documentation, that could be done if persons
wrote as verbosely and profusely as I seem to do, but only
in an ask ask ask and never produce produce manner, for
which I apologize, for I have other demands upon my time
that conflict and as you can see broadly limit my
input to email and the once-yearly bugzilla of note or
that passes into irrelevance upon the next iteration of
an installworld.

OTOH I closely follow HAMMER HAMMER2 improvements as
a on-up on UFS2, and openbsd forum details for howtos
that do not appear sometimes in the  FreeBSD forum.
..
So thanks for the reply to my email.
...
Things are peachy more or less here with FreeBSD, for instance
uptime, 16:04 despite daily core files and bland ignorance of
kgbd upon the debugging custom kernel backtraces that appear
during dmesg, starting Xorg, umounting backup filesystems,
and the daily browser freeze if I've too many open, or too
large pages in links -g.

But enough of wall of text.

Thanks again.

Jeff 
PS sorry for the rough draft. I am out of time. 
..
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r315684 panic: sleepq_add: td 0xfffff80003c01a40 to sleep on wchan 0xfffff80006f0873c with sleeping prohibited

[Jeffrey Bouquet]

On Fri, 24 Mar 2017 17:40:15 + (UTC), Darren  wrote:

> I am getting this panic every hour to every couple of hours.
> 
> FreeBSD asrock 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r315684: Thu Mar 23 
> 14:56:45 EDT 2017 darren@asrock:/usr/obj/usr/src/sys/GENERIC  amd64
> I manually typed out the following, apologize for any typos. 
> 
> 
> panic: sleepq_add: td 0xf80003c01a40 to sleep on wchan 0xf80006f0873c 
> with sleeping prohibited
> cpuid = 0
> time = 1490372797
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0072e33690
> vpanic() at vpanic+0x19c/frame 0xfe0072e33710
> kassert_panic() at kassert_panic+0x126/frame 0xfe0072e33780
> sleepq_add() at sleepq_add+0x34f/frame 0xfe0072337d0
> _sleep() at _sleep+0x28d/frame 0xfe0072e33870
> soclose() at soclose+0xda/frame 0xfe0072e338b0
> _fdrop() at _fdrop+0x1a/frame 0xfe0072e338d0
> sendfile_iodone() at sendfile_iodone+0x19d/frame 0xfe0072e33910
> vnode_pager_generic_getpages_done_async() at 
> vnode_pager_generic_getpages_done_async+037/frame 0xfe0072e33930
> bufdone() at bufdone+0x64/frame 0xfe0072e33960
> g_io_deliver() at g_io_deliver+0x276/frame 0xfe0072e339b0
> g_io_deliver() at g_io_deliver+0x276/frame 0xfe0072e33a00
> g_disk_done() at g_disk_done+0x104/frame 0xfe0072e33a40
> xpt_done_process() at xpt_done_process+0x35f/frame 0xfe0072e33a80
> xpt_done_direct() at ahci_ch_intr_direct+0xd5/frame 0xfe0072e33af0
> ahci_itr() at ahci_intr+0x102/frame 0xfe0072e33b20
> intr_event_execute_handlers() at intr_event_execute_handlers+0x99/frame 
> 0xfe0072e33b60
> ithread_loop() at ithread_loop+0xb6/frame 0xfe0072e33bb0
> fork_exit() at fork_exit+0x84/frame 0xfe0072e33bf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe0072e33bf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> [ thread pid 12 tid 100038 ]
> Stopped at  kdb_enter+0x3b: movq    $0,kdb_why
> db>
> 
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Will there ever be an auto-save to .txt upon break to debugger or lock
reversal or similar in code? or is beyond the capability of the OS once the
occurance has taken place, I wonder. 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

lock order reversal another, repeatable...

[Jeffrey Bouquet]

Mar 24 14:25:16  kernel: lock order reversal:
Mar 24 14:25:16  kernel: 1st 0xc09cf6dc ufs (ufs) @ 
/usr/src/sys/kern/vfs_mount.c:1277
Mar 24 14:25:16  kernel: 2nd 0xc0100a30 devfs (devfs) @ 
/usr/src/sys/ufs/ffs/ffs_softdep.c:1908
Mar 24 14:25:16  kernel: stack backtrace:
Mar 24 14:25:16  kernel: #0 0xb5c22421 at witness_debugger+0x81
Mar 24 14:25:16  kernel: #1 0xb5c22342 at witness_checkorder+0xd12
Mar 24 14:25:16  kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64
Mar 24 14:25:16  kernel: #3 0xb5c784ad at vop_stdlock+0x4d
Mar 24 14:25:16  kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7
Mar 24 14:25:16  kernel: #5 0xb5c9c137 at _vn_lock+0xb7
Mar 24 14:25:16  kernel: #6 0xb5e9d648 at softdep_flushworklist+0x68
Mar 24 14:25:16  kernel: #7 0xb5ebc892 at ffs_sync+0x2b2
Mar 24 14:25:16  kernel: #8 0xb5c82955 at dounmount+0x6c5
Mar 24 14:25:16  kernel: #9 0xb5c82185 at sys_unmount+0x315
Mar 24 14:25:16  kernel: #10 0xb6155fa5 at syscall+0x3b5
Mar 24 14:25:16  kernel: #11 0xb6140ede at Xint0x80_syscall+0x2e

umounting a sata filesystem, the above.  Useful?

aside: twice recently dropped to debugger upon shutdown.
kb>   [ or whatever ]
any useful commands here?
I thought 'st' but have not read about a procedure...

That occured upon umount of a 2nd sata disk's filesystem(s).

On a second note,

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

bt full - included... kgdb 'script' output vmcore.8

[Jeffrey Bouquet]

I asked the var to bt full
it laid the symbols down
I asked it current, list, the cymbals.
not newly newbie, clown

And xclip pasted, below, the rhyme
the symbollish list stuff
And I send it off to list-wise men
to make Xorg not so gruff.

...
...


Script started on Sat Mar 25 13:11:34 2017
Command: kgdb7121 /boot/test/kernel /var/crash/VMCORE.8
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/test/kernel...Reading symbols from 
/usr/lib/debug//boot/test/kernel.debug...done.
done.

Unread portion of the kernel message buffer:
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop... 
Syncing disks, vnodes remaining... 5 1 0 0 done
All buffers synced.
lock order reversal:
 1st 0xbf8ce26c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277
 2nd 0xbfb90150 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2762
stack backtrace:
#0 0xb5c22421 at witness_debugger+0x81
#1 0xb5c22342 at witness_checkorder+0xd12
#2 0xb5b9b5d4 at __lockmgr_args+0xa64
#3 0xb5c784ad at vop_stdlock+0x4d
#4 0xb618e7f7 at VOP_LOCK1_APV+0xd7
#5 0xb5c9c137 at _vn_lock+0xb7
#6 0xb5c8b00a at vputx+0x16a
#7 0xb5c8286c at dounmount+0x5dc
#8 0xb5c8c8e8 at vfs_unmountall+0x68
#9 0xb5c68333 at bufshutdown+0x3f3
#10 0xb5bbfca7 at kern_reboot+0x1b7
#11 0xb5bbfa88 at sys_reboot+0x3e8
#12 0xb6155fa5 at syscall+0x3b5
#13 0xb6140ede at Xint0x80_syscall+0x2e
lock order reversal:
 1st 0xbf8ce26c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277
 2nd 0xbfa28034 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1404
stack backtrace:
#0 0xb5c22421 at witness_debugger+0x81
#1 0xb5c22342 at witness_checkorder+0xd12
#2 0xb5b9b5d4 at __lockmgr_args+0xa64
#3 0xb5c784ad at vop_stdlock+0x4d
#4 0xb618e7f7 at VOP_LOCK1_APV+0xd7
#5 0xb5c9c137 at _vn_lock+0xb7
#6 0xb5eb9617 at ffs_flushfiles+0x157
#7 0xb5e9d9aa at softdep_flushfiles+0x17a
#8 0xb5ebc04c at ffs_unmount+0x7c
#9 0xb5c8299b at dounmount+0x70b
#10 0xb5c8c8e8 at vfs_unmountall+0x68
#11 0xb5c68333 at bufshutdown+0x3f3
#12 0xb5bbfca7 at kern_reboot+0x1b7
#13 0xb5bbfa88 at sys_reboot+0x3e8
#14 0xb6155fa5 at syscall+0x3b5
#15 0xb6140ede at Xint0x80_syscall+0x2e
lock order reversal:
 1st 0xbf69ab4c ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277
 2nd 0xb6b6f8b0 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:3104
stack backtrace:
#0 0xb5c22421 at witness_debugger+0x81
#1 0xb5c22342 at witness_checkorder+0xd12
#2 0xb5bc976a at _sx_slock+0x5a
#3 0xb5b743f1 at mountcheckdirs+0x41
#4 0xb5c828ea at dounmount+0x65a
#5 0xb5c8c93b at vfs_unmountall+0xbb
#6 0xb5c68333 at bufshutdown+0x3f3
#7 0xb5bbfca7 at kern_reboot+0x1b7
#8 0xb5bbfa88 at sys_reboot+0x3e8
#9 0xb6155fa5 at syscall+0x3b5
#10 0xb6140ede at Xint0x80_syscall+0x2e
Uptime: 3h49m18s
GEOM_SCHED: Modevent 2.
uhub11: detached
uhub9: detached
uhub10: detached
ums0: detached
<5>ue0: link state changed to DOWN
<5>Accounting disabled
panic: vm_fault: fault on nofault entry, addr: deadc000
cpuid = 2
KDB: stack backtrace:
db_trace_self_wrapper(b632dee0,b65ec9b0,0,b63057cc,20c,...) at 
db_trace_self_wrapper+0x2a/frame 0xeaa10428
kdb_backtrace(b653d063,2,b6378ae5,eaa104e4,fb,...) at kdb_backtrace+0x2d/frame 
0xeaa10490
vpanic(b6378ae5,eaa104e4,eaa104e4,eaa105c0,b5edffb1,...) at vpanic+0x115/frame 
0xeaa104c4
panic(b6378ae5,deadc000,1,eaa1052c,eaa1051c,...) at panic+0x1b/frame 0xeaa104d8
vm_fault_hold(b8172000,deadc000,1,0,0,...) at vm_fault_hold+0x2051/frame 
0xeaa105c0
vm_fault(b8172000,deadc000,1,0,c2d0bfa8,...) at vm_fault+0x88/frame 0xeaa105e8
trap_pfault(deadc348,b6ae70ec,b6600504,bdda8d00,b6ae70f0,...) at 
trap_pfault+0x116/frame 0xeaa10630
trap(eaa10778) at trap+0x2d6/frame 0xeaa1076c
calltrap() at calltrap+0x6/frame 0xeaa1076c
--- trap 0xc, eip = 0xb5bbaf19, esp = 0xeaa107b8, ebp = 0xeaa10828 ---
__rw_wlock_hard(c2d42ab4,deadc0de,be269000,b63585e2,139,...) at 
__rw_wlock_hard+0xe9/frame 0xeaa10828
_rw_wlock_cookie(c2d42ab4,b63585e2,139,136,0,...) at 
_rw_wlock_cookie+0xd8/frame 0xeaa10858
ip_output(c3acf400,0,0,0,0,...) at ip_output+0x4aa/frame 0xeaa10934
check_dyn_rules(1,1,b632a786,eaa109c8,b5bce8a2,...) at 
check_dyn_rules+0x6a8/frame 0x

Re: Howto complete(!) install a world?

[Jeffrey Bouquet]

On Mon, 27 Mar 2017 10:10:29 +0200, "O. Hartmann"  
wrote:

> After a crash in which repeatedly portions of the base tree of FreeBSD has
> nullified on a SSD system "disk" (UFS), I had to save and repair on Friday,
> 24th March anno 2017 the broken infrastructure by copying (via pax -rw -p e)
> the binaries from the recent USB (memstick) image of 23rd provided by
> freebsd.org download site.
> 
> After rebuilding and installing a complete "world" (make buildworld on a
> delete /usr/obj, so to ensure it is empty), I still face a nasty ssh problem
> (/usr/bin/ssh: Undefined symbol "msetlocale").
> 
> I checked the age of the libraries, especially the libraries, which has
> supposedly been installed and although I did in the past update/buildworld on 
> a
> daily base, /lib is populated with libraries dated on February, 3rd,
> and /libexec still has the ld-elf.so libs from 23rd/24th. 
> 
> Using "kldload filemon" in conjuction with /etc/src-env.conf containing
> WITH_META_MODE= YES I'd expect such a thing, but I got confused with
> "/lib". Since Feb 3rd, LLVM 4.0 has been introduced and all libs should
> definitely have been recompiled, haven't they?
> 
> After rebuilding a "clean" world, I'd like to know how I can force a complete
> and radical installation of ALL what's in /usr/src and /usr/obj - meaning: how
> to force the installation process to install even those libs/files/bins which
> the installer suppose to be not necessary to be installed?
> 
> After two times rebuilding now world and installing it I can not get rid of
> this nasty ssh problem which prevents me from login onto remote systems and I
> suspect a faulty library to be the culprit. libprivatessh.so is installed on
> every rund of installworld accordingly to its date/ctime, I also delete the 
> *.a
> and *_p.a archives and had them reinstalled, but without success.
> 
> Help!
> 
> Kind regards and thanks in advance,
> 
> Oliver
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


This highlights what I think is one of my foremost concerns as to 'why not is
part of FreeBSD yet'  namely the proof that an installworld can complete
[think 'foolproof staging' ] before the installworld is actually 'ENTER' 
keyed...

b...   fallback /var/db/pkg flat file pkg equivalent re-done and CARP-like 
failover
c...   2005 era install bsd ncurses menus allowing setting partitions and type
d...   pkg updates to allow 'beastie boot menu 'choose options' style fixing of
 each line in each FreeBSD.conf and pkg.conf so that they are what
 pkg expects to be there, vs what are there... if you grasp that.
e...   lint >> GENERIC heavily commented to allow...
f...e1...  an ncurses-build-line-by-line-completion of a kernel file so that
 each line omit/include is understood as to consequence AKA bios menus.
g...flow chart [ 8 sided raw disk >> 8 side which raid do you want huge 2 
meter
  by two meter ZFS decision tree aka shareware 1998 style inclusions, 
some
  of them so one does not depend upon guides from, say, Solaris
h   more, but that should do.  Just tacking on gossip, sorry... please read
 the three lines above this list so I do not de-emphasize the point of 
this
  reply, and thank you so very kindly for reading.
 
Sort of like a 'me too...'   
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

pkg wrong architecture pRoBlEm !!

[Jeffrey Bouquet]

Script started on Wed Apr  5 03:05:22 2017

Command: pkg add -f /var/cache/pkg/vim-8.0.0534-c8fbf335b0.txz

pkg: Ignoring bad configuration entry in pkg.conf: "/usr/cache/pkg"
pkg: Ignoring bad configuration entry in pkg.conf: "INDEX-12"

Installing vim-8.0.0534...

pkg: wrong architecture: FreeBSD:12:i386 instead of freebsd:12:x86:32

package vim is already installed, forced install
Extracting vim-8.0.0534:   0%
Extracting vim-8.0.0534:   0%
Extracting vim-8.0.0534:   1%
Extracting vim-8.0.0534:   2%
Extracting vim-8.0.0534:   3%
Extracting vim-8.0.0534:   4%
Extracting vim-8.0.0534:   5%
Extracting vim-8.0.0534:   6%
Extracting vim-8.0.0534:   7%
Extracting vim-8.0.0534:   8%
Extracting vim-8.0.0534:   9%
Extracting vim-8.0.0534:  10%
Extracting vim-8.0.0534:  11%
Extracting vim-8.0.0534:  12%
Extracting vim-8.0.0534:  13%
Extracting vim-8.0.0534:  14%
Extracting vim-8.0.0534:  15%
Extracting vim-8.0.0534:  16%
Extracting vim-8.0.0534:  17%
Extracting vim-8.0.0534:  18%
Extracting vim-8.0.0534:  19%
Extracting vim-8.0.0534:  20%
Extracting vim-8.0.0534:  21%
Extracting vim-8.0.0534:  22%
Extracting vim-8.0.0534:  23%
Extracting vim-8.0.0534:  24%
Extracting vim-8.0.0534:  25%
Extracting vim-8.0.0534:  26%
Extracting vim-8.0.0534:  27%
Extracting vim-8.0.0534:  28%
Extracting vim-8.0.0534:  29%
Extracting vim-8.0.0534:  30%
Extracting vim-8.0.0534:  31%
Extracting vim-8.0.0534:  32%
Extracting vim-8.0.0534:  33%
Extracting vim-8.0.0534:  34%
Extracting vim-8.0.0534:  35%
Extracting vim-8.0.0534:  36%
Extracting vim-8.0.0534:  37%
Extracting vim-8.0.0534:  38%
Extracting vim-8.0.0534:  39%
Extracting vim-8.0.0534:  40%
Extracting vim-8.0.0534:  41%
Extracting vim-8.0.0534:  42%
Extracting vim-8.0.0534:  43%
Extracting vim-8.0.0534:  44%
Extracting vim-8.0.0534:  45%
Extracting vim-8.0.0534:  46%
Extracting vim-8.0.0534:  47%
Extracting vim-8.0.0534:  48%
Extracting vim-8.0.0534:  49%
Extracting vim-8.0.0534:  50%
Extracting vim-8.0.0534:  51%
Extracting vim-8.0.0534:  52%
Extracting vim-8.0.0534:  53%
Extracting vim-8.0.0534:  54%
Extracting vim-8.0.0534:  55%
Extracting vim-8.0.0534:  56%
Extracting vim-8.0.0534:  57%
Extracting vim-8.0.0534:  58%
Extracting vim-8.0.0534:  59%
Extracting vim-8.0.0534:  60%
Extracting vim-8.0.0534:  61%
Extracting vim-8.0.0534:  62%
Extracting vim-8.0.0534:  63%
Extracting vim-8.0.0534:  64%
Extracting vim-8.0.0534:  65%
Extracting vim-8.0.0534:  66%
Extracting vim-8.0.0534:  67%
Extracting vim-8.0.0534:  68%
Extracting vim-8.0.0534:  69%
Extracting vim-8.0.0534:  70%
Extracting vim-8.0.0534:  71%
Extracting vim-8.0.0534:  72%
Extracting vim-8.0.0534:  73%
Extracting vim-8.0.0534:  74%
Extracting vim-8.0.0534:  75%
Extracting vim-8.0.0534:  76%
Extracting vim-8.0.0534:  77%
Extracting vim-8.0.0534:  78%
Extracting vim-8.0.0534:  79%
Extracting vim-8.0.0534:  80%
Extracting vim-8.0.0534:  81%
Extracting vim-8.0.0534:  82%
Extracting vim-8.0.0534:  83%
Extracting vim-8.0.0534:  84%
Extracting vim-8.0.0534:  85%
Extracting vim-8.0.0534:  86%
Extracting vim-8.0.0534:  87%
Extracting vim-8.0.0534:  88%
Extracting vim-8.0.0534:  89%
Extracting vim-8.0.0534:  90%
Extracting vim-8.0.0534:  91%
Extracting vim-8.0.0534:  92%
Extracting vim-8.0.0534:  93%
Extracting vim-8.0.0534:  94%
Extracting vim-8.0.0534:  95%
Extracting vim-8.0.0534:  96%
Extracting vim-8.0.0534:  97%
Extracting vim-8.0.0534:  98%
Extracting vim-8.0.0534:  99%
Extracting vim-8.0.0534: 100%

Command exit status: 0
Script done on Wed Apr  5 03:05:54 2017


as SAMBA44 is here per UPDATING, not only does pkg install vim which has
already been fetched need samba43 download, but the wrong architecture
problem above makes it a real conundrum.  How to make pkg smart enough
to either point to which file it gets each from to change to one OR the other,
and put it in /usr/src/PKG-UPDATING, since the pkg is in base,  OR
present a choice of options "keep this architecture, pkg will do FOO, or keep
that architecture, pkg will do BAR, " and let the user pick?

I know I can fix this just by waiting a week and doing beta stuff, but it would 
be
nice to have a polished ncurses or something what-will-happen choice or 
why-it-happened
explanation so conf files can be edited.

Thanks
J Bouquet 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: how to mark llvm* forbidden?

[Jeffrey Bouquet]

On Thu, 6 Apr 2017 17:26:18 +, Brooks Davis  wrote:

> On Wed, Apr 05, 2017 at 06:18:37PM -0700, Russell L. Carter wrote:
> > On 04/05/17 15:32, Chris H wrote:
> > > On Wed, 5 Apr 2017 21:51:40 + Brooks Davis  wrote
> > > 
> > >> On Wed, Apr 05, 2017 at 11:42:16AM -0700, Chris H wrote:
> > >>> OK I'm chasing -CURRENT, and I performed an initial
> > >>> install, followed by a new world/kernel && ports about a
> > >>> mos ago. Last Friday, I svn upped the system (src && ports),
> > >>> rebuilt/installed world/kernel. I just began rebuilding
> > >>> the ports, only to find that when finished, I will likely
> > >>> end up with every version of llvm && clang from version 3
> > >>> to the now current 4. My build session is currently tying
> > >>> nearly every core on the CPU with llvm builds. Given that
> > >>> llvm4 comes in base. Is there *any* reason I can not insist
> > >>> that the ports I upgrade, or build, just use the version(s)
> > >>> of clang/llvm in base? If so. How do I inform the ports
> > >>> that they may *only* use the version(s) in base?
> > >>
> > >> In general you can't.  There are many reasons including: the base llvm
> > >> doesn't include the requisite cmake bits for cmake based ports, some
> > >> ports use unstable APIs and require specific LLVM versions, and some use
> > >> LLVM tools or libraries that aren't built/installed as part of the base
> > >> system.
> > >>
> > >> There are probably some ports where the base clang is fine but that's
> > >> probably mostly down to someone getting USES variables right.
> > >>
> > >> -- Brooks
> > > Grumble.. That's what I was afraid I might hear.
> > > 
> > > Thanks, Brooks! Even if it's not what I was hoping to hear. :)
> > 
> > FWIW, this is biting me hard right now too.  I feel your
> > pain...  I'm a c++17 junky but I might have to let go of
> > llvm-devel.
> 
> If you want to track clang development, I would generally dis-recommend
> the llvm-devel port.  If you check out from upstream svn/git and build
> with cmake and ninja, then you get pretty efficient incremental builds.
> One nice think about the llvm build infrastructure is that you can use
> it in place in the build's bin directory so you don't even need to
> maintain an installed copy.
> 
> -- Brooks


Can/should this be in /usr/ports/UPDATING? 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

pkg with current pipe into pkg fetch problem...

[Jeffrey Bouquet]

Until pkg fetch and/or pkg install can ncurses-deselect the hundreds they are 
about to act on rather
than a Y, N...

cat pkg-to-fetch-file | xargs -J % pkg fetch -y %  
seems to fail.

I've sed'd away the : and the right awk'd away

foo-1: foo-1_1 

so the port remains
foo or foo-1, [ I forget... ]
but the list  [ the file... ] 

foo
bar 
ImageMagich
mplayer
 
etc I can';t seem to pipe into the 'pkg fetch -y' reliably, or if I've found
the solution in the past, have forgotten it.

Experts?or feature request? 
OTOH may be in one of the xargs one-liner or cheat sheet I've filed locally as
.htm, .txt or .pdf...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

new problem?

[Jeffrey Bouquet]

i386_set_ldt: start=-1 num=1 descs=0x38449fac

Tons of those, eight at a time, newly spamming /var/log/messages, maybe after a
fsck_ffs -y the partitions after a crash, that fixed it,

as in
df 
df output, then eight of the above line with the hex values varying only
ls
ls output, then eight of the above line with the hex values varying only
..
2nd problem
persistent LOR in  [several]

nvidia_os:c:662, 824
 
[dmesg only, above, ]

vfs_mount.c:1277
ffs_softdep.c:1908
vfs_subr.c:2600,  2150, 
ffs_vnops.c:280
vfs_bio.c:3500
ufs_dirhash.c:281
vfs_syscalls.c:3364

[some above also in dmesg, most in /var/log/messages...

and another one or two I've wrote down but lost,
gfvs_* I think.
but that line above may be the cause of the i386 line at the top.   ? New 
one to me. 
Sorry. ! 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Some precise procedure...

[Jeffrey Bouquet]

Given the following procedure:

svn up /usr/src
make buildworld
make buildkernel
make installkernel
mergmaster
reboot single user
mergemaster
make installworld
pkg install compatN-i386
reboot
make check-old
make delete-old

etc [ pardon the missing stuff and out of order, this is from memory]

At which precise point either
1... Xorg fails to work
2... nvidia-driver fails to work?
Because in my experience unless a minor upgrade, it happens every time, and
I am caught unawares.. so am wanting in the summaries in UPDATING
3a... do not proceed beyond this without backups, as your video driver may not 
work...
and am slightly confused.
If I svn, but do not buildworld,  is nvidia-driver somehow more unusable? etc 
etc. 
looking at it from an entirely newbie frame of mind, because  a more 
authoritative
source than I may know more about the precise how and why an svn OR a buildworld
should not be attempted if one is more concerned about the driver not breaking
or being unusable 'version mismatch' upon upgrade, than the upgrade itself.

tl;dr
anyone have an expert summary?  if not, just thanks for reading, or throw a 
concept
at me. 
1... Xorg ceases to work and/or 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

 Just had a unique to me, unbootable backup [beside the point,
just a sidebar comment... ]  quandry dealing with the nvidia-driver update
that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]

  12.0 - CURRENT

  [ my previous 'saves' -- files to consult...  were in .jpg, so no avail for 
me to peruse as I was in the terminal ]

Lessons I learned, maybe

[RFC]  rename nvidia-driver.ko to include its version, for instance 
nvidia-modeset-37539.ko
  which would make one's diagnosis a fix easier. 

[suggestions]

... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd thus 
made it 'unavailable'
... document better that one can load nvidia[modeset] later than 
/boot/loader.conf [cli, rc.conf...]

[ mini 'what fixed it for you '  and/or stalled the same ... 
] 
... I had a make.conf in place, 'trapping' a
make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
install in failure
... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
... I had no access to the forums, as the desktop could not be loaded [yet]
... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not usable 
module numbers,
THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include its 5 
digit number
as above.
... I was taken aback by the less infomative
this client has the .39 but the module has the .26 ... 
specifically stating which file/port/kernel module the 'client' refers to
   and which specific modules 'this module' was referring to.  Unknown if that 
is
   fixable here in a .c, .h , or is closed-source upstream in nvidia [corp ] 
where we can
ask them to be more specific or code in some more verbose error messages.
...  Relieved I did not have to rebuild Xorg nor the kernel, just move files 
out of the
  way and do a simple rebuild of the nvidia-driver.
[... Not relieved that the nvidia-driver needed install during the mesa-lib 
reshuffle,  maybe
   did not need to be, just a hazy recollection on my part.  So ignore this 
little bit ]

... All in all a learning experience.  Howsoever, I would like this nvidia 
stuff to be put eventuall
 in /usr/src/UPDATING so the half or third of persons who run into this yearly 
will have a more
 authoritative flowchart of sorts to determine the next course of action.
   something like
  if ... this thta
   if... this that
   if ... this that
  OTOH... error message... a... you may need to...
   ...
   error message ... r... you may need to...

 ... And it would have maybe saved a bit of time here, and I would almost if 
eventually
 possible be sure to copy /usr/src/UPDATING to /usr/ports/x11/nvidia-driver 
for
 more easy access if the desktop was broken


Apologies for the hurried post. Indeed, I have tasked myself to write it up here
locally [ still in scribbled notations...] so I can forestall/fix more quickly 
this
error the next time.
also...
Running late  in other personal matters, and out of time.

Respectfully..

J. Bouquet 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] rename nvidia-driver port binaries [ and other comments]

[Jeffrey Bouquet]

On Mon, 15 May 2017 23:53:10 +0900, Tomoaki AOKI  
wrote:

> Hi.
> If including its version to nvidia.ko and nvidia-modeset.ko,
> [hard / symbolic] link to it with current name should be needed
> not to bother admins every time upgrading.
> 
> BTW, I personally using below in rc.conf for safety.
> This only helps situations that...
> 
>  *Insufficient loader memory, but OK after kernel is started.
> 
>  *Accidentally backed to older version that doesn't have
>   nvidia-modeset.ko and only nvidia-modeset.ko is written in
>   /boot/loader.conf.
> 
> ## Temporary settings for nvidia-driver when failed loading via loader.conf
> kldstat -q -n nvidia.ko
> if [ 0 -ne $? ] ; then
>   echo "Loading nvidia-driver modules via rc.conf."
> #  kldload nvidia
>   if [ -e /boot/modules/nvidia-modeset.ko ] ; then
> #kldload nvidia-modeset
> kld_list="${kld_list} nvidia-modeset.ko"
>   else
> #kldload nvidia
>     kld_list="${kld_list} nvidia.ko"
>   fi
> fi
> 
> 
> On Mon, 15 May 2017 06:41:33 -0700 (PDT)
> "Jeffrey Bouquet"  wrote:
> 
> >  Just had a unique to me, unbootable backup [beside the point,
> > just a sidebar comment... ]  quandry dealing with the nvidia-driver update
> > that  mesa-libs needed.  [ or was appurtenant to it, unsure... ]
> > 
> >   12.0 - CURRENT
> > 
> >   [ my previous 'saves' -- files to consult...  were in .jpg, so no avail 
> > for me to peruse as I was in the terminal ]
> > 
> > Lessons I learned, maybe
> > 
> > [RFC]  rename nvidia-driver.ko to include its version, for instance 
> > nvidia-modeset-37539.ko
> >   which would make one's diagnosis a fix easier. 
> > 
> > [suggestions]
> > 
> > ... Document that the kernel will load a /boot/modules/_nvidia.ko if you'd 
> > thus made it 'unavailable'
> > ... document better that one can load nvidia[modeset] later than 
> > /boot/loader.conf [cli, rc.conf...]
> > 
> > [ mini 'what fixed it for you '  and/or stalled the same ... 
> > ] 
> > ... I had a make.conf in place, 'trapping' a
> > make -DMAKE_JOBS_UNSAFE=yes CC=".../clang39"  [and the other two...] 
> > install in failure
> > ... I had no clue if Xorg was at fault, and luckily did not have to rebuild.
> > ... I had no access to the forums, as the desktop could not be loaded [yet]
> > ... I had to do strings nvidia.ko |grep 26 [39] | less to detect the not 
> > usable module numbers,
> > THUS THE REQ FOR RENAME of the nvidia.ko binary [vs port] to include 
> > its 5 digit number
> > as above.
> > ... I was taken aback by the less infomative
> > this client has the .39 but the module has the .26 ... 
> > specifically stating which file/port/kernel module the 'client' refers 
> > to
> >and which specific modules 'this module' was referring to.  Unknown if 
> > that is
> >fixable here in a .c, .h , or is closed-source upstream in nvidia [corp 
> > ] where we can
> > ask them to be more specific or code in some more verbose error 
> > messages.
> > ...  Relieved I did not have to rebuild Xorg nor the kernel, just move 
> > files out of the
> >   way and do a simple rebuild of the nvidia-driver.
> > [... Not relieved that the nvidia-driver needed install during the mesa-lib 
> > reshuffle,  maybe
> >did not need to be, just a hazy recollection on my part.  So ignore this 
> > little bit ]
> > 
> > ... All in all a learning experience.  Howsoever, I would like this nvidia 
> > stuff to be put eventuall
> >  in /usr/src/UPDATING so the half or third of persons who run into this 
> > yearly will have a more
> >  authoritative flowchart of sorts to determine the next course of action.
> >something like
> >   if ... this thta
> >if... this that
> >if ... this that
> >   OTOH... error message... a... you may need to...
> >...
> >error message ... r... you may need to...
> > 
> >  ... And it would have maybe saved a bit of time here, and I would almost 
> > if eventually
> >  possible be sure to copy /usr/src/UPDATING to 
> > /usr/ports/x11/nvidia-driver for
> >  more easy access if the desktop was broken
> > 
> > 
> > Apologies for the hurried post. Indeed, I have tasked myself to write it up 
> > here
> > locally [ still in scribbled notations...] so I can forestall/fix more 
> > quickly this
> > error the next time.
> &g

Re: [Bug 218849] Remove rc.conf jail configuration via jail_* variables

[Jeffrey Bouquet]

Just commenting on past ideas of mine.  *spend no time replying* .  Thanks!
... inline comments below...  sort of like 'overhear my typing into my bsd
wish list nano-file.'  and as such, scribble a not to thyself, not the list nor 
I,
as I am out of time this [year] and # commenting not # coding an email ...


On Tue, 16 May 2017 10:43:47 +, bugzilla-nore...@freebsd.org wrote:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849
> 
> --- Comment #28 from Miroslav Lachman <000.f...@quip.cz> ---
> (In reply to Jonathan Anderson from comment #27)
> I think the opposite way. Or we end up with the same problems as with ezjail,
> portupgrade, portmaster etc. now. 


 I applaud each of those tools, as well as the extinct portmanager, and wish 
they be
fully pkg compliant and/or the fallback for a resurrected /var/db/pkg 
plain-text version
of .sqlite (s) for those urgent times [ once yearly for instance ] here where a 
newbie
failure by inexperience and/or unresolved bug eclipses my day with a few hours 
of
backup-worked-but-not-as-smoothly-as-I-thought successes...

Some features in base are stalled or very
> complicated just to not break 3rd party tools with no active maintainer.
> "because they are in Handbook"

 I welcome a fully salaried handbook full time 'synchronizer', too advanced in 
years
on my part, but yes I could pay yearly a share.

> It would be better to document jails with base tools and just some list of 3rd
> party tools with brief info about them and link to homepage of those projects.
.
off topic, snuck in:

 Some .htm,.php,.aspx,  I save in .htm .txt  manner a .htm[ or... ] for 
read-later, many of which  .htm[etc]  I save, vs xclip > disk ,  appear once
loaded on disk as a jumble of text within interspersed /tags/ and /css/ stuff 
making it
transcrible yes, but readable, no, so I give up and re-google the page I saved. 
 If anyone
has any best practice to educate me on a better save-to-disk-htm[php][aspx] 
method that is foolproof. comparatively, 
to reload from disk later [ for presentations, etc...] I may, if can,  also 
paypal/snail mail a
'finders fee',  if, say
after a few months of usage I could frame it on the wall, actually, so I do not 
continue as
I presently do, and feel of more use to others in pulling up saved files vs [ 
oh, I thought
I could read that, it is 2/3 mime-glyphs... ] 'stuff that happens' to me and my 
sometimes
guests.
cc:  the handbook guy, above, but that is in the distant future... so to speak. 
 Or, add
filler to an email.  Sorry, or, continue as/until I de-procrastinate and 'send' 
to my 
understanding fellow list-readers [ tl/dr :   see header, unfortunately top 
posted...
we are looking over the shoulder at my nano file, that 'just this once, I 
promise' is
publicly posted to the list so others can treat it as the off-topic it purports 
to be, 
comprises, asserts, mitigates itself as, and ... ]  


Have a very pleasant day, and I do not mean that with any insincerity.  
Thanks! 
.


> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: svn commit: r318757 - head

[Jeffrey Bouquet]

On Wed, 24 May 2017 20:10:00 +0200, "O. Hartmann"  
wrote:

> Am Wed, 24 May 2017 13:04:30 -0500
> Larry Rosenman  schrieb:
> 
> > On 5/24/17, 1:01 PM, "O. Hartmann"  wrote:
> > 
> > Am Wed, 24 May 2017 19:40:46 +0200
> > "O. Hartmann"  schrieb:
> > 
> > > Am Wed, 24 May 2017 12:28:51 -0500
> > > Larry Rosenman  schrieb:
> > >   
> > > > I fixed my issues by force-rebuilding perl and all installed p5-* 
> > ports. 
> > > > 
> > > > 
> > > 
> > > 
> > > This isn't possible in my case :-(
> > > 
> > > lang/perl rebuilds all right, but every p5-* ports fails with
> > > 
> > > [...]
> > > Checking if your kit is complete...
> > > ListUtil.c: loadable library and perl binaries are mismatched (got 
> > handshake key
> > > 0xd200080, needed 0xdf00080) 
> > > *** Error code 1
> > > 
> > > I tried to rebuild also via portmaster -f, no success. Now, I growing 
> > bunch of
> > > ports showing up with this mysterious error.
> > > 
> > > To which port "ListUtil.c" might belong to?
> > > 
> > > Rebuilding autotools (which I suspected first) also fails ...
> > > 
> > >   
> > 
> > ... it seems, as K. belousov mentioned prior regarding different ABI, 
> > all p5-*
> > ports need to be deleted by force ... They rebuild properly afterwards.
> > 
> > Which is essentially what I did re: Poudriere (poudriere bulk –C –j  
> > -p
> >  -f )
> 
> I use the traditional "make" way (via portmaster)
> 
> -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


Would it be worthwhile to have say weeks 1-3 of each month usual, then the 
fourth week a
'fix poudriere run of current totally [ or synth ] so that snapshots can be had 
monthly of
the CURRENT with ALL ports working as packages?  And a freeze on CURRENT during 
that
time? so poudriere and/or synth takes precedence over CURRENT?  For the sake of 
persons using CURRENT as their principal desktop/dev box?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

pkg weirdness

[Jeffrey Bouquet]

On a machine, pkg install xorg-server.
It wants to install the 1G llvm40
downloads... errors out.  Reboot

boot up
use tty1 rather than tty0
pkg install xorg-server
AGAIN downloads the metadata.
starts to AGAIN download llvm40, I cntl-C it.
I add 'pkg add ' the llvm40 that is ALREADY in /var/cache/pkg
Now pkg install xorg-server runs again, but RE downloading the smaller [... 
xorg-server ]
.
It lists the packages it is going to download.
Then, not in the new install... upgrade... reinstall... Y/N? ... it starts
downloading seamonkey!   I only asked it to 'install xorg-server!'
.
I think some more huge transparency [ pkg tells us in a verbose way what it
is doing, and why, and eventually have fine grained menu control before an
action... so that one can begin to make more sense of a post like this 
>> eventual bugzilla if need be.
..
Just curious more than anything this time, though... 
.
Sounds like did not happen, but did.   Sorry... 
[ by the way on the desktop, if I build from ports it is v11, but if I use pkg, 
it is v12. ] 
So I build from ports, all is good, but next pkg [week] it wants to upgrade a 
port
from v11 to v12.  too many places to look, I don't see that setting [v11 on a 
v12 machine]
anywhere.12.0-CURRENT by the way...
..
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg weirdness [corrected]

[Jeffrey Bouquet]

Errata... on a part of the below...

On Thu, 25 May 2017 17:19:05 -0700 (PDT), "Jeffrey Bouquet" 
 wrote:

> On a machine, pkg install xorg-server.
> It wants to install the 1G llvm40
> downloads... errors out.  Reboot
> 
> boot up
> use tty1 rather than tty0
> pkg install xorg-server
> AGAIN downloads the metadata.
> starts to AGAIN download llvm40, I cntl-C it.
> I add 'pkg add ' the llvm40 that is ALREADY in /var/cache/pkg
> Now pkg install xorg-server runs again, but RE downloading the smaller [... 
> xorg-server ]
> .
> It lists the packages it is going to download.
> Then, not in the new install... upgrade... reinstall... Y/N? ... it starts

  ^^^ was in a later version of the 
list...

> downloading seamonkey!   I only asked it to 'install xorg-server!'
> .
> I think some more huge transparency [ pkg tells us in a verbose way what it
> is doing, and why, and eventually have fine grained menu control before an
> action... so that one can begin to make more sense of a post like this 
> >> eventual bugzilla if need be.
> ..
> Just curious more than anything this time, though... 
> .
> Sounds like did not happen, but did.   Sorry... 
> [ by the way on the desktop, if I build from ports it is v11, but if I use 
> pkg, it is v12. ] 
> So I build from ports, all is good, but next pkg [week] it wants to upgrade a 
> port
> from v11 to v12.  too many places to look, I don't see that setting [v11 on a 
> v12 machine]
> anywhere.12.0-CURRENT by the way...
> ..
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Sorry. seamonkey WAS in the list...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Xorg error 'alphasort'

[Jeffrey Bouquet]

First try, did not build, to try to fix,  Xorg, took the easy way out and 
restored the
/usr/local/bin/Xorg that was working two days ago from backup.

Xorg.log.0 says it is devd???
...
error in Subject is only from memory.
...
Fixed, temporarily, in under 15 minutes here.  No time to investigate further, 
just wondering...
.
1.18.4,1 >> 1.18.4_1,1 
xorg-server
was done within the last 12 hours from pkg 12.0-CURRENT
ino64?  not upto speed... on that either. 

Not tested: 
xorg-vfbserver
xorg-nestserver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Firefox (and other Mozilla products) after ino64

[Jeffrey Bouquet]

On Wed, 31 May 2017 23:27:16 +0200, Dimitry Andric  wrote:

> Hi,
> 
> Due to the recent ino64 update in 12.0-CURRENT, there have been some
> reports by Firefox port users about crashes.  While I personally have
> not experienced these crashes, as I immediately rebuilt all my ports
> from scratch after the ino64 update, I think can explain why the
> following combination is very likely to have problems:
> 
> * kernel+world after ino64
> * www/firefox package from before ino64
> 
> It is because Firefox's JavaScript engine is doing tricks to get at libc
> structures and functions (via an FFI mechanism), and several structure
> layouts and offsets are hardcoded into its engine at build time.
> 
> For instance, here is the place where the engine determines the offset
> of struct dirent's d_name field:
> 
>   
> https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l648
> 
> Further down in the file, several offsets of fields in struct stats are
> similarly determined:
> 
>   
> https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l677
> 
> Now, since ino64 changed quite a number of structure layouts, including
> struct dirent, struct stat, and others, such offsets determined in the
> past will no longer be valid!
> 
> It is pretty likely that Firefox will attempt to access these fields,
> finding bogus values, or simply reading invalid memory, and crashing
> because of this.  Or at the least, the behavior will be unstable.
> 
> This also applies to other Mozilla products, such as Thunderbird,
> SeaMonkey, and so on.  These should all be rebuilt from scratch under
> ino64.
> 
> -Dimitry


What of machines where for some reason ports do not always build? [ for 
instance, 
ones with past workarounds for a
failed installworld...  ]  that still are in critical use daily? And,or where 
the
system has been installed for so long without reinstall that some ports 
segfault unless 'pkg lock'  ... and not usually upgraded... and/or thus using
binaries from backup... 

  Are upstream repositories to have those [ browser, email]  ports?  For 
instance, here iridium I cannot get to build... 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: nvidia drivers mutex lock

[Jeffrey Bouquet]

I see the same message, upon load, ...

On Thu, 6/1/17, blubee blubeeme  wrote:

 Subject: nvidia drivers mutex lock
 To: freebsd-po...@freebsd.org, freebsd-current@freebsd.org
 Date: Thursday, June 1, 2017, 11:35 AM
 
 I'm running nvidia-drivers 375.66 with a GTX
 1070 on FreeBSD-Current
 
 This problem just started happening
 recently but, every so often my laptop
 screen will just blank out and then I
 have to power cycle to get the
 machine up and running again.
 
 It seems to be a problem with nvidia
 drivers acquiring duplicate lock. Any
 info on this?
 
 Jun  2 02:29:41 blubee kernel:
 acquiring duplicate lock of same type:
 "os.lock_mtx"
 Jun  2 02:29:41 blubee kernel: 1st
 os.lock_mtx @ nvidia_os.c:841
 Jun  2 02:29:41 blubee kernel: 2nd
 os.lock_mtx @ nvidia_os.c:841
 Jun  2 02:29:41 blubee kernel:
 stack backtrace:
 Jun  2 02:29:41 blubee kernel: #0
 0x80ab7770 at
 witness_debugger+0x70
 Jun  2 02:29:41 blubee kernel: #1
 0x80ab7663 at
 witness_checkorder+0xe23
 Jun  2 02:29:41 blubee kernel: #2
 0x80a35b93 at
 __mtx_lock_flags+0x93
 Jun  2 02:29:41 blubee kernel: #3
 0x82f4397b at
 os_acquire_spinlock+0x1b
 Jun  2 02:29:41 blubee kernel: #4
 0x82c48b15 at _nv012002rm+0x185
 Jun  2 02:29:41 blubee kernel:
 ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM:
 Argument #4 type mismatch - Found
 [Buffer], ACPI requires [Package]
 (20170303/nsarguments-205)
 Jun  2 02:29:42 blubee kernel:
 nvidia-modeset: Allocated GPU:0
 (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @
 PCI::01:00.0
 
 Best,
 Owen
 ___
 freebsd-po...@freebsd.org
 mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
 


... then Xorg will run happily twelve hours or so.  The lockups here happen 
usually
when too large or too many of number of tabs/ large web pages with complex CSS 
etc
are opened at a time.  
So no help, just a 'me too'.  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: nvidia drivers mutex lock

[Jeffrey Bouquet]

SOME LINES BOTTOM POSTED, SEE...

On Fri, 6/2/17, Tomoaki AOKI  wrote:

 Subject: Re: nvidia drivers mutex lock
 To: freebsd-current@freebsd.org
 Cc: "Jeffrey Bouquet" , "blubee blubeeme" 

 Date: Friday, June 2, 2017, 11:25 PM
 
 Hi.
 Version
 381.22 (5 days newer than 375.66) of the driver states...
 [1]
 
  Fixed hangs and
 crashes that could occur when an OpenGL context is
  created while the system is out of available
 memory.
 
 Can this be related
 with your hang?
 
 IMHO,
 possibly allocating new resource (using os.lock_mtx
 guard)
 without checking the lock first while
 previous request is waiting for
 another can
 cause the duplicated lock situation. And high memory
 pressure would easily cause the situation.
 
  [1] http://www.nvidia.com/Download/driverResults.aspx/118527/en-us
 
 Hope it helps.
 
 
 On Thu, 1 Jun
 2017 22:35:46 + (UTC)
 Jeffrey Bouquet
 
 wrote:
 
 > I see the same
 message, upon load, ...
 >
 
 > On Thu, 6/1/17, blubee blubeeme 
 wrote:
 > 
 >  Subject:
 nvidia drivers mutex lock
 >  To: freebsd-po...@freebsd.org,
 freebsd-current@freebsd.org
 >  Date: Thursday, June 1, 2017, 11:35
 AM
 >  
 >  I'm
 running nvidia-drivers 375.66 with a GTX
 >  1070 on FreeBSD-Current
 >  
 >  This problem
 just started happening
 >  recently but,
 every so often my laptop
 >  screen will
 just blank out and then I
 >  have to
 power cycle to get the
 >  machine up and
 running again.
 >  
 >  It seems to be a problem with nvidia
 >  drivers acquiring duplicate lock. Any
 >  info on this?
 >  
 >  Jun〓 2 02:29:41 blubee kernel:
 >  acquiring duplicate lock of same
 type:
 >  "os.lock_mtx"
 >  Jun〓 2 02:29:41 blubee kernel: 1st
 >  os.lock_mtx @ nvidia_os.c:841
 >  Jun〓 2 02:29:41 blubee kernel: 2nd
 >  os.lock_mtx @ nvidia_os.c:841
 >  Jun〓 2 02:29:41 blubee kernel:
 >  stack backtrace:
 > 
 Jun〓 2 02:29:41 blubee kernel: #0
 > 
 0x80ab7770 at
 > 
 witness_debugger+0x70
 >  Jun〓 2
 02:29:41 blubee kernel: #1
 > 
 0x80ab7663 at
 > 
 witness_checkorder+0xe23
 >  Jun〓 2
 02:29:41 blubee kernel: #2
 > 
 0x80a35b93 at
 > 
 __mtx_lock_flags+0x93
 >  Jun〓 2
 02:29:41 blubee kernel: #3
 > 
 0x82f4397b at
 > 
 os_acquire_spinlock+0x1b
 >  Jun〓 2
 02:29:41 blubee kernel: #4
 > 
 0x82c48b15 at _nv012002rm+0x185
 >  Jun〓 2 02:29:41 blubee kernel:
 >  ACPI Warning:
 \_SB.PCI0.PEG0.PEGP._DSM:
 >  Argument #4
 type mismatch - Found
 >  [Buffer], ACPI
 requires [Package]
 > 
 (20170303/nsarguments-205)
 >  Jun〓 2
 02:29:42 blubee kernel:
 > 
 nvidia-modeset: Allocated GPU:0
 > 
 (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @
 >  PCI::01:00.0
 > 
 
 >  Best,
 >  Owen
 > 
 ___
 >  freebsd-po...@freebsd.org
 >  mailing list
 >  https://lists.freebsd.org/mailman/listinfo/freebsd-ports
 >  To unsubscribe, send any mail to
 "freebsd-ports-unsubscr...@freebsd.org"
 >  
 > 
 > 
 > ... then Xorg will
 run happily twelve hours or so.  The lockups here happen
 usually
 > when too large or too many of
 number of tabs/ large web pages with complex CSS etc
 > are opened at a time.  
 >     So no help, just a 'me
 too'.  
 >
 ___
 > freebsd-current@freebsd.org
 mailing list
 > https://lists.freebsd.org/mailman/listinfo/freebsd-current
 >
 To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
 > 
 > 
 
 
 -- 
 Tomoaki
 AOKI    
 



might be a workaround
Xorg/nvidia ran all night with this:
   nvidia-settings >>  X server display configuration >> Advanced >> Force Full 
Composition Pipeline
... for the laptop freezing.  Could not hurt to try.  " merge with Xorg.conf " 
from nvidia-settings...
..
18 hours uptime so far, even past
the 3 am periodic scripts.   Have not rebooted out of the Xorg though so may 
require edit-out of
xorg.conf if that is the case, in other words differing from real-time apply and
xorg initially start applies.  

 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

undefined symbol 'stat'

[Jeffrey Bouquet]

  The latest pkg updates broke firefox here, which won't build  [ patches fail 
to apply ]
  Also seamonkey, but building sqlite3 locally fixed that.
  
  [ not that I'd expect firefox to build anyway, not been that lucky 
recently... ] 

  Web search turns up no 'undefined symbol stat' on 12.0-CURRENT that I can 
find.

  Subject give the entirety of the error. 
  Building webkit-gtk2 locally as of now to try to fix it in a third round of 
ports. ... 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: undefined symbol 'stat'

[Jeffrey Bouquet]

On Sat, 3 Jun 2017 19:32:02 -0400, Allan Jude  wrote:

> On 2017-06-03 19:28, Jeffrey Bouquet wrote:
> >   The latest pkg updates broke firefox here, which won't build  [ patches 
> > fail to apply ]
> >   Also seamonkey, but building sqlite3 locally fixed that.
> >   
> >   [ not that I'd expect firefox to build anyway, not been that lucky 
> > recently... ] 
> > 
> >   Web search turns up no 'undefined symbol stat' on 12.0-CURRENT that I can 
> > find.
> > 
> >   Subject give the entirety of the error. 
> >   Building webkit-gtk2 locally as of now to try to fix it in a third round 
> > of ports. ... 
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> > 
> 
> The ino64 change that went into -current recently changed a lot of stuff
> related to stat(), and versioned the symbol. You are trying to run apps
> compiled for a newer version of -current than you are running. You need
> to update your kernel and userland to patch what pkg is built against.
> 
> -- 
> Allan Jude


Thanks.  I'm getting around to it, unfortunately too slowly.  Not a half hour 
after the
email, I have the v11 firefox package running happily.  webkit-gtk2 also built 
here.
So no immediate concern, browser or other GUI [ claws-mail ] at least that I use
daily.  [  pkg.freebsd.org seems way undermentioned in the wiki, and 
elsewhere...  BTW ] 

  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ERRATA: 12.0-CURRENT binaries 'stat' errors.

[Jeffrey Bouquet]

ne
/usr/local/bin/ne: Undefined symbol "stat"
ktrace -di ne
/usr/local/bin/ne: Undefined symbol "stat"

I may have posted in error an 'fstat' instead, unsure, to the ports list just 
yesterday or so.
A workaround is to use pkg.freebsd.org to attain compat11x binaries which run.
This is a showstopper here otherwise as some large ports, do not build on the
legacy desktop [ 2004 ] that has been updated numerous times, and for which
I do not wish to reinstall.

And, pkg gives conflicting messages, as pkg binaries are shown ABI v12 whereas 
if I
do build from ports, the ports are shown as v11 ABI. 
Also, ABI changed: 'freebsd:12:x86:32' > 'freebsd:12:*'   upgrades are 
requested making
  things so I have to lock many ports at v11 as the newer have the 'stat' or 
'fstat' error.

  So more than one issue, I think maybe three in tandem making 'which to tackle 
first'
even problematic.

  Any advices?  even a binary editor to examine the /ne for 'stat' code ? 

  Apologies for not being knowledgeable in many of the ways to code a solution 
or even
coding... 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Unsure about buildworld

[Jeffrey Bouquet]

Used rsync to put /usr/src/.svn to
/usr2/src/.svn [another disk]
did an svn up of that  ^^
# sh
export CC=/usr/local/bin/clang39# and the two others
cd /usr2/src
MAKEOBJDIRPREFIX=/usr2/obj -DNO_PROFILE ... buildworld.


which halts on some error 
ranlib -d ... .a
exec(ranlib) no such file or directory
...
Is there a more knowledgeable way of putting both src and obj on a seperate disk
and having the build complete AND
be sure where it builds, [ obj ] and the precise way to test an install  [ 
pre-rsync to the
production system , so to speak ]or
some other *preferred* way,  extract base.txz ...   or even a clean 
12.0-CURRENT snapshot
system to rsync onto the present one... 
.
  My motivation is I do not wish to attempt an svn upgrade of the desktop 
without a
certainty that the installworld will complete so the nvidia-driver can more 
likely
than not be restored to a working state.

  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Unsure about buildworld

[Jeffrey Bouquet]

On Tue, 20 Jun 2017 22:15:18 -0500, Benjamin Kaduk  wrote:

> On Tue, Jun 20, 2017 at 01:58:58PM -0700, Jeffrey Bouquet wrote:
> > Used rsync to put /usr/src/.svn to
> > /usr2/src/.svn [another disk]
> > did an svn up of that  ^^
> 
> Is there some reason (e.g., documentation) to believe that will
> result in a stable and self-consistent checkout?

  I've had enough installworlds that failed mid-install to be overly hesitant 
and thus
sort of wish-listing for a
make -DNVIDIA-ASSURES-BUILDING-AND-INSTALLWORLD-TEST-COMPLETED=yes
for resilency.   Not to mention a /usr/src/UPDATING method of cli 
fetching/wget/curl
base.txz and then " gcp -R  - / < unxz base.txz "  [ do not quote any of these ]
as a installworld-went-awry recovery-from-thumbdrive method... 

tl;dr, ... wish list... newbie by infrequency of updates.



> 
> > # sh
> > export CC=/usr/local/bin/clang39# and the two others
> 
> I don't think that's the correct variable(s) to set to use an
> external compiler.
> 
I've in a .sh  or two...  usually works. Someone may correct me. 

> > cd /usr2/src
> > MAKEOBJDIRPREFIX=/usr2/obj -DNO_PROFILE ... buildworld.
> > 
> > 
> > which halts on some error 
> > ranlib -d ... .a
> > exec(ranlib) no such file or directory
> > ...
> > Is there a more knowledgeable way of putting both src and obj on a seperate 
> > disk
> > and having the build complete AND
> > be sure where it builds, [ obj ] and the precise way to test an install  [ 
> > pre-rsync to the
> > production system , so to speak ]or
> > some other *preferred* way,  extract base.txz ...   or even a clean 
> > 12.0-CURRENT snapshot
> > system to rsync onto the present one... 
> 
> Building a release and extracting the tarballs is something that
> people do, though I don't have any personal experience to recommend
> it.
> 

  I've done the latter [ recovered by base.txz ] but never tried to build a 
release or
anything other than bw bk ik iw ... unless incremental binaries or failing 
disks... and
since switching to SATA from EIDE many less of the latter. 

> -Ben
> 
> > .
> >   My motivation is I do not wish to attempt an svn upgrade of the desktop 
> > without a
> > certainty that the installworld will complete so the nvidia-driver can more 
> > likely
> > than not be restored to a working state.
> > 
> >   
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Buildworld failing early. Nothing SVN yet except Makefile.inc1

[Jeffrey Bouquet]

  Wishing to avoid SVN for now to salvage nvidia-driver just in case... 



#/bin/sh
# re-used sh as one may surmise...  $1 not used... 

export CC=/usr/local/bin/clang40
export CXX=/usr/local/bin/clang++40  
export CPP=/usr/local/bin/clang-cpp40 

#cd  $1  # /usr/src/usr.sbin/pw
#make cleandepend
#make obj
#make depend
#make install

make MK_PROFILE=no -DNO_CLEAN buildworld && yell || yell
..
that failed immediately, exec ranlib, something.
however,
#  script
# zsh
# sh bw.sh 
 
and with the latest Makefile.inc1 with r383487, it starts... 
... 
never mind.
the error persists.
ar -crD libroken.a ... ... ... | tsort -q`
ranlib -D libroken.a
bmake[3]: exec(ranlib) failed (No such file or directory)   
  
*** Error code 1
bmake[3] stopped in /usr/src/kerberos5/lib/libroken
*** Error code 1
.
Not tried so far: changing /var and /tmp nosuid > suid...
...
okay, that is done.
Also, moved src.conf out of the way.
...
Proceeding again.
Again,
ranlib -D libopenbsd.a
bmake[3]: exec(ranlib) failed (No such file or directory)
..
after
ar -crD libopenbsd.a `NM='nm' NMFLAGS='' lorder getdtablecount.o imsg-buffer.o 
imsg.o ohash.o | tsort -q`
...
Not enough cleandepends, cleanworld first or more fixable ?? 


bmake[3]: stopped in /usr/src/lib/libopenbsd


...  besides nosuid > suid, src.conf, make.conf, llvm40, ???
...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

status of and/or url to check base packages repo somewhere?

[Jeffrey Bouquet]

  As the Subject: is there a canonical url to check, and a procedure in place 
yet, to, 
for instance, if one cannot buildworld on 12.0-CURRENT, to access the package 
.txz or 
whatever and 'pkg fetch ...  pkg add ...' which would substitute for the 
buildworld 
cycle?  Also, one would be rebooted into a GENERIC kernel, ... and other 
details ?

  
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Critique this plan?

[Jeffrey Bouquet]

  It seems I've a brick wall [too many ports to use pkg effectively ] -- [ 3551 
] 
and too many need ' pkg lock ' in ' v11 ' for ino64 fixes, 12.0-CURRENT, and 
quite a few
others fail to build from ports, either compiler, so are also 'pkg lock ' or in 
a few
instances binaries/trees copied from other installs, so that my DESKTOP can 
continue
running a if it were 2003 Microsoft based, vs 2004 Freebsd January based, where 
a reinstall
seems in order OR, I should just sit and wait til 13.0-CURRENT and proceed that 
way.
..
  Meantime, how is the following as a workaround
  mv /usr/src /src-2017
  mv /usr/obj /obj-2017
  mkdir -p /usr/src
  mkdir -p /usr/obj
  cd /usr/src
  bw, etc

or
.
 [ clean install ]
 mount -t ufs /dev/gpt/2004root /mnt-root
 mount -t ufs /dev/gpt/2004var  /mnt-var
 mount -t ufs /dev/gpt/2004tmp  /mnt-tmp
  mount -t ufs /dev/gpt/2004usr /mnt-usr
 into which I surmise an installworld would fail as multiple DESTDIRS are 
included. 
.
  nullfs ?
...
 Revert to all-in-one / system, no /var /tmp /usr?
.
 or some new install 
.
  None of these are plans as of yet, save proceeding without any upgrade 
whatsoever.  I recall
unpacking base.txz [etc] to fix a failing installworld in the recent past, so 
any foolproof
method of that would also be welcome.  But I suspect much would remain undone, 
initial *proper* setup of /etc/mail, /etc/groups, as well as the loss of 
fine-tunings I've
done over the past 13 years or so, if it were done preplanned as a 
new-then-rsync-the-old
system-over-it sort of reinstall  [ not looking forward to undoing years of 
week-by-week
this-rc  that-rc fixups...  newbie in so many areas who just copy-pasted the
work of others into this system, to excellent, usually effect.] 
.. 
  Apologies for the email that went on three times longer [ more verbose  ] 
than I planned, sort
of making its Subject:a  misstatement of the body of the email.
..
...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"