Re: 10.2: ntp update breaks DCF77 clock

2015-08-16 Thread Matthew Seaman
On 15/08/2015 16:46, Christian Weisgerber wrote:
 The ntp code is not very transparent, but I think the root cause
 are the ntp/config.h changes that came with the 4.2.8p3 update.  A
 number of previously disabled obscure clock drivers were enabled,
 but crucially CLOCK_RAWDCF was disabled, and this is the PARSE
 subdriver needed to use the popular DCF77 serial receivers.
 
 Frankly, it looks like we used to have a carefully considered
 selection of clock drivers which has been blindly splattered with
 the upstream defaults in the last update.

Hmmm I suggest raising a PR with patches to revert the changes in
the set of enabled clock drivers (or merge with the current list).  It's
not going to get you a working DCF77 receiver in a -RELEASE version any
time soon, I'm afraid, as you'll have to wait until the next release for
the changes to percolate down, but having a sensible list of enabled
clock drivers in base is definitely a good move.

For a more timely solution[*], it looks like the ports is your best
option.  By default the net/ntp port disables all of the clock drivers,
but allows you to configure the port to enable whatever drivers you
want.  If you built your own package it would be simple to get the right
support compiled in.  However, that won't help if you're determined to
use pre-built packages only, in which case there would need to be a
slave port with enabled clock drivers.  That's something you could
certainly argue for;

This is a symptom of the current state of the ports tree -- we've
switched over to pkg(8), but we're still working through a lot of
changes to fully enable pkg capabilities.  A lot of the functionality
still only really works if you build your own ports.  There are changes
planned, like sub-packages and package flavours which should help, but
in the case of net/ntp where clock drivers are compiled into the main
binary unfortunately those won't apply.  If NTP clock drivers were
implemented as loadable modules it would be a lot easier...

Cheers,

Matthew

[*] Pun unintentional.



signature.asc
Description: OpenPGP digital signature


Re: msk msk0 watchdog timeout freeze hang lock stop problem

2015-08-16 Thread Yonghyeon PYUN
On Wed, Aug 12, 2015 at 09:44:06AM -0400, Roosevelt Littleton wrote:
 Hi,
 So, I can confirm with the attached patch. I have a working msk0 that
 hasn't failed for the past month. I considered this problem fix for me.
 Since, I have went a long time without any problems. Thanks!

I'm not sure which patch you used.  Given that users reported
10.2-RELEASE works, it would be great if you revert local patch
and try it again on 10.2-RELEASE.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Swap Questions

2015-08-16 Thread Ronald Klop
On Sat, 15 Aug 2015 21:07:55 +0200, Tim Daneliuk tun...@tundraware.com  
wrote:



On 08/14/2015 12:39 PM, Warren Block wrote:

On Fri, 14 Aug 2015, Tim Daneliuk wrote:

I just built a 10.2 machine on a cloud-based VPS (Digital Ocean) that  
has
512M of memory and 1G of swap partition.  I am seeing a ton of errors  
like

this:

Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(10): failed
Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(14): failed
Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(11): failed
Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(6): failed
Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(7): failed
Aug 14 00:01:22 myhost last message repeated 2 times


So, I added this to fstab (after creating /usr/swap0):

md99noneswapsw,file=/usr/swap000

And then did this:

swapon -aq


But, when I do a swapinfo, all I can see is the disk swap partition
that comes standard with the VPS:


Device  1K-blocks UsedAvail Capacity
/dev/gpt/swapfs   1048576   456572   59200444%


Add the -L (late) option to swapon.  How this works might differ  
between 10-Release, 10-Stable, and 11.


Incidentally, md99 does not have to be literal, it's just meant to get  
the md device number up out of the way of common interactive usage of  
mdconfig.



So -L does fix the problem - sort of.  The machine picks up the file as
additional swap on boot just fine.  HWOEVER, when I try to reboot or shut
down the host, I get a panic telling me some noise about not being able
to shutdown swap for some reason.


It helps if you provide the exact text of the panic. People regularly  
don't get to see these inside there crystal ball. ;-) You call it noise.  
Others might get an helpful hint from it to help you.


Regards,
Ronald.



So ... I decided to just add a second disk partition for swap and -
for some reason - it works fine interactively, but upon reboot,
the newly created swap partition no longer exists and gpart shows
the space as free again.  I tried a gpart commit, but get
operation not permitted.  So now I am trying to figure out
how to make gpart changes stick.  This may be an artifact of
the way Digital Ocean droplets are set up 

G

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


Re: Swap Questions

2015-08-16 Thread Ronald Klop
On Sun, 16 Aug 2015 14:51:49 +0200, Ronald Klop ronald-li...@klop.ws  
wrote:


On Sat, 15 Aug 2015 21:07:55 +0200, Tim Daneliuk tun...@tundraware.com  
wrote:



On 08/14/2015 12:39 PM, Warren Block wrote:

On Fri, 14 Aug 2015, Tim Daneliuk wrote:

I just built a 10.2 machine on a cloud-based VPS (Digital Ocean) that  
has
512M of memory and 1G of swap partition.  I am seeing a ton of errors  
like

this:

Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(10): failed
Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(14): failed
Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(11): failed
Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(6): failed
Aug 14 00:01:22 myhost kernel: swap_pager_getswapspace(7): failed
Aug 14 00:01:22 myhost last message repeated 2 times


So, I added this to fstab (after creating /usr/swap0):

md99noneswapsw,file=/usr/swap000

And then did this:

swapon -aq


But, when I do a swapinfo, all I can see is the disk swap partition
that comes standard with the VPS:


Device  1K-blocks UsedAvail Capacity
/dev/gpt/swapfs   1048576   456572   59200444%


Add the -L (late) option to swapon.  How this works might differ  
between 10-Release, 10-Stable, and 11.


Incidentally, md99 does not have to be literal, it's just meant to get  
the md device number up out of the way of common interactive usage of  
mdconfig.



So -L does fix the problem - sort of.  The machine picks up the file as
additional swap on boot just fine.  HWOEVER, when I try to reboot or  
shut

down the host, I get a panic telling me some noise about not being able
to shutdown swap for some reason.


It helps if you provide the exact text of the panic. People regularly  
don't get to see these inside there crystal ball. ;-) You call it noise.  
Others might get an helpful hint from it to help you.



Maybe you already knew, but adding dumpdev=AUTO in /etc/rc.conf can  
provide a kernel dump on panic which can be analyzed after reboot.


Ronald.




Regards,
Ronald.



So ... I decided to just add a second disk partition for swap and -
for some reason - it works fine interactively, but upon reboot,
the newly created swap partition no longer exists and gpart shows
the space as free again.  I tried a gpart commit, but get
operation not permitted.  So now I am trying to figure out
how to make gpart changes stick.  This may be an artifact of
the way Digital Ocean droplets are set up 

G

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

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


freebsd-update to 10.2-RELEASE broken ?

2015-08-16 Thread Christian Kratzer

Hi,

I have been trying to update several of my FreeBSD 10.1 amd64 VM to 
10.2-RELEASE with freebsd-update and have been failing with an incorrect hash 
error.

This is what happens with a plain vanilla 10.1-RELEASE vm when I try to update 
to 10.2-RELEASE

--snipp--
root@test10:~ck # uname -a
FreeBSD test10.cksoft.de 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 
11 21:02:49 UTC 2014 
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
root@test10:~ck # freebsd-update upgrade -r 10.2-RELEASE
Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 10.1-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic world/base world/doc world/games world/lib32

The following components of FreeBSD do not seem to be installed:
src/src

Does this look reasonable (y/n)? y

Fetching metadata signature for 10.2-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Fetching files from 10.1-RELEASE for merging... done.
Preparing to download files... done.
Fetching 11120 
patches.102030405060708090100110120130140150160170180190200210220230240250260270280290300310320330340350360370380390400410420430440450460470480490500510520530540550560570580590600610620630640650660670680690700710720730740750760770780790800810820830840850860870880890900910920930940950960970980990100010101020103010401050106010701080109011001110112011301140115011601170118011901200121012201230124012501260127012801290130013101320133013401350...
.13601370138013901400141014201430144014501460147014801490150015101520153015401550156015701580159016001610162016301640165016601670168016901700171017201730174017501760177017801790180018101820183018401850186018701880189019001910192019301940195019601970198019902000201020202030204020502060207020802090210021102120213021402150216021702180219022002210222022302240225022602270228022902300231023202330234023502360237023802390240024102420243024402450246024702480249025002510252025302540255025602570258025902600
26102620263026402650266026702680269027002710272027302740275027602770278027902800281028202830284028502860287028802890290029102920293029402950296029702980299030003010302030303040305030603070308030903100311031203130314031503160317031803190320032103220323032403250326032703280329033003310332033303340335033603370338033903400341034203430344034503460347034803490350035103520353035403550356035703580359036003610362036303640365036603670368036903700371037203730374037503760377037803790380038103820383038403

Re: freebsd-update to 10.2-RELEASE broken ?

2015-08-16 Thread Kurt Jaeger
Hi!

[bob wrote]
 [ck wrote]
  I have been trying to update several of my FreeBSD 10.1 amd64
  VM to 10.2-RELEASE with freebsd-update and have been failing with
  an incorrect hash error.

 FWIW I had the same issue yesterday on a couple of systems.
 Repeating freebsd-update worked after two or three goes.

I've seen the same problem on several hosts and discussed it by mail
with gjb@.

We assumed that I have a DNS problem because of this line:

 Looking up update.FreeBSD.org mirrors... none found.

This happens with this query inside the freebsd-update script, at
line 950:

host -t srv _http._tcp.update.FreeBSD.org

If you prime your DNS cache with manual queries, then freebsd-update
will sometimes find the hosts and will report that it found some hosts.

But, I just tried to reproduce this and failed, the problem persists.

So, yes, it looks like a real issue.

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: libopie problems after upgrade to 10.2

2015-08-16 Thread Jan Henrik Sylvester
On 08/15/2015 20:47, Chris Anderson wrote:
 just upgraded from 10.1-RELEASE-p16 to 10.2-RELEASE using freebsd-update.
 
 after the upgrade, I began getting errors because pam_opie.so.5 has an
 unsatisfied link to libopie.so.7 (my system only has libopie.so.8).
 
 I notice a fresh install of 10.2-RELEASE does indeed contain libopie.so.7,
 so I'm curious how I managed to get into this state in the first place and
 whether it is anything I should worry about. This machine has only been
 upgraded using freebsd-update and I'm pretty sure it started from
 10.0-RELEASE.

I did the same update using freebsd-update and I do not have
libopie.so.8 that should not be in any 10.X-RELEASE.

libopie.so.8 was in stable/10 shortly after 10.0-RELEASE, but was set
back again to libopie.so.7 between 10.1-RC1 and 10.1-RELEASE:

https://svnweb.freebsd.org/base/releng/10.1/lib/libopie/Makefile?view=logpathrev=273169

Your problem was probably not introduced during the 10.1-RELEASE to
10.2-RELEASE upgrade but earlier.

I have a system that had just about every BETA, RC, and RELEASE starting
from 9.0-RC1 using freebsd-update binary upgrades only, including some
BETA or RC of 10.1 with libopie.so.8... that system has only
libopie.so.7 now as it should have. Maybe you forgot the removing of
old libraries step of freebsd-update install after freebsd-update
upgrade around 10.1-RC3, because you did not expect it on a stable branch?

Cheers,
Jan Henrik
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: 10.2: ntp update breaks DCF77 clock

2015-08-16 Thread Ian Lepore
On Sun, 2015-08-16 at 08:10 +0100, Matthew Seaman wrote:
 On 15/08/2015 16:46, Christian Weisgerber wrote:
  The ntp code is not very transparent, but I think the root cause
  are the ntp/config.h changes that came with the 4.2.8p3 update.  A
  number of previously disabled obscure clock drivers were enabled,
  but crucially CLOCK_RAWDCF was disabled, and this is the PARSE
  subdriver needed to use the popular DCF77 serial receivers.
  
  Frankly, it looks like we used to have a carefully considered
  selection of clock drivers which has been blindly splattered with
  the upstream defaults in the last update.
 
 Hmmm I suggest raising a PR with patches to revert the changes in
 the set of enabled clock drivers (or merge with the current list).  It's
 not going to get you a working DCF77 receiver in a -RELEASE version any
 time soon, I'm afraid, as you'll have to wait until the next release for
 the changes to percolate down, but having a sensible list of enabled
 clock drivers in base is definitely a good move.
 

I wonder: is there a reason to not enable all (or most of) the refclocks
in base and in ports?  Well, at least all the ones that build on
freebsd... a disturbing number of them fail to compile because they
include linux-specific header files.  Hmm, I just noticed that we
actually compile most of the refclocks, but we don't enable them in the
config.

It looks like the cost of enabling all the refclocks that compile
properly is pretty small... doing so increased the size of ntpd from
745K to 801K for me.  I'll attach the diff just to save someone else the
trouble of iteratively figuring out which ones won't build, but I think
there may be a more-proper way to generate this config by tweaking the
autotools stuff.

-- Ian

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


Re: libopie problems after upgrade to 10.2

2015-08-16 Thread Jan Henrik Sylvester
On 08/16/2015 19:47, Kimmo Paasiala wrote:
 On Sun, Aug 16, 2015 at 8:40 PM, Jan Henrik Sylvester m...@janh.de wrote:
 On 08/15/2015 20:47, Chris Anderson wrote:
 just upgraded from 10.1-RELEASE-p16 to 10.2-RELEASE using freebsd-update.

 after the upgrade, I began getting errors because pam_opie.so.5 has an
 unsatisfied link to libopie.so.7 (my system only has libopie.so.8).

 I notice a fresh install of 10.2-RELEASE does indeed contain libopie.so.7,
 so I'm curious how I managed to get into this state in the first place and
 whether it is anything I should worry about. This machine has only been
 upgraded using freebsd-update and I'm pretty sure it started from
 10.0-RELEASE.

 I did the same update using freebsd-update and I do not have
 libopie.so.8 that should not be in any 10.X-RELEASE.

 libopie.so.8 was in stable/10 shortly after 10.0-RELEASE, but was set
 back again to libopie.so.7 between 10.1-RC1 and 10.1-RELEASE:

 https://svnweb.freebsd.org/base/releng/10.1/lib/libopie/Makefile?view=logpathrev=273169

 Your problem was probably not introduced during the 10.1-RELEASE to
 10.2-RELEASE upgrade but earlier.

 I have a system that had just about every BETA, RC, and RELEASE starting
 from 9.0-RC1 using freebsd-update binary upgrades only, including some
 BETA or RC of 10.1 with libopie.so.8... that system has only
 libopie.so.7 now as it should have. Maybe you forgot the removing of
 old libraries step of freebsd-update install after freebsd-update
 upgrade around 10.1-RC3, because you did not expect it on a stable branch?

 Cheers,
 Jan Henrik
 
 
 As far as I know freebsd-update(8) should handle the obsolete files
 automatically, it's only when you're building from source you have to
 remember to do 'make delete-old delete-old-libs'. If freebsd-update(8)
 fails to delete the obsolete files it's a flaw in it that should be
 reported with a PR.

In general, you need 3 runs of freebsd-update install, one for
installing the kernel, one for installing the userland, and one for
removing obsolete shared libraries (see install_files in
freebsd-update). Of course, the third run is usually not needed during
minor version upgrades, but it was needed between 10.1-RC2 and 10.1-RC3.
Although you get a message about the necessary third run, you may forget
about it anyhow. That was my speculation. Rethinking the problem, that
is probably not it, since both libopie.so.7 and libopie.so.8 would be
present in that case.

Cheers,
Jan Henrik
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: freebsd-update to 10.2-RELEASE broken ?

2015-08-16 Thread Bob Bishop
Hi,

 On 16 Aug 2015, at 18:16, Christian Kratzer ck-li...@cksoft.de wrote:
 
 Hi,
 
 I have been trying to update several of my FreeBSD 10.1 amd64 VM to 
 10.2-RELEASE with freebsd-update and have been failing with an incorrect hash 
 error.
 
 This is what happens with a plain vanilla 10.1-RELEASE vm when I try to 
 update to 10.2-RELEASE
 
 --snipp—
[…]
 Applying patches... done.
 Fetching 2356 files... 
 068eb594e5f6b97554750a8321892e4c229a6f26455f40e4d8e4e7a79577c673 has 
 incorrect hash.
 root@test10:~ck #
 --snipp--
 
 I get the is on all kinds of VM with different patchlevels of 10.1-RELEASE.  
 Some of them have /usr/src, some of them don't.
 
 The hash seems to be different every time round.
 
 Could this be an issue with one of the mirrors ?
 
 Has anybody had success yet with an update to 10.2-RELEASE using 
 freebsd-update ?

FWIW I had the same issue yesterday on a couple of systems. Repeating 
freebsd-update worked after two or three goes.

 Greetings
 Christian
 
 -- 
 Christian Kratzer   CK Software GmbH
 Email:   c...@cksoft.de   Wildberger Weg 24/2
 Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
 Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
 Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
 Web: http://www.cksoft.de/
 ___
 freebsd-stable@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
 

--
Bob Bishop
r...@gid.co.uk




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

Re: libopie problems after upgrade to 10.2

2015-08-16 Thread Kimmo Paasiala
On Sun, Aug 16, 2015 at 8:40 PM, Jan Henrik Sylvester m...@janh.de wrote:
 On 08/15/2015 20:47, Chris Anderson wrote:
 just upgraded from 10.1-RELEASE-p16 to 10.2-RELEASE using freebsd-update.

 after the upgrade, I began getting errors because pam_opie.so.5 has an
 unsatisfied link to libopie.so.7 (my system only has libopie.so.8).

 I notice a fresh install of 10.2-RELEASE does indeed contain libopie.so.7,
 so I'm curious how I managed to get into this state in the first place and
 whether it is anything I should worry about. This machine has only been
 upgraded using freebsd-update and I'm pretty sure it started from
 10.0-RELEASE.

 I did the same update using freebsd-update and I do not have
 libopie.so.8 that should not be in any 10.X-RELEASE.

 libopie.so.8 was in stable/10 shortly after 10.0-RELEASE, but was set
 back again to libopie.so.7 between 10.1-RC1 and 10.1-RELEASE:

 https://svnweb.freebsd.org/base/releng/10.1/lib/libopie/Makefile?view=logpathrev=273169

 Your problem was probably not introduced during the 10.1-RELEASE to
 10.2-RELEASE upgrade but earlier.

 I have a system that had just about every BETA, RC, and RELEASE starting
 from 9.0-RC1 using freebsd-update binary upgrades only, including some
 BETA or RC of 10.1 with libopie.so.8... that system has only
 libopie.so.7 now as it should have. Maybe you forgot the removing of
 old libraries step of freebsd-update install after freebsd-update
 upgrade around 10.1-RC3, because you did not expect it on a stable branch?

 Cheers,
 Jan Henrik


As far as I know freebsd-update(8) should handle the obsolete files
automatically, it's only when you're building from source you have to
remember to do 'make delete-old delete-old-libs'. If freebsd-update(8)
fails to delete the obsolete files it's a flaw in it that should be
reported with a PR.

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


Re: 10.2: ntp update breaks DCF77 clock

2015-08-16 Thread Florian Ermisch


Am 16. August 2015 09:10:41 MESZ, schrieb Matthew Seaman matt...@freebsd.org:
On 15/08/2015 16:46, Christian Weisgerber wrote:
 The ntp code is not very transparent, but I think the root cause
 are the ntp/config.h changes that came with the 4.2.8p3 update.  A
 number of previously disabled obscure clock drivers were enabled,
 but crucially CLOCK_RAWDCF was disabled, and this is the PARSE
 subdriver needed to use the popular DCF77 serial receivers.
 […]

[…]
For a more timely solution[*], it looks like the ports is your best
option.  By default the net/ntp port disables all of the clock drivers,
but allows you to configure the port to enable whatever drivers you
want.
[…]

You could also check the PCBSD/TrueOS
pkg repos. I Kris Moore mentioned on
BSDnow he'll happily enable/change build
options when people need them.

When ntpd is the only pkg you'll install
anyway this might be the most hassle 
free option.

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

Re: 10.2: ntp update breaks DCF77 clock

2015-08-16 Thread Christian Weisgerber
On 2015-08-16, Matthew Seaman matt...@freebsd.org wrote:

 Hmmm I suggest raising a PR with patches to revert the changes in
 the set of enabled clock drivers (or merge with the current list).  It's

Yes.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202362

 not going to get you a working DCF77 receiver in a -RELEASE version any
 time soon, I'm afraid, as you'll have to wait until the next release for
 the changes to percolate down,

I finally had an occasion to try freebsd-update rollback and went
back to 10.1.

-- 
Christian naddy Weisgerber  na...@mips.inka.de
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: freebsd-update to 10.2-RELEASE broken ?

2015-08-16 Thread Christian Kratzer

Hi,

On Sun, 16 Aug 2015, Kimmo Paasiala wrote:

It could be the classic fall back to TCP on SRV records problem on
your upstream DNS forwarder if you're using one:

http://lists.freebsd.org/pipermail/freebsd-ports/2012-May/074801.html

The cure would be to use your own caching DNS resolver (configured to
query the authoritative name servers directly) such as dns/unbound.


I run my own bind9 resolvers on freebsd 10 at both sites.   I never
particurlarly like the concept of an upstream resolver.

All my resolvers are behind firewalls although different kinds.
ASA at one site and freebsd pf at the other.

I will investigate though.  Thanks for the tip.

Greetings
Christian

--
Christian Kratzer   CK Software GmbH
Email:   c...@cksoft.de   Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: freebsd-update to 10.2-RELEASE broken ?

2015-08-16 Thread Bjoern A. Zeeb

 On 16 Aug 2015, at 21:16 , Christian Kratzer ck-li...@cksoft.de wrote:
 
 Hi,
 
 On Sun, 16 Aug 2015, Kurt Jaeger wrote:
 Hi!
 
 It could be the classic fall back to TCP on SRV records problem on
 your upstream DNS forwarder if you're using one:
 
 http://lists.freebsd.org/pipermail/freebsd-ports/2012-May/074801.html
 
 If I query that same DNS resolver using the line from
 the script, it works every time. It's a 10.1p16 host with
 a very recent ports build, and directly connected (no NAT, no
 fw etc).
 
 If that would be the problem, how could I diagnose it in depth ?
 
 freebsd-update upgrade just failed on 3 other vm even when I explicitly
 specified the server using freebsd-update -s.
 
 I had success on another vm when I changed to using google dns.
 
 I am not aware that anything would be blocking tcp dns in my setups.
 
 Must be something else dns related.
 
 Perhaps I will run a local resolver in a vm and logg all queries and dns
 traffic.

Or run tcpdump for port 53;   also curious if it might be an IPv4 vs. IPv6 
issue?


— 
Bjoern A. Zeeb  Charles Haddon Spurgeon:
Friendship is one of the sweetest joys of life.  Many might have failed
 beneath the bitterness of their trial  had they not found a friend.

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

Re: help me understand latest-quarterly pkg.conf switch

2015-08-16 Thread Alnis Morics

On 07/25/2015 05:04 AM, Glen Barber wrote:

On Fri, Jul 24, 2015 at 09:23:12PM -0400, Nikolai Lifanov wrote:

On 2015-07-24 17:27, Glen Barber wrote:

On Fri, Jul 24, 2015 at 05:15:52PM -0400, Nikolai Lifanov wrote:

I noticed that in stable/10, /etc/pkg/FreeBSD.conf was switched from
using
latest package set to whichever one that is quarterly word is pointing
to
at the moment. What is the motivation for this change?


This was not done in the stable/10 branch, it was done in releng/10.2.


Quarterly package sets are useful if the end-user is able to pick which
one
to pull from and there is some amount of time of support overlap so that
the
user has time to validate the new package set and switch his systems to
it
(like what is done with pkgsrc). As-is, quarterly works just like
latest

from end-user perspective, but for most of the lifecycle packages are

outdated and there is a massive update bomb four times per year.

Port branches are still valuable to those building their own packages,
since
they can support the previous (unsupported by the project) branch,
backporting fixes manually, while validating and upgrading to the new
one.
But, what is the value of the quarterly package set as-is and what is
the
value of switching to this set by default?


In general, the quarterly package set is less prone to having build
failures, since the changes in the branch are (by intent) less
intrusive, while still receiving security updates.  It is analogous to
the stable or releng branches in src, and how they compare to head.

(This will be noted in the final 10.2-RELEASE announcement, as well as
the release notes, and will also include instructions on how to switch
to the 'latest' branch if that is what is desired.)

Glen

Cool, thanks for the explanation!


You're welcome.  (The 'quarterly' branch is admittedly under-documented,
which is a problem.)


What would be really amazing to see are quarterly branches that the end user
can switch between, like pkg.freebsd.org/${ABI}/2015Q3 -
pkg.freebsd.org/${ABI}/2015Q4 when he is ready, with at least a little bit
of overlap.


I agree this would be a nice to see feature, but as I have insight
into how the pkg(8) mirrors operate, this is an unfortunately
non-trivial thing to implement.

Glen

Does this mean that quarterly pkg are synchronous with ports quarterly 
branches? Say, at the moment, packages that we install with the default 
(quarterly) setting in /etc/pkg/FreeBSD.conf, are built from the 
2015Q3 branch?


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


Re: freebsd-update to 10.2-RELEASE broken ?

2015-08-16 Thread Christian Kratzer

Hi,

On Sun, 16 Aug 2015, Kurt Jaeger wrote:
snipp/

We assumed that I have a DNS problem because of this line:


Looking up update.FreeBSD.org mirrors... none found.


This happens with this query inside the freebsd-update script, at
line 950:

host -t srv _http._tcp.update.FreeBSD.org

If you prime your DNS cache with manual queries, then freebsd-update
will sometimes find the hosts and will report that it found some hosts.

But, I just tried to reproduce this and failed, the problem persists.

So, yes, it looks like a real issue.


hmmm. Thanks for pointing me at the dns issue.

I actually did not see that message as it seems to only appear on
subsequent rounds of running freebsd-update.  I always deleted
/var/db/freebsd-update and thus always started clean.

I was able to complete the freebsd-update upgrade when I manually
specified on of the mirrors as in:

freebsd-update -s update2.freebsd.org -r 10.2-RELEASE upgrade

So this does seem to be a dns related issue.  It could also be the
related to parsing the results of the dns lookup.

Anyway seems we have a workaround if we specify the mirrors manually.

Greetings
Christian

--
Christian Kratzer   CK Software GmbH
Email:   c...@cksoft.de   Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: freebsd-update to 10.2-RELEASE broken ?

2015-08-16 Thread Kimmo Paasiala
On Sun, Aug 16, 2015 at 10:07 PM, Christian Kratzer ck-li...@cksoft.de wrote:
 Hi,

 On Sun, 16 Aug 2015, Kurt Jaeger wrote:
 snipp/

 We assumed that I have a DNS problem because of this line:

 Looking up update.FreeBSD.org mirrors... none found.


 This happens with this query inside the freebsd-update script, at
 line 950:

 host -t srv _http._tcp.update.FreeBSD.org

 If you prime your DNS cache with manual queries, then freebsd-update
 will sometimes find the hosts and will report that it found some hosts.

 But, I just tried to reproduce this and failed, the problem persists.

 So, yes, it looks like a real issue.


 hmmm. Thanks for pointing me at the dns issue.

 I actually did not see that message as it seems to only appear on
 subsequent rounds of running freebsd-update.  I always deleted
 /var/db/freebsd-update and thus always started clean.

 I was able to complete the freebsd-update upgrade when I manually
 specified on of the mirrors as in:

 freebsd-update -s update2.freebsd.org -r 10.2-RELEASE upgrade

 So this does seem to be a dns related issue.  It could also be the
 related to parsing the results of the dns lookup.

 Anyway seems we have a workaround if we specify the mirrors manually.

 Greetings
 Christian

 --



It could be the classic fall back to TCP on SRV records problem on
your upstream DNS forwarder if you're using one:

http://lists.freebsd.org/pipermail/freebsd-ports/2012-May/074801.html

The cure would be to use your own caching DNS resolver (configured to
query the authoritative name servers directly) such as dns/unbound.

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


Re: freebsd-update to 10.2-RELEASE broken ?

2015-08-16 Thread Kurt Jaeger
Hi!

 It could be the classic fall back to TCP on SRV records problem on
 your upstream DNS forwarder if you're using one:
 
 http://lists.freebsd.org/pipermail/freebsd-ports/2012-May/074801.html

If I query that same DNS resolver using the line from
the script, it works every time. It's a 10.1p16 host with
a very recent ports build, and directly connected (no NAT, no
fw etc).

If that would be the problem, how could I diagnose it in depth ?

-- 
p...@opsec.eu+49 171 3101372 5 years to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: freebsd-update to 10.2-RELEASE broken ?

2015-08-16 Thread Christian Kratzer

Hi,

On Sun, 16 Aug 2015, Kurt Jaeger wrote:

Hi!


It could be the classic fall back to TCP on SRV records problem on
your upstream DNS forwarder if you're using one:

http://lists.freebsd.org/pipermail/freebsd-ports/2012-May/074801.html


If I query that same DNS resolver using the line from
the script, it works every time. It's a 10.1p16 host with
a very recent ports build, and directly connected (no NAT, no
fw etc).

If that would be the problem, how could I diagnose it in depth ?


freebsd-update upgrade just failed on 3 other vm even when I explicitly
specified the server using freebsd-update -s.

I had success on another vm when I changed to using google dns.

I am not aware that anything would be blocking tcp dns in my setups.

Must be something else dns related.

Perhaps I will run a local resolver in a vm and logg all queries and dns
traffic.

Greetings
Christian

--
Christian Kratzer   CK Software GmbH
Email:   c...@cksoft.de   Wildberger Weg 24/2
Phone:   +49 7032 893 997 - 0   D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9   HRB 245288, Amtsgericht Stuttgart
Mobile:  +49 171 1947 843   Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: 10.2: ntp update breaks DCF77 clock

2015-08-16 Thread Cy Schubert
In message 1439744220.242.87.ca...@freebsd.org, Ian Lepore writes:
 
 
 --=-yOSDvPzQIQnw2oRARoLp
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 On Sun, 2015-08-16 at 08:10 +0100, Matthew Seaman wrote:
  On 15/08/2015 16:46, Christian Weisgerber wrote:
   The ntp code is not very transparent, but I think the root cause
   are the ntp/config.h changes that came with the 4.2.8p3 update.  A
   number of previously disabled obscure clock drivers were enabled,
   but crucially CLOCK_RAWDCF was disabled, and this is the PARSE
   subdriver needed to use the popular DCF77 serial receivers.
   
   Frankly, it looks like we used to have a carefully considered
   selection of clock drivers which has been blindly splattered with
   the upstream defaults in the last update.
  
  Hmmm I suggest raising a PR with patches to revert the changes in
  the set of enabled clock drivers (or merge with the current list).  It's
  not going to get you a working DCF77 receiver in a -RELEASE version any
  time soon, I'm afraid, as you'll have to wait until the next release for
  the changes to percolate down, but having a sensible list of enabled
  clock drivers in base is definitely a good move.
  
 
 I wonder: is there a reason to not enable all (or most of) the refclocks
 in base and in ports?  Well, at least all the ones that build on
 freebsd... a disturbing number of them fail to compile because they
 include linux-specific header files.  Hmm, I just noticed that we
 actually compile most of the refclocks, but we don't enable them in the
 config.

The reason not to include all drivers is fourfold.

1. Support of all drivers does increase the risk out-of-the-box breakage 
and security exposure. Not often used drivers may contain additional 
security exposures.

2. IMO, a client-only configuration should be supported. I've been told via 
email (which I was cc'd) exchanged between a person on the project and our 
NTP upline (at ntp.org) that a timekeeping client able of understanding 
multiple protocols (e.g. PTP) is in the works and will someday (soon?) 
replace ntp in base. Avoiding too much function creep may avoid POLA when 
that occurs.

3. Some drivers may interfere with each other. This is why ntp as 
distributed by our upline does not turn them all on, and which is why the 
port allows a user to install them as required. I've heard of occasional 
conflicts over the years. Turning them all on could be a risk for the 
project, as in someone may have to needlessly fix something that has not 
been tested or supported by our upline. With the port OTOH, it's easy to 
tell a user to turn off whatever they don't need.

4. Also IMO, that's what the port is for. If a person wants to use ntp as a 
server, e.g. to serve time to other computers, i.e. not simply use ntp as a 
consumer, then the port is always available. (Also juxtapositioned to this 
point, the port is updated before base because testing and commit [commit 
to vendor branch, MFV, build tinderbox, run for a while, MFC] is much 
simpler with the port than in base.)

As to why, historically, not all drivers have been built and installed is 
something I cannot answer, though I hazard to guess it may be due to one or 
more of the above.

IMO I'd prefer to keep ntp minimal within base and direct people who want 
more to one of the ports. (The ports collection has a -rc incarnation when 
release candidates are available.)

 
 It looks like the cost of enabling all the refclocks that compile
 properly is pretty small... doing so increased the size of ntpd from
 745K to 801K for me.  I'll attach the diff just to save someone else the
 trouble of iteratively figuring out which ones won't build, but I think
 there may be a more-proper way to generate this config by tweaking the
 autotools stuff.

Size of the binary is not an issue.

I'll be working on generating config.h. The issue here is that config.h is 
different for each supported FreeBSD platform (32bit, 64bit, little and big 
endian, etc.). The plan is to make config the port on each supported 
platform using qemu-sbruno and steal ^W borrow the config.h and import into 
base, using a master config.h (actually called config.h) to include via 
#ifdef definitions the appropriate config.h.PLATFORM_NAME. Qemu (and 
qemu-sbruno) doesn't support all our supported platforms, especially the 
multitude of ARM platforms, so holes in our auto-generated config.h support 
will exist.

Thanks for the diff. I think the place to start is to enable them in a 
(new) dependent port (ntp-all and ntp-devel-all for the lack of better 
names) and see what fallout comes from it.


-- 
Cheers,
Cy Schubert cy.schub...@komquats.com or cy.schub...@cschubert.com
FreeBSD UNIX:  c...@freebsd.org   Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
freebsd-stable@freebsd.org mailing list