Re: sed command does not behave equal from 10.3 to 11.0

[Kimmo Paasiala]

On Wed, Jul 27, 2016 at 2:55 PM, Tomoaki AOKI  wrote:
> Hi.
>
> There were some collation related changes (*1) between 10.3 and 11.
> So the results can be changed even with the same locale.
>
> *1: For example, r302512.
>   https://lists.freebsd.org/pipermail/svn-src-head/2016-July/088919.html
>
> But I cannot understand why ASCII range of characters are affected with
> UTF-8 encoding.
>
>
> On Wed, 27 Jul 2016 11:19:06 +0200
> Jos〓 Garc〓a Juanino  wrote:
>
>> On 27 July 2016 at 11:01, Matthew D. Fuller  wrote:
>> > On Wed, Jul 27, 2016 at 09:45:23AM +0100 I heard the voice of
>> > krad, and lo! it spake thus:
>> >> are you sure you aren't hitting a port or something?
>> >
>> > Locale dependant.
>> >
>> > % echo "abc_ABC.def" | env LANG=C sed -e 's/[^A-Z0-9]//g'
>> > ABC
>> >
>> > % echo "abc_ABC.def" | env LANG=en_US.UTF-8 sed -e 's/[^A-Z0-9]//g'
>> > bcABCdef
>> >
>> > (pre-branch -CURRENT)
>> >
>>
>> The issue is that, under the same locale, the output is not the same
>> in 10.3 as 11.0. It sounds to me a bug ...
>> ___
>> 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"
>>
>
>
> --
> Tomoaki AOKIjunch...@dec.sakura.ne.jp
> ___

If I change the invocation to this I get the correct output:

% echo "abc_ABC.def" | env LANG=en_US.UTF-8 sed -e 's/[^ABC]//g'

Is the real problem that the UTF-8 locale messes up character ranges
(e.g. A-Z) in sed(1)?

-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: new certificate for svn.freebsd.org?

[Kimmo Paasiala]

On Sat, Jun 18, 2016 at 12:55 PM, Wolfgang Zenker
 wrote:
> * Matthew Seaman  [160618 11:21]:
>> On 18/06/2016 05:40, Ben Steel via freebsd-stable wrote:
>>> It's not just you, Wolfgang. See bug 210332 at bugs.freebsd.org.
>>> The new certificate is in place on the 4 mirrors that I found (US East,
>>> US West, UK, Russia) but didn't verify cleanly and wasn't in the
>>> documentation.
>
>>> For me, the fix was in Dimitry's mail, a step I probably missed when
>>> installing security/ca_root_nss:
>
>>> sudo ln -s /usr/local/share/certs/ca-root-nss.crt /etc/ssl/cert.pem
>
>> There's an option in the ca_root_nss port to create the symlink, which
>> is enabled by default.  That option only exists because the ports are
>> not supposed to touch anything outside /usr/local -- except that for
>> this port, not creating the symlink for /etc/ssl/cert.pm pretty much
>> renders the whole port pointless.
>
>> Even so, the option used to be off by default: the change to 'on by
>> default' was made almost exactly a year ago, and there have been several
>> changes to the list of certs since, so not having the symlink in place
>> indicates either that you haven't updated your ports recently, or that
>> you've specifically chosen not to enable the symlink.  In which case you
>> wouldn't have been able to validate the previous cert either.
>
> I first installed the port a couple of years ago and updated regularly,
> but of course the options value of not installing the symlink, which
> I then accepted as default, had been saved and was automatically used
> in every update since. I could not validate the previous cert either,
> but could check the hash against the published version.
>
> Now using "make rmconfig" and reinstalling the port fixed it for me.
>
> Maybe we should consider bringing the config dialog up again in
> ports where default values are changed?
>
> Wolfgang

That would probably require some reworking of the saved options. Now
there is no information saved if an option is at its default setting
or differs from the default. Without that information evaluating all
options to detect changed defaults for a large set of ports would be
very slow.

-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: new certificate for svn.freebsd.org?

[Kimmo Paasiala]

On Sat, Jun 18, 2016 at 7:40 AM, Ben Steel via freebsd-stable
 wrote:
> It's not just you, Wolfgang. See bug 210332 at bugs.freebsd.org.
> The new certificate is in place on the 4 mirrors that I found (US East, US
> West, UK, Russia) but didn't verify cleanly and wasn't in the documentation.
>
> For me, the fix was in Dimitry's mail, a step I probably missed when
> installing security/ca_root_nss:
>
> sudo ln -s /usr/local/share/certs/ca-root-nss.crt /etc/ssl/cert.pem
>
> Hope this helps,
>
> Ben
>

You might have saved options for security/ca_root_nss which tell the
port not to install the symlink. The ETCSYMLINK option has been on by
default for quite a long time. Delete the saved options or change them
to have the port control the symlink.

-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: libopie problems after upgrade to 10.2

[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: freebsd-update to 10.2-RELEASE broken ?

[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: 8-stable crashing recently in ufsdirhash

[Kimmo Paasiala]

On Wed, Aug 5, 2015 at 2:24 PM, parv p...@bitter-almonds.com wrote:
 On August 5, 2015 12:55:28 AM HST, Ian  wrote:
On Wed, 5 Aug 2015 00:33:16 -1000, parv wrote:
  On August 4, 2015 11:54:16 PM HST, parv wrote:
  
 Please CC me as I cannot properly use my laptop, Thinkpad X200
(i386).
  
 8-stable has been crashing a lot since source update of Jul 2015[0].
  ...
 
  Another crash on umount ...
 
  http://imagebin.ca/v/2B5CKNCOojPW

My X200 runs really nicely on 9.3 amd64, and 10.x almost certainly.

Just sayin' .. I wouldn't bother chasing an expired branch, or i386,
when you can run amd64 with - frankly - more enthusiastic support.

 Well, I don't see a way to upgrade while FreeBSD 8 is crashing on file system 
 operations (mktemp, rm, umount, mount after boot, vi, ed, etc).

 As for amd64 version, my 'puter is really i386.


 --


As a first aid you should boot into single user mode and run fsck(8)
on your filesystem(s) in case there's some corruption going on.

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

Re: Upgrade SRC built i386 8.4 to 10.1 questions

[Kimmo Paasiala]

On Tue, Aug 4, 2015 at 4:22 PM, Pete French petefre...@ingresso.co.uk wrote:
 1. can I use freebsd-update to migrate to 10.1 i386

 not qualified to comment on this, to go from 8 to 10 I
 wuld recommend going via 9, as I am not sure it can be done in
 one step.

 2. can I use freebsd-update to migrate to 10.1 amd64
 3. can I use source buildkernel + buildworld to migrate i386 8.4 to amd64 
 10.1

 here you want to move from a 32 bit install to a 64 bit install. I have
 done this using the buildkernel + buoldworld process, but I had to
 use a second instagllation. Basically I upgraded to the latest version on
 the 32 bit platform, then installed a USB stick with the 64 bit platform, and
 upgraded that to exactly the same version. Then I booted from the
 USB stick and did an installworld  installkernel with the destination
 set to the hard discv with the 32 bit installation on it.

 That actually worked fine, it was on FreeBSD 8 I belive, I havent tried it
 recently, but it did shift the machine from 32 bit to 64 bit smoothly.
 Obviously you should not have any poirts installed whilst ding this, as they
 will need to be reinstalled for the new architecture.

 -pete.

I've done a similar operation:

https://forums.freebsd.org/threads/migrating-an-i386-installation-to-amd64-without-reinstall.50495/

Remember to run mergemaster(8) with the correct options for the target
platform (amd64) or you'll install some wrong configuration files.

HTH,

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

Re: FreeBSD 10.1_RELEASE to FreeBSD 10.2 BETA2

[Kimmo Paasiala]

On Sat, Jul 25, 2015 at 1:27 PM, Stari Karp starik...@yandex.com wrote:
 On Fri, 2015-07-24 at 16:17 -0400, Stari Karp wrote:

  
1. VT module doesn't load.
  In /boot/loader.conf I have:
  kern.vty=vt
but it doesn't work. If I manual loada module witk kldload radeonkms I
got just black screen and nothing more.
  

 I saved the problem. The BETA2 make some  and ** in
 device.hints and it was error to reading them. I didn't saw before.
 Today I also update to RC1 and works good.

 Thank you for the help.

 --
 ajtiM
 -
 http://www.redbubble.com/people/lumiwa
 https://www.facebook.com/pages/Lumiwa-FARM/775292915882930?_fb_noscript=1



That's freebsd-update(8)'s doing if you skip the merge questions too
hastily. Take note about them next time and make sure the merges are
done correctly, otherwise you'll end up with messed up configuration
files.

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

Re: Freebsd-version problem

[Kimmo Paasiala]

On Thu, Jul 2, 2015 at 2:41 PM, Dag-Erling Smørgrav d...@des.no wrote:
 Kimmo Paasiala kpaas...@gmail.com writes:
 Marko Turk mark...@markoturk.info writes:
  after today update to r284993, my /bin/freebsd-version is wrong. It
  contains both freebsd-version script and newvers.sh [...]
 Looks like this commit broke it:

 https://svnweb.freebsd.org/base?view=revisionsortby=revsortdir=downrevision=284957

 My apologies.  I should have merged r277531 as well.

 DES
 --
 Dag-Erling Smørgrav - d...@des.no

Confirmed, freebsd-version(1) works again after r285027. Thanks!

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

Re: Freebsd-version problem

[Kimmo Paasiala]

On Wed, Jul 1, 2015 at 8:55 PM, Marko Turk mark...@markoturk.info wrote:
 Hi,

 after today update to r284993, my /bin/freebsd-version is wrong. It
 contains both freebsd-version script and newvers.sh as if someone
 concatenated these two files into /bin/freebsd-version.

 Can anyone confirm or is it just me?

 BR,
 Marko


Looks like this commit broke it:

https://svnweb.freebsd.org/base?view=revisionsortby=revsortdir=downrevision=284957

I think the problem is that ${.ALLSRC} expands now to both
${.CURDIR}/freebsd-version.sh.in and ${NEWVERS} where ${NEWVERS} is
the newvers.sh from sys/conf/.

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

Re: Bug 201072

[Kimmo Paasiala]

On Tue, Jun 30, 2015 at 8:02 PM, Kubilay Kocak ko...@freebsd.org wrote:
 On 29/06/2015 8:18 PM, Kimmo Paasiala wrote:
 It looks like the atf directories were removed from /etc/mtree/* in:

 https://svnweb.freebsd.org/base?view=revisionrevision=260024

 They were later put back in this commit:

 https://svnweb.freebsd.org/base?view=revisionrevision=277457

 My patch is not valid apparently because it would break the tests
 stuff again, I had no idea how complex the issue was...

 Hi Kimmo, thanks for the report :)

 Please add your comment to the issue, I have triaged it and cc'd our
 testing gurus who can hopefully help

 ./koobs

Done.

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

Re: Bug 201072

[Kimmo Paasiala]

On Sun, Jun 28, 2015 at 5:50 AM, Alan Somers asom...@freebsd.org wrote:
 I'm on vacation now.  But if nobody else helps you, ping me again on
 8-July-2015 and I'll test and merge the patch.  One question, have you
 checked whether the issue exists on CURRENT?

 Thanks for your contribution.

 On Sat, Jun 27, 2015 at 4:15 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 Hello,

 Could someone take a look at
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201072 ?

 The patch I've created fixes an issue on stable/10 with various atf
 directories that are still created by /etc/mtree/* database but are
 then deleted by 'make delete-old' later. The directories are clearly
 redundant because the WITH/WITHOUT_ATF flags were removed in
 https://svnweb.freebsd.org/base?view=revisionsortby=revsortdir=downrevision=r261236.

 -Kimmo



It looks like the atf directories were removed from /etc/mtree/* in:

https://svnweb.freebsd.org/base?view=revisionrevision=260024

They were later put back in this commit:

https://svnweb.freebsd.org/base?view=revisionrevision=277457

My patch is not valid apparently because it would break the tests
stuff again, I had no idea how complex the issue was...

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

Bug 201072

[Kimmo Paasiala]

Hello,

Could someone take a look at
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201072 ?

The patch I've created fixes an issue on stable/10 with various atf
directories that are still created by /etc/mtree/* database but are
then deleted by 'make delete-old' later. The directories are clearly
redundant because the WITH/WITHOUT_ATF flags were removed in
https://svnweb.freebsd.org/base?view=revisionsortby=revsortdir=downrevision=r261236.

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

Re: building -stable after FreeBSD-SA-15:10.openssl

[Kimmo Paasiala]

On Wed, Jun 17, 2015 at 9:14 PM, jungle Boogie jungleboog...@gmail.com wrote:
 Hello All,

 Trying to upgrade from r283863 to 284520 after I applied this patch:
 https://www.freebsd.org/security/advisories/FreeBSD-SA-15:10.openssl.asc

 In the manner described:

 # fetch https://security.FreeBSD.org/patches/SA-15:10/openssl-10.1.patch
 # cd /usr/src
 # patch  /path/to/patch


 I begin the build by doing:
 cd /usr/src
 svn update
 make -j `sysctl -n hw.ncpu` buildworld  -DNO_CLEAN

 But then this happened:

 Removing stale symlinks.
 rm -f /usr/obj/usr/src/tmp/usr/include/des.h
 rm -f /usr/obj/usr/src/tmp/usr/lib/libdes.a
 rm -f /usr/obj/usr/src/tmp/usr/lib/libdes.so
 rm -f /usr/obj/usr/src/tmp/usr/lib/libdes.so.3
 rm -f /usr/obj/usr/src/tmp/usr/lib/libdes_p.a
 === lib/libldns (obj,depend,all,install)
 sh /usr/src/tools/install.sh -C -o root -g wheel -m 444   libldns.a
 /usr/obj/usr/src/tmp/usr/lib/private
 sh /usr/src/tools/install.sh -s -o root -g wheel -m 444
 libldns.so.5 /usr/obj/usr/src/tmp/usr/lib/private
 sh /usr/src/tools/install.sh -l s libldns.so.5
 /usr/obj/usr/src/tmp/usr/lib/private/libldns.so
 === secure/lib/libssl (obj,depend,all,install)
 cc  -fpic -DPIC  -O2 -pipe   -DTERMIOS -DANSI_SOURCE
 -I/usr/src/secure/lib/libssl/../../../crypto/openssl
 -I/usr/src/secure/lib/libssl/../../../crypto/openssl/crypto
 -I/usr/obj/usr/src/secure/lib/libssl -DOPENSSL_THREADS -DDSO_DLFCN
 -DH$
 /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:3371:9:
 error: redefinition of 'al'
 int al = SSL_AD_HANDSHAKE_FAILURE;
 ^
 /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_clnt.c:3276:9:
 note: previous definition is here
 int al = SSL_AD_HANDSHAKE_FAILURE;
 ^
 1 error generated.
 *** [s3_clnt.So] Error code 1

 make[4]: stopped in /usr/src/secure/lib/libssl
 1 error

 make[4]: stopped in /usr/src/secure/lib/libssl
 A failure has been detected in another branch of the parallel make

 make[3]: stopped in /usr/src
 *** [libraries] Error code 2

 make[2]: stopped in /usr/src
 1 error

 make[2]: stopped in /usr/src
 *** [_libraries] Error code 2

 make[1]: stopped in /usr/src
 1 error

 make[1]: stopped in /usr/src
 *** [buildworld] Error code 2

 make: stopped in /usr/src
 1 error

 make: stopped in /usr/src



 My patch happened to be in /usr/src when I applied it. Is this what
 caused the issue?

 Is there a way to revert the patch?


 Thanks  Best,
 jungle

 --
 ---
 inum: 883510009027723
 sip: jungleboo...@sip2sip.info
 xmpp: jungle-boo...@jit.si


Don't use the patch at all if you're following stable/10, the
necessary security fixes are already included in updates you pull in
from SVN.

You can revert all local changes with 'svnlite revert -R .' in
/usr/src, might take a while for it to finish though.

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

Re: building -stable after FreeBSD-SA-15:10.openssl

[Kimmo Paasiala]

On Wed, Jun 17, 2015 at 9:36 PM, jungle Boogie jungleboog...@gmail.com wrote:
 On 17 June 2015 at 11:23, Kimmo Paasiala kpaas...@gmail.com wrote:
 Don't use the patch at all if you're following stable/10, the
 necessary security fixes are already included in updates you pull in
 from SVN.


 Oh, so in the future, just svn up and rebuild?


Exactly.

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

Re: How to track stable on multiple servers?

[Kimmo Paasiala]

On Mon, Jun 1, 2015 at 4:10 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
 I have some set of FreeBSD servers in public internet and continue to
 find optimal way for track -stable branch.

 Handbook give next metods:

 1. Tracking -security branch by freebsd-update.
I want -stable, -security don't have wanted features.

 2. svn  rebuilding world localy. To long and wery badly automated,
bad version synchronisation between servers.

 3. svn  rebuilding world on build server, install localy by NFS.
Servers in public internet, I am to be  afraid exposing NFS to
public internet. Also, need to have localy /etc/{make,src}.conf in
sync with build server. Also badly automated.

 4. Build private freebsd-update-server and build (simularity to
security btanch) updates for -stable.
Need essentially dedicated server -- during build system time
changed and this is may be raise side effects.
freebsd-update work wery long time (hours) and accumulate a lot of
garbage:

 # du -ms /var/db/freebsd-update/
 2010/var/db/freebsd-update/

freebsd-update-server/freebsd-update too bugly and debuggint is not
easy.
config mergering working worse mergemaster.
Don't allow to repair damaged files (freebsd-update IDS detect
changes but don't repair this).

 5. nanobsd.
Don't automatic save /etc and etc.
pkg updated throw system image update and reboot. Unaccpetable.


 Something else?


When I had to something like this I went with option 3. It's not
completely automated as you say because of /etc/(make|src).conf but
there are no better options at the moment because /usr/obj is not
self contained because its contents and interpretation depends on
auxillary files, the /etc/make.conf and /etc/src.conf files.

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

Re: CPU frequency doesn't drop below 1200MHz (like it used to)

[Kimmo Paasiala]

On Sat, May 23, 2015 at 10:41 PM, Adrian Chadd adr...@freebsd.org wrote:
 Frequency control may not be relevant on that platform.

 Try installing the intel-pcm package; then

 # kldload cpuctl
 # pcm.x 1

 Then paste some of that in here. Let's see if the CPU is idling some other 
 way.



 -adrian

Five iterations one every second:

Script started on Sun May 24 00:07:18 2015
command: sudo pcm.x 1 -i=5

 Intel(r) Performance Counter Monitor V2.8 (2014-12-18 12:52:39 +0100
ID=ba39a89)

 Copyright (c) 2009-2014 Intel Corporation

Number of physical cores: 1
Number of logical cores: 4
Number of online logical cores: 4
Threads (logical cores) per physical core: 4
Num sockets: 1
Physical cores per socket: 1
Core PMU (perfmon) version: 3
Number of core PMU generic (programmable) counters: 2
Width of generic (programmable) counters: 40 bits
Number of core PMU fixed counters: 3
Width of fixed counters: 40 bits
Nominal core frequency: 166000 Hz
Delay: 1

Detected Intel(R) Atom(TM) CPU D510 @ 1.66GHz Intel(r)
microarchitecture codename Atom(tm)

 EXEC  : instructions per nominal CPU cycle
 IPC   : instructions per CPU cycle
 FREQ  : relation to nominal CPU frequency='unhalted clock
ticks'/'invariant timer ticks' (includes Intel Turbo Boost)
 L2MISS: L2 cache misses
 L2HIT : L2 cache hit ratio (0.00-1.00)
 TEMP  : Temperature reading in 1 degree Celsius relative to the TjMax
temperature (thermal headroom): 0 corresponds to the max temperature


 Core (SKT) | EXEC | IPC  | FREQ | L2MISS | L2HIT | TEMP

   00 0.00   0.19   0.00   5513  0.85 89
   10 0.00   0.37   0.00   2676  0.84 89
   20 0.00   0.39   0.01 21 K0.83 N/A
   30 0.00   0.28   0.00   4731  0.64 N/A
-
 TOTAL  * 0.00   0.33   0.00 34 K0.82 N/A

 Instructions retired:  K ; Active cycles:   20 M ; Time (TSC):
1765 Mticks ; C0 (active,non-halted) core residency: 0.28 %

 C1 core residency: 99.72 %;
 C2 package residency: 0.00 %; C4 package residency: 0.00 %; C6
package residency: 0.00 %;

 PHYSICAL CORE IPC : 1.33 = corresponds to 66.42 %
utilization for cores in active state
 Instructions per nominal CPU cycle: 0.00 = corresponds to 0.19 %
core utilization over time interval
--

 EXEC  : instructions per nominal CPU cycle
 IPC   : instructions per CPU cycle
 FREQ  : relation to nominal CPU frequency='unhalted clock
ticks'/'invariant timer ticks' (includes Intel Turbo Boost)
 L2MISS: L2 cache misses
 L2HIT : L2 cache hit ratio (0.00-1.00)
 TEMP  : Temperature reading in 1 degree Celsius relative to the TjMax
temperature (thermal headroom): 0 corresponds to the max temperature


 Core (SKT) | EXEC | IPC  | FREQ | L2MISS | L2HIT | TEMP

   00 0.00   0.19   0.00   6296  0.82 89
   10 0.00   0.35   0.00 12 K0.81 89
   20 0.00   0.44   0.00   6378  0.84 N/A
   30 0.00   0.24   0.00   3846  0.86 N/A
-
 TOTAL  * 0.00   0.34   0.00 29 K0.83 N/A

 Instructions retired: 6646 K ; Active cycles:   19 M ; Time (TSC):
1766 Mticks ; C0 (active,non-halted) core residency: 0.28 %

 C1 core residency: 99.72 %;
 C2 package residency: 0.00 %; C4 package residency: 0.00 %; C6
package residency: 0.00 %;

 PHYSICAL CORE IPC : 1.34 = corresponds to 67.19 %
utilization for cores in active state
 Instructions per nominal CPU cycle: 0.00 = corresponds to 0.19 %
core utilization over time interval
--

 EXEC  : instructions per nominal CPU cycle
 IPC   : instructions per CPU cycle
 FREQ  : relation to nominal CPU frequency='unhalted clock
ticks'/'invariant timer ticks' (includes Intel Turbo Boost)
 L2MISS: L2 cache misses
 L2HIT : L2 cache hit ratio (0.00-1.00)
 TEMP  : Temperature reading in 1 degree Celsius relative to the TjMax
temperature (thermal headroom): 0 corresponds to the max temperature


 Core (SKT) | EXEC | IPC  | FREQ | L2MISS | L2HIT | TEMP

   00 0.00   0.25   0.00 12 K0.74 89
   10 0.00   0.42   0.00   3166  0.94 89
   20 0.00   0.19   0.00   4869  0.68 94
   30 0.00   0.36   0.00 13 K0.81 94
-
 TOTAL  * 0.00   0.34   0.00 33 K0.82 N/A

 Instructions retired: 8041 K ; Active cycles:   23 M ; Time (TSC):
1755 Mticks ; C0 (active,non-halted) core residency: 0.34 %

 C1 core residency: 99.66 %;
 C2 package residency: 0.00 %; C4 package 

Re: CPU frequency doesn't drop below 1200MHz (like it used to)

[Kimmo Paasiala]

On Sat, May 23, 2015 at 10:00 AM, Ian Smith smi...@nimnet.asn.au wrote:
 On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote:
   On Fri, May 22, 2015 at 8:19 PM, Ian Smith smi...@nimnet.asn.au wrote:
On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote:
  On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko fi...@ukr.net wrote:
 [..]
Try changing the options in /boot/device.hints
hint.acpi_throttle.0.disabled=0
hint.p4tcc.0.disabled=0
   
  Thanks, those also fixed powerd(8) for me that stopped working after
  upgrading to stable/10 from releng/10.1. Why are those setting
  suddenly needed now?
 
  -Kimmo
 [..]
Can you say exactly in what way powerd stopped working then?
  
   Powerd(8) complained (excerpt from dmesg -a):
  
   Starting powerd.
   powerd: no cpufreq(4) support -- aborting: No such file or directory
   /etc/rc: WARNING: failed to start powerd
  
   Putting those two settings in loader.conf and rebooting fixed the
   problem and powerd started working again apparently because cpufreq(4)
   device was available again.

 Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus
 powerd - work for you, then it seems likely that you do not have EST
 enabled in your BIOS.  Or at least, we've seen another instance where
 that was the case, which was fixed by enabling EST (or however your
 particular BIOS refers to it .. AMD for example use different terms).

 What CPU is this?  In what machine?

 If EST (ono) IS enabled in your BIOS, this needs further investigation.

 As is, powerd may be running, but it's doing so highly inefficiently;
 refer to Stefan, Adrian and Kevin's responses for details.

 cheers, Ian

It's an Intel Atom running amd64 version of FreeBSD stable/10:

FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
r283292: Sat May 23 01:08:03 EEST 2015
r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64

CPU: Intel(R) Atom(TM) CPU D510   @ 1.66GHz (1666.68-MHz K8-class CPU)
  Origin=GenuineIntel  Id=0x106ca  Family=0x6  Model=0x1c  Stepping=10
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
  AMD Features=0x20100800SYSCALL,NX,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant, performance statistics

Powerd was working on 10.1-RELEASE but stopped working after upgrade
to 10-STABLE and nothing was changed in BIOS settings.

However, reading the other replies to this thread I get the impression
that powerd(8) doesn't actually save energy on this platform and I'm
better off without it?

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

Re: CPU frequency doesn't drop below 1200MHz (like it used to)

[Kimmo Paasiala]

On Sat, May 23, 2015 at 6:57 PM, Ian Smith smi...@nimnet.asn.au wrote:
 On Sat, 23 May 2015 17:40:26 +0300, Kimmo Paasiala wrote:
   On Sat, May 23, 2015 at 5:15 PM, Ian Smith smi...@nimnet.asn.au wrote:
 [..]
  It's an Intel Atom running amd64 version of FreeBSD stable/10:
 
  FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
  r283292: Sat May 23 01:08:03 EEST 2015
  r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64
 
  CPU: Intel(R) Atom(TM) CPU D510   @ 1.66GHz (1666.68-MHz K8-class CPU)
Origin=GenuineIntel  Id=0x106ca  Family=0x6  Model=0x1c  
 Stepping=10

 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE

 Features2=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
AMD Features=0x20100800SYSCALL,NX,LM
AMD Features2=0x1LAHF
TSC: P-state invariant, performance statistics
 
  Powerd was working on 10.1-RELEASE but stopped working after upgrade
  to 10-STABLE and nothing was changed in BIOS settings.
 [..]
  However, reading the other replies to this thread I get the impression
  that powerd(8) doesn't actually save energy on this platform and I'm
  better off without it?
   
No, I don't think that's correct; using deeper C-states is most likely a
bigger win, but higher than needed CPU freq will still use extra power,
so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.
   
Reason I'm pursuing this is that this change shouldn't hurt, but it will
flush out those cases where people were only getting cpufreq due to use
of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS;
I suspect yours may be one such case :)  If not, there's a bug to fix.

 Seems _I've_ got a bug to fix; I need to stop assuming all modern Intel
 CPUs are going to make SpeedStep and/or deeper C-states available :(

   Looking deeper into this it appears I don't have speedstep (EST)
   support in the CPU it being a crappy Atom D510:
  
   http://ark.intel.com/products/43098

 Indeed.  It is rated at only 13W TDP, so relatively low power anyway.

   This the full 'sysctl dev.cpu' output:
  
   % sysctl dev.cpu

   dev.cpu.3.cx_usage: 100.00% last 65712us
   dev.cpu.3.cx_lowest: C1
   dev.cpu.3.cx_supported: C1/1/0
 [..]
   dev.cpu.0.cx_usage: 100.00% last 3132us
   dev.cpu.0.cx_lowest: C1
   dev.cpu.0.cx_supported: C1/1/0
   dev.cpu.0.%parent: acpi0
   dev.cpu.0.%pnpinfo: _HID=none _UID=0
   dev.cpu.0.%location: handle=\_PR_.P001
   dev.cpu.0.%driver: cpu
   dev.cpu.0.%desc: ACPI CPU
   dev.cpu.%parent:

 It doesn't even provide dev.cpu.0.freq, and has no deeper C-states
 ('Idle States' on that page) available, so it looks like you may as well
 not bother running powerd.  Others maybe can offer better suggestions.

   So I should keep those two hints in loader.conf to use p4tcc I guess?

 If this is a desktop I'd just let it run flat out, ie disable p4tcc and
 acpi_throttle, have no cpufreq and forget powerd.

 If it's a laptop and power consumption on battery matters to you, you
 could see if p4tcc's lower frequencies actually save any power much, by
 running 'powerd -v' in a terminal while testing with different loads, or
 if your 'acpiconf -i0' shows discharging rates in mA or mW, or both.

 Sorry again for my poor assumption, and thanks for the data point!

 cheers, Ian

It's a firewall/router with some minimal services like nginx running.
I'll just leave it like it's now without any frequency control.

Thanks,

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

Re: CPU frequency doesn't drop below 1200MHz (like it used to)

[Kimmo Paasiala]

On Sat, May 23, 2015 at 5:15 PM, Ian Smith smi...@nimnet.asn.au wrote:
 On Sat, 23 May 2015 14:01:16 +0300, Kimmo Paasiala wrote:
   On Sat, May 23, 2015 at 10:00 AM, Ian Smith smi...@nimnet.asn.au wrote:
On Fri, 22 May 2015 20:26:40 +0300, Kimmo Paasiala wrote:
  On Fri, May 22, 2015 at 8:19 PM, Ian Smith smi...@nimnet.asn.au 
 wrote:
   On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote:
 On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko fi...@ukr.net 
 wrote:
[..]
   Try changing the options in /boot/device.hints
   hint.acpi_throttle.0.disabled=0
   hint.p4tcc.0.disabled=0
  
 Thanks, those also fixed powerd(8) for me that stopped working 
 after
 upgrading to stable/10 from releng/10.1. Why are those setting
 suddenly needed now?
[..]
   Can you say exactly in what way powerd stopped working then?
 
  Powerd(8) complained (excerpt from dmesg -a):
 
  Starting powerd.
  powerd: no cpufreq(4) support -- aborting: No such file or directory
  /etc/rc: WARNING: failed to start powerd
 
  Putting those two settings in loader.conf and rebooting fixed the
  problem and powerd started working again apparently because cpufreq(4)
  device was available again.
   
Ok, if anabling acpi_throttle and/or p4tcc made cpufreq - and thus
powerd - work for you, then it seems likely that you do not have EST
enabled in your BIOS.  Or at least, we've seen another instance where
that was the case, which was fixed by enabling EST (or however your
particular BIOS refers to it .. AMD for example use different terms).
   
What CPU is this?  In what machine?
   
If EST (ono) IS enabled in your BIOS, this needs further investigation.
   
As is, powerd may be running, but it's doing so highly inefficiently;
refer to Stefan, Adrian and Kevin's responses for details.

   It's an Intel Atom running amd64 version of FreeBSD stable/10:
  
   FreeBSD firewall.rdnzl.info 10.1-STABLE FreeBSD 10.1-STABLE #1
   r283292: Sat May 23 01:08:03 EEST 2015
   r...@firewall.rdnzl.info:/usr/obj/usr/src/sys/GENERIC  amd64
  
   CPU: Intel(R) Atom(TM) CPU D510   @ 1.66GHz (1666.68-MHz K8-class CPU)
 Origin=GenuineIntel  Id=0x106ca  Family=0x6  Model=0x1c  Stepping=10
 
 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
 Features2=0x40e31dSSE3,DTES64,MON,DS_CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE
 AMD Features=0x20100800SYSCALL,NX,LM
 AMD Features2=0x1LAHF
 TSC: P-state invariant, performance statistics
  
   Powerd was working on 10.1-RELEASE but stopped working after upgrade
   to 10-STABLE and nothing was changed in BIOS settings.

 Which would be consistent with EST not being enabled in your BIOS; with
 no EST, cpufreq(4) still checks for 'relative' drivers such as p4tcc or
 acpi_throttle and uses that, as a last resort really; with those also
 disabled, no cpufreq, so no powerd.  Have you checked BIOS settings to
 confirm that you do have SpeedStep (however termed) properly enabled?

 Please show `sysctl dev.cpu dev.est` and `sysctl -a | grep freq_levels`

   However, reading the other replies to this thread I get the impression
   that powerd(8) doesn't actually save energy on this platform and I'm
   better off without it?

 No, I don't think that's correct; using deeper C-states is most likely a
 bigger win, but higher than needed CPU freq will still use extra power,
 so run hotter. `sysctl dev.cpu` will also reveal your C-state usage.

 Reason I'm pursuing this is that this change shouldn't hurt, but it will
 flush out those cases where people were only getting cpufreq due to use
 of a 'relative' cpufreq driver like p4tcc, unless EST's enabled in BIOS;
 I suspect yours may be one such case :)  If not, there's a bug to fix.

 cheers, Ian

Looking deeper into this it appears I don't have speedstep (EST)
support in the CPU it being a crappy Atom D510:

http://ark.intel.com/products/43098

This the full 'sysctl dev.cpu' output:

% sysctl dev.cpu
dev.cpu.3.cx_usage: 100.00% last 65712us
dev.cpu.3.cx_lowest: C1
dev.cpu.3.cx_supported: C1/1/0
dev.cpu.3.%parent: acpi0
dev.cpu.3.%pnpinfo: _HID=none _UID=0
dev.cpu.3.%location: handle=\_PR_.P004
dev.cpu.3.%driver: cpu
dev.cpu.3.%desc: ACPI CPU
dev.cpu.2.cx_usage: 100.00% last 41518us
dev.cpu.2.cx_lowest: C1
dev.cpu.2.cx_supported: C1/1/0
dev.cpu.2.%parent: acpi0
dev.cpu.2.%pnpinfo: _HID=none _UID=0
dev.cpu.2.%location: handle=\_PR_.P003
dev.cpu.2.%driver: cpu
dev.cpu.2.%desc: ACPI CPU
dev.cpu.1.cx_usage: 100.00% last 12706us
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_supported: C1/1/0
dev.cpu.1.%parent: acpi0
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%location: handle=\_PR_.P002
dev.cpu.1.%driver: cpu
dev.cpu.1.%desc: ACPI CPU
dev.cpu.0.cx_usage: 100.00% last 3132us
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_supported: C1/1/0
dev.cpu.0.%parent: acpi0

Re: CPU frequency doesn't drop below 1200MHz (like it used to)

[Kimmo Paasiala]

On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko fi...@ukr.net wrote:
 Fri, 22 May 2015 09:33:15 +0200
 Nikos Vassiliadis nv...@gmx.com написав:

 Hi,

 I just noticed that my CPU's frequency doesn't support dropping
 below 1200MHz. It used to be able to go down to 150MHz, if I am
 not mistaken. I'd like it to go down to 600MHz via powerd, like
 it used to go. This is a month's old 10-STABLE.

  [nik@moby ~]$ sysctl dev.cpu.0.freq_levels
  dev.cpu.0.freq_levels: 2400/35000 2300/32872 2200/31127 2100/29417
  2000/27740 1900/26096 1800/24490 1700/22588 1600/21045 1500/19534
  1400/18055 1300/16611 1200/15194

 This is the CPU:
   hw.model: Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz

 Thanks in advance for any ideas,
 Nikos

 Try changing the options in /boot/device.hints
 hint.acpi_throttle.0.disabled=0
 hint.p4tcc.0.disabled=0

Thanks, those also fixed powerd(8) for me that stopped working after
upgrading to stable/10 from releng/10.1. Why are those setting
suddenly needed now?

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

Re: CPU frequency doesn't drop below 1200MHz (like it used to)

[Kimmo Paasiala]

On Fri, May 22, 2015 at 8:19 PM, Ian Smith smi...@nimnet.asn.au wrote:
 On Fri, 22 May 2015 16:28:49 +0300, Kimmo Paasiala wrote:
   On Fri, May 22, 2015 at 10:42 AM, Ivan Klymenko fi...@ukr.net wrote:
 Fri, 22 May 2015 09:33:15 +0200
 Nikos Vassiliadis nv...@gmx.com яя:

 Hi,

 I just noticed that my CPU's frequency doesn't support dropping
 below 1200MHz. It used to be able to go down to 150MHz, if I am
 not mistaken. I'd like it to go down to 600MHz via powerd, like
 it used to go. This is a month's old 10-STABLE.

  [nik@moby ~]$ sysctl dev.cpu.0.freq_levels
  dev.cpu.0.freq_levels: 2400/35000 2300/32872 2200/31127 2100/29417
  2000/27740 1900/26096 1800/24490 1700/22588 1600/21045 1500/19534
  1400/18055 1300/16611 1200/15194

 This is the CPU:
   hw.model: Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz

 Thanks in advance for any ideas,
 Nikos

 Try changing the options in /boot/device.hints
 hint.acpi_throttle.0.disabled=0
 hint.p4tcc.0.disabled=0

   Thanks, those also fixed powerd(8) for me that stopped working after
   upgrading to stable/10 from releng/10.1. Why are those setting
   suddenly needed now?
  
   -Kimmo

 Looks like the changes to these two hints, now defaulting to 1,
 committed to -head some months ago has been merged to stable/10.

 Can you say exactly in what way powerd stopped working then?

Powerd(8) complained (excerpt from dmesg -a):

Starting powerd.
powerd: no cpufreq(4) support -- aborting: No such file or directory
/etc/rc: WARNING: failed to start powerd

Putting those two settings in loader.conf and rebooting fixed the
problem and powerd started working again apparently because cpufreq(4)
device was available again.

-Kimmo


 Except that the minimum frequency that may be set with powerd's -m
 switch will be higher without p4tcc (or acpi_throttle) running, this
 change shouldn't hurt powerd; if anything it should be more efficient,
 as the lower p4tcc-generated frequencies don't save much if any power.

 If you compare dev.cpu.0.freq_levels, as above, both before and after
 booting with the changed hints, you can see the ones due to p4tcc's use
 of subfrequencies with factors of 1/8 to 7/8 of some base freq, but the
 power use in milliWatts provided for these seems largely ficticious.

 On my Lenovo X200, Core2Duo 2.4GHz, idling on battery at 800MHz (minimum
 EST freq) or at 100MHz using p4tcc draws almost exactly the same power,
 about 7.6W measured from the battery - but responsiveness as performance
 is required is a great deal better using just the base EST freqs; YMMV.

 This generally gets discussed on the freebsd-mobile and freebsd-acpi
 lists; not sure if a deeper discussion of issues is warranted here.

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

Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC?

[Kimmo Paasiala]

On Fri, Aug 30, 2013 at 3:07 AM, Andy Farkas an...@andyit.com.au wrote:
 There's still plenty of laptops that would be crippled if these were
 removed.


 Indeed:

 dc0: Abocom FE2500 10/100BaseTX port 0x1000-0x10ff mem
 0x8800-0x880003ff irq 11 at device 0.0 on cardbus1

 -andyf


Just to be clear, I'm not suggesting to retire the drivers but to take
them out of the GENERIC kernel config and move them to be loaded as
modules only. Adrian Chadd undestood perfectly what I was after.

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

Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC?

[Kimmo Paasiala]

In reference to this FreeBSD forums post:

http://forums.freebsd.org/showpost.php?p=231135postcount=4

Would it be a good time to remove those from GENERIC since the
hardware they are for is becoming so seriously outdated?

There's always an option to load those drivers as modules if needed.

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

Re: Installer on serial-console-only-embedded system

[Kimmo Paasiala]

On Mon, Aug 12, 2013 at 4:00 PM, CeDeROM cede...@tlen.pl wrote:
 On Mon, Aug 12, 2013 at 2:56 PM, Michael Sierchio ku...@tenebras.com wrote:
 You need to change /etc/ttys to turn off the virtual consoles and turn
 on a serial terminal.
 (..)

 Thank you Michael for the hint! Do you think it would be sensible to
 put that functionality into a new installer to detect this kind of
 configuration and apply it over fresh system during install (just as
 it detects and verifies some partitioning formats)?

 Best regards! :-)
 Tomek

 --

You can easily detect that the system has a COM port. However, it is
very hard to detect that there is a working terminal attached to the
port.

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

Re: Strange sendmail behaviour after upgrade to 9.1-BETA2

[Kimmo Paasiala]

Forgot to send to list as well

On Thu, Aug 1, 2013 at 1:40 PM, Pavel Timofeev tim...@gmail.com wrote:
 Ok, I understand. Thanks a lot for excelent explanation. Maybe
 sendmail ignores additional section?

 I use _default_ fresh system, so resolver is _default_ bind.
 For investigation I've just installed fresh 9.1-RELEASE amd64, email
 delivery works and picture looks different than on 9.2:


The default resolver is not BIND because it's not enabled by default.
The nameservers listed in /etc/resolv.conf are used for resolving
addresses in default setup (assuming they are filled properly by DHCP
client or manually by user).
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: sshd didn't run after upgrade to FreeBSD 8.4

[Kimmo Paasiala]

On Thu, Jun 20, 2013 at 1:17 AM, Miroslav Lachman 000.f...@quip.cz wrote:
 The version of sshd in FreeBSD 8.4 is not backward compatible with older
 version from 8.3.

 OpenSSH_5.4p1 (on FreeBSD 8.3)
 OpenSSH_6.1p1 (on FreeBSD 8.4)

 # sshd -t
 /etc/ssh/sshd_config line 19: Missing argument.

 On line 19, there is:
 VersionAddendum

 It was OK in older versions. It will remove any default text appended to SSH
 protocol banner (for example 'FreeBSD-20120901').

 On FreeBSD 8.4, there must be some string (any single character)

 I was really badly surprised that the machine was re-booted without ssh
 access!

 I think this change is worth to mention in Release Notes

 Miroslav Lachman

How did you update to 8.4? This sounds more like messing up the
mergemaster(8)/freebsd-update merge procedure than a real problem with
the config file.

This is the source configuration file straight from SVN releng/8.4
branch and as you can see the VersionAddendum on line 115 is commented
out there:

http://svnweb.freebsd.org/base/releng/8.4/crypto/openssh/sshd_config?view=markup

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

Re: sshd didn't run after upgrade to FreeBSD 8.4

[Kimmo Paasiala]

On Thu, Jun 20, 2013 at 2:29 AM, Miroslav Lachman 000.f...@quip.cz wrote:
 Kimmo Paasiala wrote:

 On Thu, Jun 20, 2013 at 1:17 AM, Miroslav Lachman000.f...@quip.cz
 wrote:

 The version of sshd in FreeBSD 8.4 is not backward compatible with older
 version from 8.3.

 OpenSSH_5.4p1 (on FreeBSD 8.3)
 OpenSSH_6.1p1 (on FreeBSD 8.4)

 # sshd -t
 /etc/ssh/sshd_config line 19: Missing argument.

 On line 19, there is:
 VersionAddendum

 It was OK in older versions. It will remove any default text appended to
 SSH
 protocol banner (for example 'FreeBSD-20120901').

 On FreeBSD 8.4, there must be some string (any single character)

 I was really badly surprised that the machine was re-booted without ssh
 access!

 I think this change is worth to mention in Release Notes

 Miroslav Lachman


 How did you update to 8.4? This sounds more like messing up the
 mergemaster(8)/freebsd-update merge procedure than a real problem with
 the config file.

 This is the source configuration file straight from SVN releng/8.4
 branch and as you can see the VersionAddendum on line 115 is commented
 out there:


 http://svnweb.freebsd.org/base/releng/8.4/crypto/openssh/sshd_config?view=markup


 It was upgraded by freebsd-update. It was intentionally left here as it was
 valid configuration for many years.
 That's why I think it should be mentioned in the Release Notes, that it is
 no longer valid configuration (empty VersionAddendum).

 The fact, that it is no longer in default sshd_config file doesn't mean it
 can't be used at all. It is still valid in the form which was in old default
 config: VersionAddendum FreeBSD-20100308, but is no longer valid if empty.
 That's the point.

 (and empty VersionAddendum was widely used, it is not my invention)

 Miroslav Lachman


You're missing my point totally. The line is commented out in the
official source of 8.4 and there for I have very hard time believing
that it would show up uncommented on a fresh 8.4 installation.

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

Re: sshd didn't run after upgrade to FreeBSD 8.4

[Kimmo Paasiala]

On Thu, Jun 20, 2013 at 2:40 AM, Steven Hartland
kill...@multiplay.co.uk wrote:


 I believe Miroslav is saying he left his old but previously working
 sshd_config as was when updating, so its a change to the code which
 now fails on an empty VersionAddendum, where it previously didn't
 hence the problem.

Regards
Steve



Err yes, your right. The proper way to specify empty VersionAddendum
based on some googling seems to be now:


VersionAddendum 


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

Re: sshd didn't run after upgrade to FreeBSD 8.4

[Kimmo Paasiala]

On Thu, Jun 20, 2013 at 3:15 AM, Miroslav Lachman 000.f...@quip.cz wrote:
 Kimmo Paasiala wrote:

 On Thu, Jun 20, 2013 at 2:40 AM, Steven Hartland
 kill...@multiplay.co.uk  wrote:



 I believe Miroslav is saying he left his old but previously working
 sshd_config as was when updating, so its a change to the code which
 now fails on an empty VersionAddendum, where it previously didn't
 hence the problem.


 Yes, this is my point - I left my old and previously working sshd_config
 with empty VersionAddendum.


 Err yes, your right. The proper way to specify empty VersionAddendum
 based on some googling seems to be now:


 VersionAddendum 


 This is not true, it will add two quotes to the banner:
 SSH-2.0-OpenSSH_6.1_hpn13v11 


 Default banner (no VersionAddendum in sshd_config):
 SSH-2.0-OpenSSH_6.1_hpn13v11 FreeBSD-20120901


 So I am fine with:
 VersionAddendum -

 It will print:
 SSH-2.0-OpenSSH_6.1_hpn13v11 -

 I don't need really empty addendum, I just don't want to show FreeBSD
 version info and empty VersionAddendum was working for me many years. Now it
 breaks sshd after final reboot on two of our upgraded servers.

 So Release Notes or better UPDATING entry will warn other users before the
 same mistake.

 Thanks to the remote management / KVM on Sun Fire and Supermicro servers
 that I didn't need to drive to the datacenter and I can fix it remotely.

 Miroslav Lachman

Ok, this is crazy. If you put one space after the VersionAddendum
keyword you get exactly what you want, an empty VersionAddendum
string. If there's no space but a newline right after the
VersionAddendum keyword, sshd(8) complains about the line and refuses
to start. So this is ok (without the single quotes, they are just to
show the endings of the lines):

'VersionAddendum '

But this is not:

'VersionAddendum'

What are the OpenSSH devs thinking?

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

Re: zpool labelclear destroys GPT data

[Kimmo Paasiala]

The 'device' can be a partition as well as the whole disk, use 'zpool
labelclear' on the freebsd-zfs partition instead of the whole disk.

-Kimmo

On Thu, Jun 13, 2013 at 3:29 PM, Johan Hendriks joh.hendr...@gmail.com wrote:
 When i use zpool labelclear, it wipes the whole disk including gpt data.
 So the whole disk is empty and i need to create the gpt partitions again.

 Is this supposed to work like this?
 The man page suggests that it only wipes the ZFS metadata.

 zpool labelclear [-f] device

  Removes ZFS label information from the specified device. The device
  must not be part of an active pool configuration.

  -v  Treat exported or foreign devices as inactive.

 This is on FreeBSD 9.1 stable r251213 memstick install.

 regards

 Johan Hendriks
 Neuteboom Automatisering
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: zpool labelclear destroys GPT data

[Kimmo Paasiala]

On Fri, Jun 14, 2013 at 12:22 AM, Johan Hendriks joh.hendr...@gmail.com wrote:
 Op 13-6-2013 14:40, Kimmo Paasiala schreef:

 The 'device' can be a partition as well as the whole disk, use 'zpool
 labelclear' on the freebsd-zfs partition instead of the whole disk.

 -Kimmo

 On Thu, Jun 13, 2013 at 3:29 PM, Johan Hendriks joh.hendr...@gmail.com
 wrote:

 When i use zpool labelclear, it wipes the whole disk including gpt data.
 So the whole disk is empty and i need to create the gpt partitions again.

 Is this supposed to work like this?
 The man page suggests that it only wipes the ZFS metadata.

 zpool labelclear [-f] device

   Removes ZFS label information from the specified device. The
 device
   must not be part of an active pool configuration.

   -v  Treat exported or foreign devices as inactive.

 This is on FreeBSD 9.1 stable r251213 memstick install.

 regards

 Johan Hendriks
 Neuteboom Automatisering
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

 Thanks for your reply.
 I will try it on the actual zfs partition.

 But imho it is a bad thing that it destroys the whole disk layout.
 It does not remove ZFS label information, it removes ALL label information
 on the disk or device you give it


 regards
 Johan Hendriks
 Neuteboom Automatisering


Of course, zpool(8) will do exactly what you tell it to do. It does
not know about any partitioning schemes and assumes that the user
knows that using labelclear on a the whole disk will potentially
destroy all data on it including any partitioning information.

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

Re: Corrupt GPT header on disk from twa array - fixable?

[Kimmo Paasiala]

On Sun, Jun 2, 2013 at 5:02 PM, Steven Hartland kill...@multiplay.co.uk wrote:
 Does gpart recover ada4 help at all?

 Be warned this could edit the partition on the disk and make it worse, but
 I've had success in the past with it.

Regards
Steve

 - Original Message - From: Alban Hertroys haram...@gmail.com
 To: freebsd-stable@freebsd.org
 Sent: Sunday, June 02, 2013 2:53 PM
 Subject: Corrupt GPT header on disk from twa array - fixable?



 Hello list,

 I just replaced my home server and moved the disks from the old one over
 to the new one. In the old server, 4 of the disks were connected to a twa
 (3Ware 9550) controller, which of course has it's own way of marking
 units/volumes on those disks.

 Before you start yelling at me, yes, of course I made backups ;) [*]

 The thing is, I have these disks in the new server and I found that I (to
 my surprise) I can actually mount them! But, I'm missing a large part and I
 am wondering if there's some method to access those last partitions too.

 Here's what gpart show says about the problematic disk:

 # gpart show /dev/ada4
 =  34  41942972  ada4  GPT  (931G) [CORRUPT]
34   128 1  freebsd-boot  (64k)
   162   1048448 2  freebsd-ufs  (512M)
   1048610   6291456 3  freebsd-swap  (3.0G)
   7340066   1048576 4  freebsd-ufs  (512M)
   8388642   2097152 5  freebsd-ufs  (1.0G)
  10485794  31457211 6  freebsd-ufs  (15G)
  41943005 1- free -  (512B)

 As you can see, most (about 910GB) of the disk is missing! This disk was
 one half of a mirror on the twa controller, which had those disks split in
 two again (I don't recall how, perhaps 2 different BSD slices?)
 I already looked if that part may perhaps have ended up as a different
 device. On the old server, fstab was this:

 # cat /tmp/solfertje/etc/fstab
 # DeviceMountpoint  FStype  Options DumpPass#

 # These are the partitions listed above in gpart
 /dev/da0p2  /   ufs rw  1   1
 /dev/da0p3  noneswapsw  0   0
 /dev/da0p4  /varufs rw  2   2
 /dev/da0p5  /tmpufs rw  2   2
 /dev/da0p6  /usrufs rw  2   2

 # These are missing
 /dev/da1p1  /home   ufs rw  2   2
 /dev/da1p2  /media  ufs rw  2   2

 # These are on a different disk (ada2)
 /dev/da2p1  /media2 ufs rw  2   2


 I don't _really_ need to get to those partitions, but it would be a
 comfortable thought if it were possible somehow.


 [*] The reason I was trying to access those disks anyway is that I thought
 I forgot to backup my database tables, but it turns out I had just misplaced
 that backup and it has been restored now.

 Alban Hertroys
 --
 If you can't see the forest for the trees,
 cut the trees and you'll find there is no forest.

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




Looking at the gpart(8) output it seems that only 20GBs of the disk is
recognized by the disk driver but the GPT table still shows the full
capacity 910GB. I'd say that the GPT table is in fact correct and if
you can somehow get the disks to be recognized with full capacity they
should be usable as they are. What does dmesg(8) say about the disks?

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

config(8) -x headscratcher

[Kimmo Paasiala]

I'm getting a core dump on 'config -x /boot/kernel/kernel' on 9.1-RELEASE i386.

Assertion failed: (r != '\0'  (Char present in the configuration 
string mustn't be equal to 0)), function kernconfdump, file
/usr/src/usr.sbin/config/main.c, line 710.

I have double checked that my config file is sane and does not have
any funny characters anywhere.

The system is i386 9.1-RELEASE r249856. The world and kernel are built
with clang and I'm suspecting that the use of clang has something to
do with this segfault.

Looking at the kernel files I can see one very obvious difference.
This is the 'elfdump -c kernel | grep -A 8 kern_conf' output (what
config -x seems to use for finding out the config file from the kernel
image) for the GENERIC kernel from the stock installation:

sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc1039f80
sh_offset: 12820352
sh_size: 3771
sh_link: 0
sh_info: 0
sh_addralign: 32

And this is from the kernel I have built myself using clang and a
custom config file:

sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc09aee9c
sh_offset: 5959324
sh_size: 1994
sh_link: 0
sh_info: 0
sh_addralign: 1

The align field looks suspicious, config -x seems to use it to check
for padding but to me it looks like the logic may not work if the
alignment is 1.

This the relevant bit from main.c of config(8)

if (r == '\0'  (size - i)  align)
break;
assert(r != '\0'  (Char present in the configuration 
string mustn't be equal to 0));
fputc(r, stdout);


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

Re: svn revision stable/9

[Kimmo Paasiala]

On Tue, Apr 23, 2013 at 3:42 PM, John Mehr j...@visi.com wrote:


 Hello,

 svnup stores known file information in /tmp/svnup for each of the defined
 sections (current, stable, ports, etc.) and in the next update, it will be
 including the revision number in these files so that something like:

 # svnup stable -n

 would return the stable branch's last downloaded revision number and then
 exit.

 Because the current, stable and releng branches all use /usr/src by default,
 implementing a custom svnversion to inform newvers.sh of which revision
 exists in /usr/src would be problematic without leaving a small bread crumb
 there for newvers.sh to use.  If this is ok to do, I can include this in the
 next revision (which should be ready to go in the next couple of days).


Wouldn't /var/db/svnup be the proper place for the bread crumb?

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Thu, Jan 17, 2013 at 7:24 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin sch...@gmail.com wrote:
 2012/12/26 Kimmo Paasiala kpaas...@gmail.com:

 I've revised the patch again and updated it at gihub,
 https://gist.github.com/4362018.  It can now be applied at top level
 of sources (/usr/src typically). It now does the deconfiguration in
 reverse order of the configuration, meaning the aliases configured
 with ipv6_addrs_IF are removed before the ones configured with
 ifconfig_IF_aliasN=inet6 

 Adapted for FreeBSD 8.2, works fine:

 --- network.subr.orig   2011-02-17 05:19:39.0 +0300
 +++ network.subr2012-12-28 00:46:38.0 +0400
 @@ -312,6 +312,12 @@ afexists()
  #  1 otherwise.
  ipv6if()
  {
 +   # Test for $ipv6_addrs_IF. If it exists then the
 +   # interface should be configured for IPv6
 +   _tmpargs=$(get_if_var $_if ipv6_addrs_IF)
 +   if [ -n ${_tmpargs} ]; then
 +   return 0
 +   fi
 if ! checkyesno ipv6_enable; then
 return 1
 fi
 @@ -948,7 +954,12 @@ network6_interface_setup()
 rtsol_interface=no
 ifconfig $i inet6 ${ipv6_ifconfig} alias
 fi
 -
 +   ipv6_addrs=`get_if_var $i ipv6_addrs_IF`
 +   if [ -n ${ipv6_addrs} ]; then
 +   rtsol_available=no
 +   rtsol_interface=no
 +   ipv6_addrs_common ${i} alias
 +   fi
 # Wireless NIC cards are virtualized through the wlan 
 interface
 if ! is_wired_interface ${i}; then
 case ${i} in
 @@ -1178,3 +1189,39 @@ network6_getladdr()
 esac
 done
  }
 +
 +ipv6_addrs_common()
 +{
 +   local _ret _if _action _ip6prefix _ip6prefixes
 +   local _ip6addr _prefixlen
 +   local _range _ip6net _ip6low _ip6high
 +   _ret=1
 +   _if=$1
 +   _action=$2
 +   # get the prefixes from ipv6_addrs_IF variable
 +   _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
 +   for _ip6prefix in ${_ip6prefixes}; do
 +   _ip6addr=${_ip6prefix%%/*}
 +   _prefixlen=${_ip6prefix##*/}
 +   _range=${_ip6addr##*:}
 +   _ip6net=${_ip6addr%:*}
 +   _ip6low=${_range%-*}
 +   _ip6high=${_range#*-}
 +   # If deleting an alias, set _prefixlen to null string.
 +   if [ ${_action} = -alias ]; then
 +   _prefixlen=
 +   else
 +   _prefixlen=prefixlen $_prefixlen
 +   fi
 +   _ip6high=$((0x${_ip6high}))
 +   _ip6count=$((0x${_ip6low}))
 +   while [ ${_ip6count} -le ${_ip6high} ]; do
 +   # Re-uses the _ip6addr variable from above
 +   _ip6addr=$(printf %x ${_ip6count})
 +   eval ifconfig ${_if} inet6
 ${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}
 +   _ip6count=$((${_ip6count}+1))
 +   _ret=0
 +   done
 +   done
 +   return $_ret
 +}


 --
 Non nobis Domine non nobis sed Nomini Tuo da gloriam
 Phil Kulin

 I don't have an 8.X system to test but I guess it's fine.

 Any more interest in this? I'd love to see this added, not because I
 wrote it but because I want to contribute in any way I can.

 -Kimmo

Sorry to resurrect this thread but since nothing has happened in about
three months I have to ask: What can I do to have this commited to
HEAD? I'd be even willing to become a src committer if that's what is
required. I feel that I'm compentent enough. Who can I contact?

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

Re: troubles with buildworld/sendmail/sasl/clang

[Kimmo Paasiala]

On Mon, Mar 18, 2013 at 1:03 PM, Beat Siegenthaler
beat.siegentha...@beatsnet.com wrote:
 Hi all,

 since some days i try to make buildworld, but have some errors in
 sendmail.
 The make conf is not changed since years (in this case) . Adding
 NO_WERROR= in src.conf helps, but i think it is not the optimal solution?

 # SASL (cyrus-sasl v2) sendmail build flags...
 SENDMAIL_CFLAGS+=-I/usr/local/include -DSASL=2
 SENDMAIL_LDFLAGS+=-L/usr/local/lib
 SENDMAIL_LDADD+=-lsasl2
 SENDMAIL_CFLAGS+= -D_FFR_SMTP_SSL

 SENDMAIL_MC = /etc/mail/xyz.mc
 WITH_SSL_AND_PLAINTEXT=yes # for imaps and cclient

 ==src.conf===

 CC=clang
 CXX=clang++
 CPP=clang-cpp
 # This setting to build world without -Werror:
 # NO_WERROR=
 # This setting to build kernel without -Werror:
 # WERROR=

 =buildworld===

 /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/usersmtp.c:1864:8:
 error: incompatible pointer types passing 'void ()' to parameter of type
 'void (*)(char *, bool, MAILER *, struct mailer_con_info *, ENVELOPE *)'
 [-Werror,-Wincompatible-pointer-types]
getsasldata, NULL, XS_AUTH);
^~~
 /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sendmail.h:2519:67: 
 note:
 passing argument to parameter here
 extern int  reply __P((MAILER *, MCI *, ENVELOPE *, time_t, void
 (*)__P((char *, bool, MAILER *, MCI *, ENVELOPE *)), char **, int));
^
 /usr/obj/usr/src/tmp/usr/include/sys/cdefs.h:129:21: note: expanded from
 macro '__P'
 #define __P(protos) protos  /* full-blown ANSI C */
 ^
 3 errors generated.
 *** [usersmtp.o] Error code 1
 1 error
 *** [all] Error code 2
 1 error
 *** [usr.sbin.all__D] Error code 2
 1 error
 *** [everything] Error code 2
 1 error
 *** [buildworld] Error code 2
 1 error

 regards
 beat


I can not help with the error but I really have to make this question:
Does FreeBSD really have to support pre-ANSI C compilers in 2013?

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

Re: stable/9 r245439 breaks security/pam_ssh_agent_auth on stable/9 (WAS: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9)

[Kimmo Paasiala]

On Wed, Feb 6, 2013 at 12:28 AM, Stefan Bethke s...@lassitu.de wrote:

 Am 05.02.2013 um 23:06 schrieb Stefan Bethke s...@lassitu.de:

 Am 05.02.2013 um 19:09 schrieb Kimmo Paasiala kpaas...@gmail.com:

 On Tue, Feb 5, 2013 at 12:36 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sun, Feb 3, 2013 at 7:22 PM, Chris Rees cr...@freebsd.org wrote:
 On 3 February 2013 17:15, Stefan Bethke s...@lassitu.de wrote:

 Am 03.02.2013 um 10:57 schrieb Chris Rees cr...@freebsd.org:

 On 3 February 2013 03:55, Kimmo Paasiala kpaas...@gmail.com wrote:

 There is no PR yet with my fix and therefor no commit to ports tree
 that would fix the problem. I'll file a PR soon (TM).

 The problem was in base, and is fixed there.

 Huh? With -current r246283, I still get a segfault from sudo unless I 
 have Kimmo's patch.

 Is there some confusion about which problem is addressed by Kimmo's 
 patch?


 Hm, perhaps it might be necessary then.

 Kimmo, please would you submit the patch you had as a PR?  I'm sure
 Wesley would appreciate the hint.

 Chris

 I'll file a PR when I have recovered from a nasty flu. Right now I'm
 not fit for thinking...

 I changed the title of this thread to a better one.

 -Kimmo

 It looks like the port was updated just recently to a new version that
 has its own problems that are no longer related strnvis(3). I'll have
 to give up for now.

 (freebsd-ports added to cc:)

 I can confirm that with the new port version on a two day old current, the 
 module doesn't work:
 $ uname -a
 FreeBSD freebsd-current.lassitu.de 10.0-CURRENT FreeBSD 10.0-CURRENT #0 
 r246283: Sun Feb  3 16:55:16 CET 2013 
 r...@freebsd-current.lassitu.de:/usr/obj/usr/src/sys/GENERIC  amd64
 $ pkg info|grep pam
 pam_ssh_agent_auth-0.9.4   PAM module which permits authentication via 
 ssh-agent
 $ sudo ls
 sudo: unable to initialize PAM: No error: 0

 If I downgrade to the previous port version (and apply Kimmo's patch), it's 
 working properly.


 Here's a slightly different error message on 9-stable:
 $ uname -a
 FreeBSD diesel.lassitu.de 9.1-STABLE FreeBSD 9.1-STABLE #7 r245996: Sun Jan 
 27 22:36:05 CET 2013 r...@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL  
 amd64
 stb@diesel:~$ sudo ls
 sudo: unable to initialize PAM: No such file or directory


 Stefan

 --
 Stefan Bethke s...@lassitu.de   Fon +49 151 14070811




Latest version pam_ssh_agent_auth-0.9.4_1 seems to finally work
without any extra patches when built on a 9.1-RELEASE system.

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

Re: CLANG and -fstack-protector

[Kimmo Paasiala]

On Wed, Feb 13, 2013 at 4:22 AM, Dmitry Marakasov amd...@amdmi3.ru wrote:
 * Kimmo Paasiala (kpaas...@gmail.com) wrote:

 Does the -fstack-protector option work on CLANG 3.1 and 3.2?

 There is thread on FreeBSD forums about the stack protector and ports
 and I'm wondering if it's possible to use the -fstack-protector option
 with CLANG.

 http://forums.freebsd.org/showthread.php?t=36927

 You might be interested in this patch:

 https://github.com/AMDmi3/freebsd-ports-mk/compare/master...stack-protector

 afaik, in prior discussion some years ago an issue was mentioned that
 some ports don't build with stack-protector, so I suggested to introduce
 STACK_PROTECTOR_SAFE/_UNSAFE knobs similar to what we have for
 MAKE_JOBS_SAFE_/_UNSAFE (we might actually only need
 STACK_PROTECTOR_UNSAFE, as unlike MAKE_JOBS, build errors caused by
 enabling stack protector are not transient, so we can have an exp-run
 to just mark all uncompatible ports and consider all others compatible).

 If there's interest in this, I can refresh the patch and submit it.


Yes, this is very much what I had in mind. Please submit it :)

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

CLANG and -fstack-protector

[Kimmo Paasiala]

Hello,

Does the -fstack-protector option work on CLANG 3.1 and 3.2?

There is thread on FreeBSD forums about the stack protector and ports
and I'm wondering if it's possible to use the -fstack-protector option
with CLANG.

http://forums.freebsd.org/showthread.php?t=36927

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

Re: CLANG and -fstack-protector

[Kimmo Paasiala]

On Thu, Feb 7, 2013 at 11:06 PM, Dimitry Andric d...@freebsd.org wrote:
 On 2013-02-07 20:42, Kimmo Paasiala wrote:

 Does the -fstack-protector option work on CLANG 3.1 and 3.2?


 Yes, it works with both clang and gcc.


Good to know thank you!


 There is thread on FreeBSD forums about the stack protector and ports
 and I'm wondering if it's possible to use the -fstack-protector option
 with CLANG.

 http://forums.freebsd.org/showthread.php?t=36927


 That thread seems to be full of confusion. :-)  The base system is mostly
 built with -fstack-protector, except for the ia64, arm and mips arches,
 and for some specific cases where it is not necessary, or unwanted.

I was aware of the base system being built with the stack protector on
systems where it makes sense.


 Ports are largely independent of the base system, and their compilation
 flags are different from port to port.  You could set -fstack-protector
 for your ports in either make.conf or ports.conf, if you wanted.

Is there any work being done to provide an optional Makefile knob
(WITH_STACK_PROTECTOR ?) to turn on -fstack-protector for ports that
install network services (or other critical code)? I'd bet such
feature would be popular.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: stable/9 r245439 breaks security/pam_ssh_agent_auth on stable/9 (WAS: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9)

[Kimmo Paasiala]

On Tue, Feb 5, 2013 at 12:36 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sun, Feb 3, 2013 at 7:22 PM, Chris Rees cr...@freebsd.org wrote:
 On 3 February 2013 17:15, Stefan Bethke s...@lassitu.de wrote:

 Am 03.02.2013 um 10:57 schrieb Chris Rees cr...@freebsd.org:

 On 3 February 2013 03:55, Kimmo Paasiala kpaas...@gmail.com wrote:

 There is no PR yet with my fix and therefor no commit to ports tree
 that would fix the problem. I'll file a PR soon (TM).

 The problem was in base, and is fixed there.

 Huh? With -current r246283, I still get a segfault from sudo unless I have 
 Kimmo's patch.

 Is there some confusion about which problem is addressed by Kimmo's patch?


 Hm, perhaps it might be necessary then.

 Kimmo, please would you submit the patch you had as a PR?  I'm sure
 Wesley would appreciate the hint.

 Chris

 I'll file a PR when I have recovered from a nasty flu. Right now I'm
 not fit for thinking...

 I changed the title of this thread to a better one.

 -Kimmo

It looks like the port was updated just recently to a new version that
has its own problems that are no longer related strnvis(3). I'll have
to give up for now.

(freebsd-ports added to cc:)

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

Re: stable/9 r245439 breaks security/pam_ssh_agent_auth on stable/9 (WAS: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9)

[Kimmo Paasiala]

On Sun, Feb 3, 2013 at 7:22 PM, Chris Rees cr...@freebsd.org wrote:
 On 3 February 2013 17:15, Stefan Bethke s...@lassitu.de wrote:

 Am 03.02.2013 um 10:57 schrieb Chris Rees cr...@freebsd.org:

 On 3 February 2013 03:55, Kimmo Paasiala kpaas...@gmail.com wrote:

 There is no PR yet with my fix and therefor no commit to ports tree
 that would fix the problem. I'll file a PR soon (TM).

 The problem was in base, and is fixed there.

 Huh? With -current r246283, I still get a segfault from sudo unless I have 
 Kimmo's patch.

 Is there some confusion about which problem is addressed by Kimmo's patch?


 Hm, perhaps it might be necessary then.

 Kimmo, please would you submit the patch you had as a PR?  I'm sure
 Wesley would appreciate the hint.

 Chris

I'll file a PR when I have recovered from a nasty flu. Right now I'm
not fit for thinking...

I changed the title of this thread to a better one.

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

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Sun, Feb 3, 2013 at 11:57 AM, Chris Rees cr...@freebsd.org wrote:
 On 3 February 2013 03:55, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sun, Feb 3, 2013 at 4:06 AM, Mark Linimon lini...@lonesome.com wrote:
 On Fri, Feb 01, 2013 at 11:53:03AM -0600, Brooks Davis wrote:
 I'm not sure why I'm being jumped on in this weeks old report of a
 now-fixed problem.

 I'm sorry, I'm that far behind in email.  I did not realize the problem
 had already been solved.

 More often than not the problem is simply thrown over the fence for
 the ports team to deal with.

 mcl

 There is no PR yet with my fix and therefor no commit to ports tree
 that would fix the problem. I'll file a PR soon (TM).

 The problem was in base, and is fixed there.

 Chris

I missed that fix if it was posted here, can someone point me to the
commit that fixed the issue?

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

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Sun, Feb 3, 2013 at 4:06 AM, Mark Linimon lini...@lonesome.com wrote:
 On Fri, Feb 01, 2013 at 11:53:03AM -0600, Brooks Davis wrote:
 I'm not sure why I'm being jumped on in this weeks old report of a
 now-fixed problem.

 I'm sorry, I'm that far behind in email.  I did not realize the problem
 had already been solved.

 More often than not the problem is simply thrown over the fence for
 the ports team to deal with.

 mcl

There is no PR yet with my fix and therefor no commit to ports tree
that would fix the problem. I'll file a PR soon (TM).

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

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Tue, Jan 29, 2013 at 9:08 PM, Mike Tancsa m...@sentex.net wrote:
 On 1/17/2013 4:35 PM, Kimmo Paasiala wrote:
 On Thu, Jan 17, 2013 at 5:15 PM, Dimitry Andric d...@freebsd.org wrote:
 On 2013-01-17 14:07, Kimmo Paasiala wrote:

 On Thu, Jan 17, 2013 at 2:11 AM, Brooks Davis bro...@freebsd.org wrote:

 ...

 Please try the following patch, which tells configure that HAVE_STRNVIS
 is always false.  I think this is the easiest way, unless we really want
 the port to use our own strnvis.

 This will still leave the exported symbol in the plugin binary with
 the name strnvis. What would be needed is renaming of the function to
 something else, like pam_ssh_agent_auth_strnvis(), maybe using a macro

 #define strnvis pam_ssh_agent_auth_strnvis

 somewhere.

 I can try my hand on coming up with a fix but its going to take some
 time, the source code of the plugin and not to mention the configure
 script look quite hairy.

 Hi,
 Just wondering if anyone ever came up with a patch / work around to 
 this ?

 ---Mike


 --

Hi,

Yes I did in fact but it's a really quick and dirty hack. I renamed
the openbsd strnvis to strnvis_local so the symbol in plugin binary
won't conflict with strnvis from libc. I'll have to see if I can clean
it up and submit a PR with a diff.

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

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Wed, Jan 30, 2013 at 7:27 AM, James ja...@hicag.org wrote:
 I was able to correct the problem as well by prefixing strnvis, avoiding the
 symbol collision. I also found PR: ports/172941 which also has a fix.

 Using my patch or the patch in ports/172941 fixes the segfault for me in
 stable/9. However, I quickly ran into another problem. I can't remember the
 error message exactly, it was something like Unable to initialize PAM:
 Unknown file descriptor. A ktrace didn't reveal anything obvious. I'll try
 to test it out tomorrow.

 --
 James.

Try the attached patch. Just drop it into
/usr/ports/security/pam_ssh_agent_auth/files directory and recompile.

This will make the port use the system strnvis() with correctly
ordered arguments if one is available (HAVE_STRNVIS defined) and an
_openbsd suffixed version if not.


-Kimmo
--- 
../../../pam_ssh_agent_auth/work/pam_ssh_agent_auth-0.9.3/openbsd-compat/vis.h  
2009-01-05 09:31:07.0 +0200
+++ openbsd-compat/vis.h2013-01-30 07:13:19.782431257 +0200
@@ -79,15 +79,16 @@
  */
 #defineUNVIS_END   1   /* no more characters */
 
-char   *vis(char *, int, int, int);
-intstrvis(char *, const char *, int);
-intstrnvis(char *, const char *, size_t, int)
+
+char   *vis_openbsd(char *, int, int, int);
+intstrvis_openbsd(char *, const char *, int);
+intstrnvis_openbsd(char *, const char *, size_t, int)
__attribute__ ((__bounded__(__string__,1,3)));
-intstrvisx(char *, const char *, size_t, int)
+intstrvisx_openbsd(char *, const char *, size_t, int)
__attribute__ ((__bounded__(__string__,1,3)));
-intstrunvis(char *, const char *);
-intunvis(char *, char, int *, int);
-ssize_t strnunvis(char *, const char *, size_t)
+intstrunvis_openbsd(char *, const char *);
+intunvis_openbsd(char *, char, int *, int);
+ssize_t strnunvis_openbsd(char *, const char *, size_t)
__attribute__ ((__bounded__(__string__,1,3)));
 
 #endif /* !_VIS_H_ */
--- ../../../pam_ssh_agent_auth/work/pam_ssh_agent_auth-0.9.3/log.c 
2013-01-30 07:09:24.325405879 +0200
+++ log.c   2013-01-30 07:14:13.708422511 +0200
@@ -360,9 +360,13 @@
snprintf(fmtbuf, sizeof(fmtbuf), %s: %s, preface, fmt);
vsnprintf(msgbuf, sizeof(msgbuf), fmtbuf, args);
}
-
-   strnvis(fmtbuf, msgbuf, sizeof(fmtbuf),
+#if defined (HAVE_STRNVIS)
+   strnvis(fmtbuf, sizeof(fmtbuf), msgbuf,
+   log_on_stderr ? LOG_STDERR_VIS : LOG_SYSLOG_VIS);
+#else
+   strnvis_openbsd(fmtbuf, msgbuf, sizeof(fmtbuf),
log_on_stderr ? LOG_STDERR_VIS : LOG_SYSLOG_VIS);
+#endif
 
 if(level == SYSLOG_LEVEL_FATAL) {
snprintf(msgbuf, sizeof msgbuf, %s\r\nThis incident has been 
reported to the authorities\r\n, fmtbuf);
--- 
../../../pam_ssh_agent_auth/work/pam_ssh_agent_auth-0.9.3/openbsd-compat/vis.c  
2009-01-05 09:31:07.0 +0200
+++ openbsd-compat/vis.c2013-01-30 07:31:50.516441571 +0200
@@ -54,7 +54,7 @@
  * vis - visually encode characters
  */
 char *
-vis(char *dst, int c, int flag, int nextc)
+vis_openbsd(char *dst, int c, int flag, int nextc)
 {
if (isvisible(c)) {
*dst++ = c;
@@ -151,19 +151,19 @@
  * This is useful for encoding a block of data.
  */
 int
-strvis(char *dst, const char *src, int flag)
+strvis_openbsd(char *dst, const char *src, int flag)
 {
char c;
char *start;
 
for (start = dst; (c = *src);)
-   dst = vis(dst, c, flag, *++src);
+   dst = vis_openbsd(dst, c, flag, *++src);
*dst = '\0';
return (dst - start);
 }
 
 int
-strnvis(char *dst, const char *src, size_t siz, int flag)
+strnvis_openbsd(char *dst, const char *src, size_t siz, int flag)
 {
char *start, *end;
char tbuf[5];
@@ -186,7 +186,7 @@
}
src++;
} else {
-   i = vis(tbuf, c, flag, *++src) - tbuf;
+   i = vis_openbsd(tbuf, c, flag, *++src) - tbuf;
if (dst + i = end) {
memcpy(dst, tbuf, i);
dst += i;
@@ -201,23 +201,23 @@
if (dst + i  end) {
/* adjust return value for truncation */
while ((c = *src))
-   dst += vis(tbuf, c, flag, *++src) - tbuf;
+   dst += vis_openbsd(tbuf, c, flag, *++src) - tbuf;
}
return (dst - start);
 }
 
 int
-strvisx(char *dst, const char *src, size_t len, int flag)
+strvisx_openbsd(char *dst, const char *src, size_t len, int flag)
 {
char c;
char *start;
 
for (start = dst; len  1; len--) {
c = *src;
-   dst = vis(dst, c, flag, *++src);
+   dst = vis_openbsd(dst, c, flag, *++src);
}
if (len)
-   dst = vis(dst, *src, flag, '\0');
+ 

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Thu, Jan 17, 2013 at 2:11 AM, Brooks Davis bro...@freebsd.org wrote:
 On Wed, Jan 16, 2013 at 08:01:00PM +0200, Kimmo Paasiala wrote:
 On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric d...@freebsd.org wrote:
  On 2013-01-16 13:05, Kimmo Paasiala wrote:
 
  I just updated my stable/9 system after clang3.2 was added. My system
  is amd64, both world and kernel are compiled with clang3.2 and the
  default compiler is clang. I'm tracking the sources with GIT and the
  version I have corresponds to SVN revision r245451.
 
  Everything else seems to work but the pam authentication module
  security/pam_ssh_agent_auth segfaults immediately.
 
  ...
 
  #0  0x000800ef2070 in strsvis () from /lib/libc.so.7
  #1  0x000800ef2584 in strvis () from /lib/libc.so.7
  #2  0x000800ef25e5 in strnvis () from /lib/libc.so.7
  #3  0x000801c0e2e7 in do_log () from
  /usr/local/lib/pam_ssh_agent_auth.so
  #4  0x000801c0e4ff in logit () from
  /usr/local/lib/pam_ssh_agent_auth.so
 
  ...
 
  The str*vis() calls suggest that it's something in the libc maybe?
 
 
  Brooks merged the new strvis implementations in r245439, so you may have
  run into a bug with them.  I don't think this is caused specifically by
  clang, at least not without more proof. :-)
 
  Can you try reverting to the revision just before r245439, rebuilding
  and reinstalling at least libc, and see if the pam_ssh_agent_auth crash
  goes away?

 I'm rebuilding world now. Took me some time to figure out how to
 revert the commits in git. I'll report back once finished.

 NetBSD and OpenBSD use different signatures for strnvis(). :(
 pam_ssh_agent_auth assumes that if the system has one it is the OpenBSD
 one but ours is the NetBSD one.  The port will need to be patched to use
 the openbsd version like it was doing or to swap the second and third
 arguments when build on newer versions of FreeBSD.

 -- Brooks

It turns out that security/pam_ssh_agent_auth compiles its own version
of strnvis() when HAVE_STRNVIS is not defined. This in turn results in
an exported dynamic strnvis symbol in the plugin binary. I guess
that's what is breaking things when the plugin binary is loaded on
post r245439 world.

First thing that comes to my mind for a fix is renaming the local
strnvis() to something else conditionally based on HAVE_STRNVIS.

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

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Thu, Jan 17, 2013 at 5:15 PM, Dimitry Andric d...@freebsd.org wrote:
 On 2013-01-17 14:07, Kimmo Paasiala wrote:

 On Thu, Jan 17, 2013 at 2:11 AM, Brooks Davis bro...@freebsd.org wrote:

 ...

 NetBSD and OpenBSD use different signatures for strnvis(). :(
 pam_ssh_agent_auth assumes that if the system has one it is the OpenBSD
 one but ours is the NetBSD one.  The port will need to be patched to use
 the openbsd version like it was doing or to swap the second and third
 arguments when build on newer versions of FreeBSD.

 It turns out that security/pam_ssh_agent_auth compiles its own version

 of strnvis() when HAVE_STRNVIS is not defined. This in turn results in
 an exported dynamic strnvis symbol in the plugin binary. I guess
 that's what is breaking things when the plugin binary is loaded on
 post r245439 world.

 First thing that comes to my mind for a fix is renaming the local
 strnvis() to something else conditionally based on HAVE_STRNVIS.


 Please try the following patch, which tells configure that HAVE_STRNVIS
 is always false.  I think this is the easiest way, unless we really want
 the port to use our own strnvis.

This will still leave the exported symbol in the plugin binary with
the name strnvis. What would be needed is renaming of the function to
something else, like pam_ssh_agent_auth_strnvis(), maybe using a macro

#define strnvis pam_ssh_agent_auth_strnvis

somewhere.

I can try my hand on coming up with a fix but its going to take some
time, the source code of the plugin and not to mention the configure
script look quite hairy.

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

CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

Hello list.

I just updated my stable/9 system after clang3.2 was added. My system
is amd64, both world and kernel are compiled with clang3.2 and the
default compiler is clang. I'm tracking the sources with GIT and the
version I have corresponds to SVN revision r245451.

Everything else seems to work but the pam authentication module
security/pam_ssh_agent_auth segfaults immediately.

The version I had was compiled in a releng/9.1 jail using poudriere
with clang as the default compiler. I recompiled the port with the new
clang3.2 compiler but no difference.

Here is the backtrace from gdb when I run su(1) as root with the
suitable settings to force the use of the plugin:

(gdb) run
Starting program: /usr/bin/su
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x000800ef2070 in strsvis () from /lib/libc.so.7
(gdb) bt
#0  0x000800ef2070 in strsvis () from /lib/libc.so.7
#1  0x000800ef2584 in strvis () from /lib/libc.so.7
#2  0x000800ef25e5 in strnvis () from /lib/libc.so.7
#3  0x000801c0e2e7 in do_log () from /usr/local/lib/pam_ssh_agent_auth.so
#4  0x000801c0e4ff in logit () from /usr/local/lib/pam_ssh_agent_auth.so
#5  0x000801c116f4 in pam_user_key_allowed2 () from
/usr/local/lib/pam_ssh_agent_auth.so
#6  0x000801c11f1e in pam_user_key_allowed () from
/usr/local/lib/pam_ssh_agent_auth.so
#7  0x000801c11a18 in userauth_pubkey_from_id () from
/usr/local/lib/pam_ssh_agent_auth.so
#8  0x000801c118fa in find_authorized_keys () from
/usr/local/lib/pam_ssh_agent_auth.so
#9  0x000801c122e5 in pam_sm_authenticate () from
/usr/local/lib/pam_ssh_agent_auth.so
#10 0x000800a343e0 in openpam_dispatch () from /usr/lib/libpam.so.5
#11 0x000800a33946 in pam_authenticate () from /usr/lib/libpam.so.5
#12 0x004020b8 in ?? ()
#13 0x00401c61 in ?? ()
#14 0x00080061f000 in ?? ()
#15 0x in ?? ()

The str*vis() calls suggest that it's something in the libc maybe?


Regards,

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

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric d...@freebsd.org wrote:
 On 2013-01-16 13:05, Kimmo Paasiala wrote:

 I just updated my stable/9 system after clang3.2 was added. My system
 is amd64, both world and kernel are compiled with clang3.2 and the
 default compiler is clang. I'm tracking the sources with GIT and the
 version I have corresponds to SVN revision r245451.

 Everything else seems to work but the pam authentication module
 security/pam_ssh_agent_auth segfaults immediately.

 ...

 #0  0x000800ef2070 in strsvis () from /lib/libc.so.7
 #1  0x000800ef2584 in strvis () from /lib/libc.so.7
 #2  0x000800ef25e5 in strnvis () from /lib/libc.so.7
 #3  0x000801c0e2e7 in do_log () from
 /usr/local/lib/pam_ssh_agent_auth.so
 #4  0x000801c0e4ff in logit () from
 /usr/local/lib/pam_ssh_agent_auth.so

 ...

 The str*vis() calls suggest that it's something in the libc maybe?


 Brooks merged the new strvis implementations in r245439, so you may have
 run into a bug with them.  I don't think this is caused specifically by
 clang, at least not without more proof. :-)

 Can you try reverting to the revision just before r245439, rebuilding
 and reinstalling at least libc, and see if the pam_ssh_agent_auth crash
 goes away?

I'm rebuilding world now. Took me some time to figure out how to
revert the commits in git. I'll report back once finished.

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

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Thu, Jan 17, 2013 at 2:11 AM, Brooks Davis bro...@freebsd.org wrote:
 On Wed, Jan 16, 2013 at 08:01:00PM +0200, Kimmo Paasiala wrote:
 On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric d...@freebsd.org wrote:
  On 2013-01-16 13:05, Kimmo Paasiala wrote:
 
  I just updated my stable/9 system after clang3.2 was added. My system
  is amd64, both world and kernel are compiled with clang3.2 and the
  default compiler is clang. I'm tracking the sources with GIT and the
  version I have corresponds to SVN revision r245451.
 
  Everything else seems to work but the pam authentication module
  security/pam_ssh_agent_auth segfaults immediately.
 
  ...
 
  #0  0x000800ef2070 in strsvis () from /lib/libc.so.7
  #1  0x000800ef2584 in strvis () from /lib/libc.so.7
  #2  0x000800ef25e5 in strnvis () from /lib/libc.so.7
  #3  0x000801c0e2e7 in do_log () from
  /usr/local/lib/pam_ssh_agent_auth.so
  #4  0x000801c0e4ff in logit () from
  /usr/local/lib/pam_ssh_agent_auth.so
 
  ...
 
  The str*vis() calls suggest that it's something in the libc maybe?
 
 
  Brooks merged the new strvis implementations in r245439, so you may have
  run into a bug with them.  I don't think this is caused specifically by
  clang, at least not without more proof. :-)
 
  Can you try reverting to the revision just before r245439, rebuilding
  and reinstalling at least libc, and see if the pam_ssh_agent_auth crash
  goes away?

 I'm rebuilding world now. Took me some time to figure out how to
 revert the commits in git. I'll report back once finished.

 NetBSD and OpenBSD use different signatures for strnvis(). :(
 pam_ssh_agent_auth assumes that if the system has one it is the OpenBSD
 one but ours is the NetBSD one.  The port will need to be patched to use
 the openbsd version like it was doing or to swap the second and third
 arguments when build on newer versions of FreeBSD.

 -- Brooks

Doesn't the change to strnvis() break the ABI on FreeBSD 9.X? I
thought you could always compile a binary on an earlier version of
FreeBSD 9.X and trust it to work without recompiling on any later
minor version of the same major version line.

(dynamic link libraries that are from ports excluded of course)

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Thu, Dec 27, 2012 at 11:42 PM, Phil Kulin sch...@gmail.com wrote:
 2012/12/26 Kimmo Paasiala kpaas...@gmail.com:

 I've revised the patch again and updated it at gihub,
 https://gist.github.com/4362018.  It can now be applied at top level
 of sources (/usr/src typically). It now does the deconfiguration in
 reverse order of the configuration, meaning the aliases configured
 with ipv6_addrs_IF are removed before the ones configured with
 ifconfig_IF_aliasN=inet6 

 Adapted for FreeBSD 8.2, works fine:

 --- network.subr.orig   2011-02-17 05:19:39.0 +0300
 +++ network.subr2012-12-28 00:46:38.0 +0400
 @@ -312,6 +312,12 @@ afexists()
  #  1 otherwise.
  ipv6if()
  {
 +   # Test for $ipv6_addrs_IF. If it exists then the
 +   # interface should be configured for IPv6
 +   _tmpargs=$(get_if_var $_if ipv6_addrs_IF)
 +   if [ -n ${_tmpargs} ]; then
 +   return 0
 +   fi
 if ! checkyesno ipv6_enable; then
 return 1
 fi
 @@ -948,7 +954,12 @@ network6_interface_setup()
 rtsol_interface=no
 ifconfig $i inet6 ${ipv6_ifconfig} alias
 fi
 -
 +   ipv6_addrs=`get_if_var $i ipv6_addrs_IF`
 +   if [ -n ${ipv6_addrs} ]; then
 +   rtsol_available=no
 +   rtsol_interface=no
 +   ipv6_addrs_common ${i} alias
 +   fi
 # Wireless NIC cards are virtualized through the wlan 
 interface
 if ! is_wired_interface ${i}; then
 case ${i} in
 @@ -1178,3 +1189,39 @@ network6_getladdr()
 esac
 done
  }
 +
 +ipv6_addrs_common()
 +{
 +   local _ret _if _action _ip6prefix _ip6prefixes
 +   local _ip6addr _prefixlen
 +   local _range _ip6net _ip6low _ip6high
 +   _ret=1
 +   _if=$1
 +   _action=$2
 +   # get the prefixes from ipv6_addrs_IF variable
 +   _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
 +   for _ip6prefix in ${_ip6prefixes}; do
 +   _ip6addr=${_ip6prefix%%/*}
 +   _prefixlen=${_ip6prefix##*/}
 +   _range=${_ip6addr##*:}
 +   _ip6net=${_ip6addr%:*}
 +   _ip6low=${_range%-*}
 +   _ip6high=${_range#*-}
 +   # If deleting an alias, set _prefixlen to null string.
 +   if [ ${_action} = -alias ]; then
 +   _prefixlen=
 +   else
 +   _prefixlen=prefixlen $_prefixlen
 +   fi
 +   _ip6high=$((0x${_ip6high}))
 +   _ip6count=$((0x${_ip6low}))
 +   while [ ${_ip6count} -le ${_ip6high} ]; do
 +   # Re-uses the _ip6addr variable from above
 +   _ip6addr=$(printf %x ${_ip6count})
 +   eval ifconfig ${_if} inet6
 ${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}
 +   _ip6count=$((${_ip6count}+1))
 +   _ret=0
 +   done
 +   done
 +   return $_ret
 +}


 --
 Non nobis Domine non nobis sed Nomini Tuo da gloriam
 Phil Kulin

I don't have an 8.X system to test but I guess it's fine.

Any more interest in this? I'd love to see this added, not because I
wrote it but because I want to contribute in any way I can.

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

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Wed, Jan 16, 2013 at 8:01 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Wed, Jan 16, 2013 at 6:15 PM, Dimitry Andric d...@freebsd.org wrote:
 On 2013-01-16 13:05, Kimmo Paasiala wrote:

 I just updated my stable/9 system after clang3.2 was added. My system
 is amd64, both world and kernel are compiled with clang3.2 and the
 default compiler is clang. I'm tracking the sources with GIT and the
 version I have corresponds to SVN revision r245451.

 Everything else seems to work but the pam authentication module
 security/pam_ssh_agent_auth segfaults immediately.

 ...

 #0  0x000800ef2070 in strsvis () from /lib/libc.so.7
 #1  0x000800ef2584 in strvis () from /lib/libc.so.7
 #2  0x000800ef25e5 in strnvis () from /lib/libc.so.7
 #3  0x000801c0e2e7 in do_log () from
 /usr/local/lib/pam_ssh_agent_auth.so
 #4  0x000801c0e4ff in logit () from
 /usr/local/lib/pam_ssh_agent_auth.so

 ...

 The str*vis() calls suggest that it's something in the libc maybe?


 Brooks merged the new strvis implementations in r245439, so you may have
 run into a bug with them.  I don't think this is caused specifically by
 clang, at least not without more proof. :-)

 Can you try reverting to the revision just before r245439, rebuilding
 and reinstalling at least libc, and see if the pam_ssh_agent_auth crash
 goes away?


Confirmed. Reverting world to one commit before r245439 and using the
version of the port I used before fixes the problem.

Trying to use the version I compiled with post r245439 world results
in su: pam_start: system error when used on pre r245439 world.

I have to repeat my question, isn't this the definition of ABI breakage?

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

Re: CLANG 3.2 breaks security/pam_ssh_agent_auth on stable/9

[Kimmo Paasiala]

On Thu, Jan 17, 2013 at 9:33 AM, Ben Morrow b...@morrow.me.uk wrote:
 Quoth Kimmo Paasiala kpaas...@gmail.com:

 Doesn't the change to strnvis() break the ABI on FreeBSD 9.X? I
 thought you could always compile a binary on an earlier version of
 FreeBSD 9.X and trust it to work without recompiling on any later
 minor version of the same major version line.

 No, it doesn't. No existing prototypes are changed, there are just a
 number of *nvis* functions added to complement the existing ones that
 didn't have length arguments. The only problem is that the port assumes
 that if a system has strnvis, it has a prototype matching OpenBSD's,
 which the new one doesn't.

 Ben


Aah yes, thanks for clarification. I'll submit a PR about the port then.

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

Re: Does / Is anyone maintaining CVS for FreeBSD?

[Kimmo Paasiala]

On Fri, Jan 4, 2013 at 6:45 AM, Dewayne Geraghty
dewayne.gerag...@heuristicsystems.com.au wrote:
 -Original Message-
 From: owner-freebsd-sta...@freebsd.org
 [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of Erich Dollansky
 Sent: Friday, 4 January 2013 12:26 PM
 To: Patrick M. Hausen
 Cc: Eitan Adler; freebsd-stable@freebsd.org
 Subject: Re: Does / Is anyone maintaining CVS for FreeBSD?

 Hi,

 On Thu, 3 Jan 2013 18:48:01 +0100
 Patrick M. Hausen hau...@punkt.de wrote:

  Hello,
 
  Am 03.01.2013 um 16:36 schrieb Eitan Adler li...@eitanadler.com:
   CVS/SVN should be considered a development tool.  Users
 should not
   see the impact of the switch.  In theory.
 
 
  What is the recommended csup replacement for users that did
 
  cd /usr/src  make update buildworld buildkernel
 
  as their method of keeping the system current?

 the above's line keeps the originally installed sources
 intact and just recompiles them again and again and again ...
 
  I'm a bit reluctant to installing svn on every system that needs
  source updates. Are there more lightweight ways?
 
 The line above will stay the same. Only the process of
 downloading the changes will change.

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

 Erich, If there's a more lightweight way than :
 1. cd /usr/ports/devel/subversion
 2. turning off all options
 3. turn on these options: ENHANCED_KEYWORD P4_STYLE_MARKERS STATIC
 4. make install
 5. Copy the svn as needed. The image should be 4.2MB
 Then I'd be happy to adopt.

 Regards, Dewayne.


Even better,

4. make package
5. pkg_install or 'pkg install' the created package on the other machines.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Does / Is anyone maintaining CVS for FreeBSD?

[Kimmo Paasiala]

On Wed, Jan 2, 2013 at 12:51 AM, Matthias Andree mand...@freebsd.org wrote:
 Am 31.12.2012 21:40, schrieb Chris H:

 IM(NS)HO; SVN is an inferior RCS created so Windows users wouldn't feel
 left out.

 No, and it has nothing to do with Windows.  CVS does work on Windows.

 SVN 1.5 or newer is CVS done right, if you want the server-client split
 model, and can waive the distributed nature of Mercurial, Git, or
 Bazaar-NG.

 For those who abuse CVS as content distribution and management system to
 just peek at individual files, it may not matter, and the pain of
 migrating to SVN may dominate, but if you have ever manually assembled a
 list of versions for how to merge because someone else branched in CVS
 without laying proper tags, you know why CVS must be replaced.

It's completely laughable to try to put a yet another dumbed down
tool for windows users label on Subversion. It's not. To the OP of
this thread, do your homework before you make such claims.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Does / Is anyone maintaining CVS for FreeBSD?

[Kimmo Paasiala]

On Tue, Jan 1, 2013 at 3:21 AM, Alfred Perlstein bri...@mu.org wrote:
 There are arguments on both sides; some (perhaps you) feel SVN has/
 provides more options, others (maybe myself) feel the same can be
 accomplished with CVS, and that migration only causes more initial
 (and unnecessary) overhead. I'll leave it at that. :)

 Chris,

 I think you've gotten to your NYE jubilations a bit early.

 Sure the same can be accomplished by CVS, the same way a mission to the moon
 could be accomplished with enough black powder and a sailing ship.

 It just won't be a pleasant trip.

 Go finish whatever you're drinking and have a great 2013.

 When you wake up, go crack a book on SVN and you'll only be living in 2007.


 -Alfred


Anyone who has had the pleasure of being an admin charge of a CVS
repository will not want to go back to it after discovering what SVN
and GIT have to offer.

Just my 2c

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

Re: 9.1 minimal ram requirements

[Kimmo Paasiala]

On Sat, Dec 29, 2012 at 1:46 PM, Thomas Mueller muelle...@insightbb.com wrote:
 from Mark Linimon lini...@lonesome.com:

 In an ideal world, the bits that will almost certainly become FreeBSD 9.1
 would not appear on the masters, or any of the mirrors, until the same
 instant that the release announcement is set to freebsd-annou...@freebsd.org.

 In practice this doesn't happen.  If there is some clever way for that to
 happen, we haven't found it yet.

 It has happened in the past that even as the release bits were propogating,
 One Last Big Bug was found and those bits had to be pulled and re-done.  It
 would have looked like you had FreeBSD Release X.Y but you wouldn't have had
 the final bits that everyone else did.

 I understand your frustration that this process takes days, and in general
 the frustration with this particular release -- more than you could possibly
 believe.  However, until we figure out the process that would exist in an
 ideal world, this is what we have, and so if you need something that will be
 in 9.1, your options at this moment are: build an install from 9-STABLE; find
 one of the snapshots (and no, I am not the one to ask, sorry); or wait.

 Sorry, but that's the best I can offer right now.

 mcl

 So that's why I downloaded-updated source tree using svn, built and installed,
 and uname -a revealed 9.1-PRERELEASE.  It seemed strange after 9.1-RELEASE
 became available on FTP servers December 5.  Maybe they can do something to
 better document device ctl in GENERIC; I kept it because it was there, and
 one is led to think it is needed due to changes in FreeBSD.


 Tom

Most likely you took the stable/9 aka 9-STABLE sources. They have
internal name 9.1-PRERELEASE until the 9.1-RELEASE goes out of the
door.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1 minimal ram requirements

[Kimmo Paasiala]

On Sat, Dec 29, 2012 at 1:59 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sat, Dec 29, 2012 at 1:46 PM, Thomas Mueller muelle...@insightbb.com 
 wrote:
 from Mark Linimon lini...@lonesome.com:

 In an ideal world, the bits that will almost certainly become FreeBSD 9.1
 would not appear on the masters, or any of the mirrors, until the same
 instant that the release announcement is set to 
 freebsd-annou...@freebsd.org.

 In practice this doesn't happen.  If there is some clever way for that to
 happen, we haven't found it yet.

 It has happened in the past that even as the release bits were propogating,
 One Last Big Bug was found and those bits had to be pulled and re-done.  It
 would have looked like you had FreeBSD Release X.Y but you wouldn't have had
 the final bits that everyone else did.

 I understand your frustration that this process takes days, and in general
 the frustration with this particular release -- more than you could possibly
 believe.  However, until we figure out the process that would exist in an
 ideal world, this is what we have, and so if you need something that will be
 in 9.1, your options at this moment are: build an install from 9-STABLE; 
 find
 one of the snapshots (and no, I am not the one to ask, sorry); or wait.

 Sorry, but that's the best I can offer right now.

 mcl

 So that's why I downloaded-updated source tree using svn, built and 
 installed,
 and uname -a revealed 9.1-PRERELEASE.  It seemed strange after 9.1-RELEASE
 became available on FTP servers December 5.  Maybe they can do something to
 better document device ctl in GENERIC; I kept it because it was there, and
 one is led to think it is needed due to changes in FreeBSD.


 Tom

 Most likely you took the stable/9 aka 9-STABLE sources. They have
 internal name 9.1-PRERELEASE until the 9.1-RELEASE goes out of the
 door.

Erm too little coffee this early... I should have written IF you are
following stable/9 aka 9-STABLE the 9.1-PRERELEASE is what you will
see as the internal name until 9.1-RELEASE is released.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-RC3: xorg-input-mouse, xfce4-panel

[Kimmo Paasiala]

On Fri, Dec 28, 2012 at 1:33 PM, CeDeROM cede...@tlen.pl wrote:
 On Thu, Dec 27, 2012 at 6:07 PM, Jakub Lach jakub_l...@mailplus.pl wrote:
 xf86-input-mouse-1.8.1 is in dev trunk xorg tree. (see -x11).

 This is the only sensible solution to use new driver. HAL and
 AllowEmptyInput are EXCLUSIVE and cause very strange behavior - I have
 just noticed that again on another desktop - screen is refreshed AFTER
 mouse is moved heh...

 Still I cannot see the new 1.8.1 driver after updating the port
 tree... cannot wait to see that one, still I think this is a must for
 a release package :-)

 Best regards :-)
 Tomek

 --
 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

You're misunderstanding a few things. There are no release packages
for any release of FreeBSD. What you have on the install discs are
just snapshot packages built from the ports tree as it happened to
be at the time of the release was made. If you want to see the newer
mouse driver in ports help the xorg developers by testing their
experimental tree. There's nothing to be done about the 9.1-RELEASE,
the packages on the install discs will not have any experimental
content.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-RC3: xorg-input-mouse, xfce4-panel

[Kimmo Paasiala]

On Fri, Dec 28, 2012 at 1:51 PM, CeDeROM cede...@tlen.pl wrote:
 On Fri, Dec 28, 2012 at 12:42 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 You're misunderstanding a few things. There are no release packages
 for any release of FreeBSD. What you have on the install discs are
 just snapshot packages built from the ports tree as it happened (...)

 I know, I hoped 1.7.2 driver or 1.8.1 can get into a port tree before
 packages for 9.1 are built and released. When I applied a patch (some
 structure fields initialization) from 1.7.2 on current 1.7.1 driver
 problem of detection and strange mouse behavior was gone. If 1.7.1
 gets into the packages lots of people will report this issue... thats
 all.

 Best regards :-)
 Tomek

 --
 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Related to this,

It doesn't look like the FreeBSD ports SVN repository is used to its
full potential. SVN allows branching and creation of experimental
versions of the tree very easily and cheaply, yet all the experimental
repositories references so far are stored in some external
repositories, github or elsewhere.

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

Re: 9.1-RC3: xorg-input-mouse, xfce4-panel

[Kimmo Paasiala]

On Fri, Dec 28, 2012 at 2:08 PM, CeDeROM cede...@tlen.pl wrote:
 On Fri, Dec 28, 2012 at 1:02 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 It doesn't look like the FreeBSD ports SVN repository is used to its
 full potential. (...)

 Yea, btw why FreeBSD does not use GIT? I have been using it for some
 time and I have not seen better source code revision utility. GIT is
 really amazing, SVN/CVS seems to be a file revision control, while GIT
 is the source code revision control, this tool surprises me all the
 time with its great features :-)

 --
 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

I would personally use GIT but I'm ok with SVN too. I absolutely hate
CVS :P  My point is really that why not centralise all the development
that happens around the ports tree. The infrastructure is there
already.

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

Re: FreeBSD 9.1-PRERELEASE

[Kimmo Paasiala]

On Thu, Dec 27, 2012 at 11:53 AM, Jack Raats j...@jarasoft.net wrote:
 Hi,

 In this mailinglist I'm reading a lot about problems (re)compiling the 
 system. At this moment I'm running:
 FreeBSD 9.1-PRERELEASE (ORAC) #0 r244047: Sun Dec  9 15:33:19 CET 2012 
 without problems.

 Is it save to recompile the system with all patches?

 Thanks
 Jack Raats
 ___


You're seeing just the tip of the iceberg meaning only those who do
have problems building the OS from sources and are following the
mailing lists post on them. There's potentially thousands or even much
more of those who are following 9-STABLE and never encounter a problem
they can not solve on their own.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Anothe pkgng question: signing a repository

[Kimmo Paasiala]

On Thu, Dec 27, 2012 at 6:22 PM, Rainer Duffner rai...@ultra-secure.de wrote:
 Hi,

 I'm creating my own repository and have created a key for it.

 I've created a CSR for it and used that to generate a certificate via
 our internal CA. Because there was no other information available, I
 used the profile that we use to generate SSL-certificates for web
 servers.

 I copied the certificate to the server and adjusted pkg.conf, but when I
 want to query the repository, I get:

 root@server:/etc/ssl/cert # pkg install net-snmpd
 Updating repository catalogue
 repo.txz
 100%  219KB 219.5KB/s 219.5KB/s   00:00 pkg: error reading public
 key(/etc/ssl/pkg.conf): error:0906D06C:PEM routines:PEM_read_bio:no
 start line pkg: Invalid signature, removing repository.


 What does pkg expect to be in this file?


 openssl x509 displays the data for the certificate correctly, so I
 really don't know what's missing.

 I ktraced pkg and it is indeed reading the file.




 Best Regards
 Rainer


See Glen Barber's page about Maintaining your own pkgng repository.

https://glenbarber.us/2012/06/11/Maintaining-Your-Own-pkgng-Repository.html

HTH

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Mon, Dec 24, 2012 at 6:07 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sat, Dec 22, 2012 at 7:49 PM, Łukasz Wąsikowski
 luk...@wasikowski.net wrote:
 W dniu 2012-12-22 18:14, Ben Morrow pisze:
 Quoth =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= luk...@wasikowski.net:
 W dniu 2012-12-22 04:41, Kimmo Paasiala pisze:

 Yeah, this is problem in network.subr. An interface is not recognized
 as IPv6 capable if the interface is not in ipv6_network_interfaces
 and there's no ifconfig_IF_ipv6 in rc.conf(5), bummer. For IPv4 it
 just works because the interface is always assumed to be IPv4
 capable.

 Ok, I used ifconfig_em0_ipv6=up and it worked. So it looks like this:

 The documented way to do this is to just set the link-local address in
 ifconfig_IF_ipv6, since an interface is required to have a link-local
 address. Either configure an fe80:: address explicitly or set

 ifconfig_em0_ipv6=inet6 auto_linklocal

 Alternatively, if you set ipv6_activate_all_interfaces all interfaces
 will be considered IPv6-capable.

 link-local address is assigned by default, even with ifconfig_IF_ipv6=up.

 root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf ; ifconfig
 em0 | grep -E '^[[:space:]]*inet6' | head -2
 hostname=freebsd
 ifconfig_em0=up
 ipv4_addrs_em0=192.168.168.20-24/24
 defaultrouter=192.168.168.1
 ipv6_network_interfaces=em0
 ipv6_defaultrouter=2001:6a0:1cb::
 ifconfig_em0_ipv6=up
 ipv6_addrs_em0=2001:6a0:1cb::1-e/128
 sshd_enable=YES
 dumpdev=NO
 named_enable=YES
 inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
 inet6 2001:6a0:1cb::1 prefixlen 128

 Of course using inet6 auto_linklocal instead of up seems a better
 way to do it, thank you for this tip.

 --
 best regards,
 Lukasz Wasikowski


 I have put up the patch at github as:

 https://gist.github.com/4362018

 This version should work with just the ipv6_addrs_IF in rc.conf(5). I
 changed the detection of ipv6 interfaces so that just having the
 ipv6_addrs_IF line is enough.

 -Kimmo

I've revised the patch again and updated it at gihub,
https://gist.github.com/4362018.  It can now be applied at top level
of sources (/usr/src typically). It now does the deconfiguration in
reverse order of the configuration, meaning the aliases configured
with ipv6_addrs_IF are removed before the ones configured with
ifconfig_IF_aliasN=inet6 

Also as noted in my previous message it's possible to configure all
IPv6 addresses with a single ipv6_addrs_IF line in rc.conf:

ipv6_addrs_re0=2001:db8::::1-4/64


I consider this version of the patch pretty much completed work. It
applies cleanly to HEAD version r244694 and I don't see why it
wouldn't work in HEAD as well.

Now, is there any interest in seeing this feature as part of future
versions of FreeBSD? Could it be incorporated to HEAD and then MFC'ed
to 9-STABLE  if it turns out it's seen as a useful feature?

Regards,

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

Re: 9.1 minimal ram requirements

[Kimmo Paasiala]

On Wed, Dec 26, 2012 at 7:43 PM, Zoran Kolic zko...@sbb.rs wrote:
 9.1-RC3 works just fine as well for some weeks :-) When your computers
 are not production machines I also recommend this to you Zoran to test
 RC in order to make RELEASE a better product. What you have now is
 labeled as RELEASE but it is a decoration. The RELEASE will be
 different from what you have found and installed (I think there are
 already versions with different tags available). This is really the
 thing that pushed me away from Linux :-(

 I removed the line and it booted just fine.
 To me, 9.1 is probably the best looking release, but
 it might be due to new hardware.

 I'n not aware what is going on, regarding release or
 release. At full speed I support the way devel team
 does the work. And contrary, the team has to bear with
 users, who want to know. I had new desktop and new
 laptop waiting, since power surge killed some devices
 at my home. And I waited for 3 months. None could say
 I was impatient. The release image is on the site. And,
 if you change RC3 to RELEASE in browser, there is even
 more. Why would serious guys keep those files available,
 if not for usage?
 My best guess is that some packages compile made all
 that fuss. What else might be?
 Best regards

  Zoran


You are correct, the hold up that has kept the release from being
announced is the recent security incident that could have compromised
the package build clusters. It looks like everything is all right
after all.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: [HEADSUP] zfs root pool mounting

[Kimmo Paasiala]

On Sun, Dec 23, 2012 at 2:49 PM, Andriy Gapon a...@freebsd.org wrote:
 on 23/12/2012 14:34 Kimmo Paasiala said the following:
 On Sun, Dec 23, 2012 at 2:28 PM, Andriy Gapon a...@freebsd.org wrote:

 I have MFCed the following change, so please double-check if you might be
 affected.  Preferably before upgrading :-)

 on 28/11/2012 20:35 Andriy Gapon said the following:

 Recently some changes were made to how a root pool is opened for root 
 filesystem
 mounting.  Previously the root pool had to be present in zpool.cache.  Now 
 it is
 automatically discovered by probing available GEOM providers.
 The new scheme is believed to be more flexible.  For example, it allows to 
 prepare
 a new root pool at one system, then export it and then boot from it on a 
 new
 system without doing any extra/magical steps with zpool.cache.  It could 
 also be
 convenient after zpool split and in some other situations.

 The change was introduced via multiple commits, the latest relevant 
 revision in
 head is r243502.  The changes are partially MFC-ed, the remaining parts are
 scheduled to be MFC-ed soon.

 I have received a report that the change caused a problem with booting on 
 at least
 one system.  The problem has been identified as an issue in local 
 environment and
 has been fixed.  Please read on to see if you might be affected when you 
 upgrade,
 so that you can avoid any unnecessary surprises.

 You might be affected if you ever had a pool named the same as your 
 current root
 pool.  And you still have any disks connected to your system that belonged 
 to that
 pool (in whole or via some partitions).  And that pool was never properly
 destroyed using zpool destroy, but merely abandoned (its disks
 re-purposed/re-partitioned/reused).

 If all of the above are true, then I recommend that you run 'zdb -l 
 disk' for
 all suspect disks and their partitions (or just all disks and partitions). 
  If
 this command reports at least one valid ZFS label for a disk or a 
 partition that
 do not belong to any current pool, then the problem may affect you.

 The best course is to remove the offending labels.

 If you are affected, please follow up to this email.

 Much appreciated!

 I have verified that my system is not affected.

 One question, do I have to rewrite the zfs gpt boot loader
 (/boot/gptzfsboot) onto the freebsd-boot partition to make use of this
 change?

 This change is kernel-level only.  There is no interaction with boot blocks.

 --
 Andriy Gapon

I can happily report that booting from the ZFS pool works on my
9-STABLE system without the zpool.cache file.

Thanks, merry christmas and happy new year!

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

Re: [HEADSUP] zfs root pool mounting

[Kimmo Paasiala]

On Sun, Dec 23, 2012 at 2:28 PM, Andriy Gapon a...@freebsd.org wrote:

 I have MFCed the following change, so please double-check if you might be
 affected.  Preferably before upgrading :-)

 on 28/11/2012 20:35 Andriy Gapon said the following:

 Recently some changes were made to how a root pool is opened for root 
 filesystem
 mounting.  Previously the root pool had to be present in zpool.cache.  Now 
 it is
 automatically discovered by probing available GEOM providers.
 The new scheme is believed to be more flexible.  For example, it allows to 
 prepare
 a new root pool at one system, then export it and then boot from it on a new
 system without doing any extra/magical steps with zpool.cache.  It could 
 also be
 convenient after zpool split and in some other situations.

 The change was introduced via multiple commits, the latest relevant revision 
 in
 head is r243502.  The changes are partially MFC-ed, the remaining parts are
 scheduled to be MFC-ed soon.

 I have received a report that the change caused a problem with booting on at 
 least
 one system.  The problem has been identified as an issue in local 
 environment and
 has been fixed.  Please read on to see if you might be affected when you 
 upgrade,
 so that you can avoid any unnecessary surprises.

 You might be affected if you ever had a pool named the same as your current 
 root
 pool.  And you still have any disks connected to your system that belonged 
 to that
 pool (in whole or via some partitions).  And that pool was never properly
 destroyed using zpool destroy, but merely abandoned (its disks
 re-purposed/re-partitioned/reused).

 If all of the above are true, then I recommend that you run 'zdb -l disk' 
 for
 all suspect disks and their partitions (or just all disks and partitions).  
 If
 this command reports at least one valid ZFS label for a disk or a partition 
 that
 do not belong to any current pool, then the problem may affect you.

 The best course is to remove the offending labels.

 If you are affected, please follow up to this email.

 --
 Andriy Gapon


Much appreciated!

I have verified that my system is not affected.

One question, do I have to rewrite the zfs gpt boot loader
(/boot/gptzfsboot) onto the freebsd-boot partition to make use of this
change?

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Sat, Dec 22, 2012 at 7:49 PM, Łukasz Wąsikowski
luk...@wasikowski.net wrote:
 W dniu 2012-12-22 18:14, Ben Morrow pisze:
 Quoth =?UTF-8?B?xYF1a2FzeiBXxIVzaWtvd3NraQ==?= luk...@wasikowski.net:
 W dniu 2012-12-22 04:41, Kimmo Paasiala pisze:

 Yeah, this is problem in network.subr. An interface is not recognized
 as IPv6 capable if the interface is not in ipv6_network_interfaces
 and there's no ifconfig_IF_ipv6 in rc.conf(5), bummer. For IPv4 it
 just works because the interface is always assumed to be IPv4
 capable.

 Ok, I used ifconfig_em0_ipv6=up and it worked. So it looks like this:

 The documented way to do this is to just set the link-local address in
 ifconfig_IF_ipv6, since an interface is required to have a link-local
 address. Either configure an fe80:: address explicitly or set

 ifconfig_em0_ipv6=inet6 auto_linklocal

 Alternatively, if you set ipv6_activate_all_interfaces all interfaces
 will be considered IPv6-capable.

 link-local address is assigned by default, even with ifconfig_IF_ipv6=up.

 root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf ; ifconfig
 em0 | grep -E '^[[:space:]]*inet6' | head -2
 hostname=freebsd
 ifconfig_em0=up
 ipv4_addrs_em0=192.168.168.20-24/24
 defaultrouter=192.168.168.1
 ipv6_network_interfaces=em0
 ipv6_defaultrouter=2001:6a0:1cb::
 ifconfig_em0_ipv6=up
 ipv6_addrs_em0=2001:6a0:1cb::1-e/128
 sshd_enable=YES
 dumpdev=NO
 named_enable=YES
 inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
 inet6 2001:6a0:1cb::1 prefixlen 128

 Of course using inet6 auto_linklocal instead of up seems a better
 way to do it, thank you for this tip.

 --
 best regards,
 Lukasz Wasikowski


I have put up the patch at github as:

https://gist.github.com/4362018

This version should work with just the ipv6_addrs_IF in rc.conf(5). I
changed the detection of ipv6 interfaces so that just having the
ipv6_addrs_IF line is enough.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Sat, Dec 22, 2012 at 4:25 PM, Łukasz Wąsikowski
luk...@wasikowski.net wrote:
 W dniu 2012-12-22 04:41, Kimmo Paasiala pisze:

 It looks like the reason for the difference to ipv4_addrs_IF is that
 the alias parameter for ifconfig(8) operates differently for IPv6
 addresses, the first address of an interface can't be added with
 alias, for IPv4 it does not care. I'll have to dig deeper but that's
 what the problem seems to be.

 -Kimmo

 The 'alias' parameter of ifconfig(8) is not the problem on the first
 ipv6 address, I have verified that. However, there's probably
 something in network.subr or /etc/rc.d/netif that I have overlooked
 and causes my code to be skipped if there's no ifconfig_IF_ipv6
 variable defined in rc.conf(5).

 -Kimmo

 Yeah, this is problem in network.subr. An interface is not recognized
 as IPv6 capable if the interface is not in ipv6_network_interfaces
 and there's no ifconfig_IF_ipv6 in rc.conf(5), bummer. For IPv4 it
 just works because the interface is always assumed to be IPv4
 capable.

 Ok, I used ifconfig_em0_ipv6=up and it worked. So it looks like this:

 ipv6_activate_all_interfaces=NO
 ipv6_network_interfaces=em0
 ifconfig_em0_ipv6=up
 ipv6_addrs_em0=2001:6a0:1cb::1-ff/64
 ipv6_defaultrouter=2001:6a0:1cb::

 Good job, thank you! :)

 --
 best regards,
 Lukasz Wasikowski

I'm looking into fixing the issue so you could just have the
ipv6_addrs_em0 line in rc.conf. However I don't want to flood the PR
and this mailing list with different versions of the patch. I want to
get it right next time. Stay tuned.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker jil...@stack.nl wrote:
 On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
 A question related to this for those who have been doing work on the
 rc(8) scripts. Can I assume that /usr/bin is available when
 network.subr functions are used? Doing calculations on hexadecimal
 numbers is going to be very awkward if I can't use for example bc(1).

 You cannot assume that /usr/bin is available when setting up the
 network. It may be that /usr is mounted via NFS.

 You can use hexadecimal numbers (prefixed with 0x) in $((...))
 expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
 use; in older versions you can use hexdigit and hexprint from
 network.subr.

 --
 Jilles Tjoelker

 Thanks, I've rewitten my patch to support ranges. It is attached in
 this message.

 Again it's against a very recent 9-STABLE, I still haven't found time
 to see if it applies to CURRENT.

 It does allow you to do crazy stuff like

 ipv6_addrs_re0=2001:db8::::1-/64

 However I didn't find anything to limit the number of aliases in the
 ipv4 version of the function either.

 Please test it :)


 Then a question about the PR
 (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
 attach this new patch to it? The submit follow up -button fires up my
 email client and I'm not so sure how to submit a new patch for the PR
 in an email in such a way that it appears properly formatted in the
 PR.

 Regards,

 Kimmo Paasiala

PR updated with the new patch.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Sat, Dec 22, 2012 at 1:38 AM, Łukasz Wąsikowski
luk...@wasikowski.net wrote:
 W dniu 2012-12-21 13:23, Kimmo Paasiala pisze:
 On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker jil...@stack.nl wrote:
 On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
 A question related to this for those who have been doing work on the
 rc(8) scripts. Can I assume that /usr/bin is available when
 network.subr functions are used? Doing calculations on hexadecimal
 numbers is going to be very awkward if I can't use for example bc(1).

 You cannot assume that /usr/bin is available when setting up the
 network. It may be that /usr is mounted via NFS.

 You can use hexadecimal numbers (prefixed with 0x) in $((...))
 expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
 use; in older versions you can use hexdigit and hexprint from
 network.subr.

 --
 Jilles Tjoelker

 Thanks, I've rewitten my patch to support ranges. It is attached in
 this message.

 Again it's against a very recent 9-STABLE, I still haven't found time
 to see if it applies to CURRENT.

 It does allow you to do crazy stuff like

 ipv6_addrs_re0=2001:db8::::1-/64

 However I didn't find anything to limit the number of aliases in the
 ipv4 version of the function either.

 Please test it :)


 Then a question about the PR
 (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
 attach this new patch to it? The submit follow up -button fires up my
 email client and I'm not so sure how to submit a new patch for the PR
 in an email in such a way that it appears properly formatted in the
 PR.

 Regards,

 Kimmo Paasiala

 PR updated with the new patch.

 Your patch applied cleanly, but it's not working or I am doing something
 wrong.

 root@freebsd:~ # uname -a
 FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri
 Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC
 amd64

 root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf
 hostname=freebsd
 ifconfig_em0=up
 ipv4_addrs_em0=192.168.168.20-24/24
 defaultrouter=192.168.168.1
 ipv6_activate_all_interfaces=YES
 ipv6_addrs_em0=2001:6a0:1cb::1-6/64
 ipv6_defaultrouter=2001:6a0:1cb::
 sshd_enable=YES
 dumpdev=NO
 named_enable=YES

 root@freebsd:~ # ifconfig
 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM
 ether 08:00:27:02:83:71
 inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
 inet 192.168.168.20 netmask 0xff00 broadcast 192.168.168.255
 inet 192.168.168.21 netmask 0x broadcast 192.168.168.21
 inet 192.168.168.22 netmask 0x broadcast 192.168.168.22
 inet 192.168.168.23 netmask 0x broadcast 192.168.168.23
 inet 192.168.168.24 netmask 0x broadcast 192.168.168.24
 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active
 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
 options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6
 inet6 ::1 prefixlen 128
 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
 inet 127.0.0.1 netmask 0xff00
 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL

 --
 best regards,
 Lukasz Wasikowski

You need to first add a single ipv6 address using the
ifconfig_em0_ipv6 -syntax.

ifconfig_em0_ipv6=2001:6a0:1cb::1/64

And then this should add the rest of the addresses

ipv6_addrs_em0=2001:6a0:1cb::2-6/64

It looks like the reason for the difference to ipv4_addrs_IF is that
the alias parameter for ifconfig(8) operates differently for IPv6
addresses, the first address of an interface can't be added with
alias, for IPv4 it does not care. I'll have to dig deeper but that's
what the problem seems to be.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Sat, Dec 22, 2012 at 3:19 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sat, Dec 22, 2012 at 1:38 AM, Łukasz Wąsikowski
 luk...@wasikowski.net wrote:
 W dniu 2012-12-21 13:23, Kimmo Paasiala pisze:
 On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker jil...@stack.nl wrote:
 On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
 A question related to this for those who have been doing work on the
 rc(8) scripts. Can I assume that /usr/bin is available when
 network.subr functions are used? Doing calculations on hexadecimal
 numbers is going to be very awkward if I can't use for example bc(1).

 You cannot assume that /usr/bin is available when setting up the
 network. It may be that /usr is mounted via NFS.

 You can use hexadecimal numbers (prefixed with 0x) in $((...))
 expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
 use; in older versions you can use hexdigit and hexprint from
 network.subr.

 --
 Jilles Tjoelker

 Thanks, I've rewitten my patch to support ranges. It is attached in
 this message.

 Again it's against a very recent 9-STABLE, I still haven't found time
 to see if it applies to CURRENT.

 It does allow you to do crazy stuff like

 ipv6_addrs_re0=2001:db8::::1-/64

 However I didn't find anything to limit the number of aliases in the
 ipv4 version of the function either.

 Please test it :)


 Then a question about the PR
 (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
 attach this new patch to it? The submit follow up -button fires up my
 email client and I'm not so sure how to submit a new patch for the PR
 in an email in such a way that it appears properly formatted in the
 PR.

 Regards,

 Kimmo Paasiala

 PR updated with the new patch.

 Your patch applied cleanly, but it's not working or I am doing something
 wrong.

 root@freebsd:~ # uname -a
 FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri
 Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC
 amd64

 root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf
 hostname=freebsd
 ifconfig_em0=up
 ipv4_addrs_em0=192.168.168.20-24/24
 defaultrouter=192.168.168.1
 ipv6_activate_all_interfaces=YES
 ipv6_addrs_em0=2001:6a0:1cb::1-6/64
 ipv6_defaultrouter=2001:6a0:1cb::
 sshd_enable=YES
 dumpdev=NO
 named_enable=YES

 root@freebsd:~ # ifconfig
 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM
 ether 08:00:27:02:83:71
 inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
 inet 192.168.168.20 netmask 0xff00 broadcast 192.168.168.255
 inet 192.168.168.21 netmask 0x broadcast 192.168.168.21
 inet 192.168.168.22 netmask 0x broadcast 192.168.168.22
 inet 192.168.168.23 netmask 0x broadcast 192.168.168.23
 inet 192.168.168.24 netmask 0x broadcast 192.168.168.24
 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active
 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
 options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6
 inet6 ::1 prefixlen 128
 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
 inet 127.0.0.1 netmask 0xff00
 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL

 --
 best regards,
 Lukasz Wasikowski

 You need to first add a single ipv6 address using the
 ifconfig_em0_ipv6 -syntax.

 ifconfig_em0_ipv6=2001:6a0:1cb::1/64

 And then this should add the rest of the addresses

 ipv6_addrs_em0=2001:6a0:1cb::2-6/64

 It looks like the reason for the difference to ipv4_addrs_IF is that
 the alias parameter for ifconfig(8) operates differently for IPv6
 addresses, the first address of an interface can't be added with
 alias, for IPv4 it does not care. I'll have to dig deeper but that's
 what the problem seems to be.

 -Kimmo

The 'alias' parameter of ifconfig(8) is not the problem on the first
ipv6 address, I have verified that. However, there's probably
something in network.subr or /etc/rc.d/netif that I have overlooked
and causes my code to be skipped if there's no ifconfig_IF_ipv6
variable defined in rc.conf(5).

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Sat, Dec 22, 2012 at 5:09 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sat, Dec 22, 2012 at 3:19 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Sat, Dec 22, 2012 at 1:38 AM, Łukasz Wąsikowski
 luk...@wasikowski.net wrote:
 W dniu 2012-12-21 13:23, Kimmo Paasiala pisze:
 On Fri, Dec 21, 2012 at 5:43 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker jil...@stack.nl wrote:
 On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
 A question related to this for those who have been doing work on the
 rc(8) scripts. Can I assume that /usr/bin is available when
 network.subr functions are used? Doing calculations on hexadecimal
 numbers is going to be very awkward if I can't use for example bc(1).

 You cannot assume that /usr/bin is available when setting up the
 network. It may be that /usr is mounted via NFS.

 You can use hexadecimal numbers (prefixed with 0x) in $((...))
 expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
 use; in older versions you can use hexdigit and hexprint from
 network.subr.

 --
 Jilles Tjoelker

 Thanks, I've rewitten my patch to support ranges. It is attached in
 this message.

 Again it's against a very recent 9-STABLE, I still haven't found time
 to see if it applies to CURRENT.

 It does allow you to do crazy stuff like

 ipv6_addrs_re0=2001:db8::::1-/64

 However I didn't find anything to limit the number of aliases in the
 ipv4 version of the function either.

 Please test it :)


 Then a question about the PR
 (http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
 attach this new patch to it? The submit follow up -button fires up my
 email client and I'm not so sure how to submit a new patch for the PR
 in an email in such a way that it appears properly formatted in the
 PR.

 Regards,

 Kimmo Paasiala

 PR updated with the new patch.

 Your patch applied cleanly, but it's not working or I am doing something
 wrong.

 root@freebsd:~ # uname -a
 FreeBSD freebsd 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #1 r244567: Fri
 Dec 21 23:57:28 CET 2012 root@freebsd:/usr/obj/usr/src/sys/GENERIC
 amd64

 root@freebsd:~ # grep -Ev '^[[:space:]]*#|^$' /etc/rc.conf
 hostname=freebsd
 ifconfig_em0=up
 ipv4_addrs_em0=192.168.168.20-24/24
 defaultrouter=192.168.168.1
 ipv6_activate_all_interfaces=YES
 ipv6_addrs_em0=2001:6a0:1cb::1-6/64
 ipv6_defaultrouter=2001:6a0:1cb::
 sshd_enable=YES
 dumpdev=NO
 named_enable=YES

 root@freebsd:~ # ifconfig
 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM
 ether 08:00:27:02:83:71
 inet6 fe80::a00:27ff:fe02:8371%em0 prefixlen 64 scopeid 0x1
 inet 192.168.168.20 netmask 0xff00 broadcast 192.168.168.255
 inet 192.168.168.21 netmask 0x broadcast 192.168.168.21
 inet 192.168.168.22 netmask 0x broadcast 192.168.168.22
 inet 192.168.168.23 netmask 0x broadcast 192.168.168.23
 inet 192.168.168.24 netmask 0x broadcast 192.168.168.24
 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active
 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
 options=63RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6
 inet6 ::1 prefixlen 128
 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
 inet 127.0.0.1 netmask 0xff00
 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL

 --
 best regards,
 Lukasz Wasikowski

 You need to first add a single ipv6 address using the
 ifconfig_em0_ipv6 -syntax.

 ifconfig_em0_ipv6=2001:6a0:1cb::1/64

 And then this should add the rest of the addresses

 ipv6_addrs_em0=2001:6a0:1cb::2-6/64

 It looks like the reason for the difference to ipv4_addrs_IF is that
 the alias parameter for ifconfig(8) operates differently for IPv6
 addresses, the first address of an interface can't be added with
 alias, for IPv4 it does not care. I'll have to dig deeper but that's
 what the problem seems to be.

 -Kimmo

 The 'alias' parameter of ifconfig(8) is not the problem on the first
 ipv6 address, I have verified that. However, there's probably
 something in network.subr or /etc/rc.d/netif that I have overlooked
 and causes my code to be skipped if there's no ifconfig_IF_ipv6
 variable defined in rc.conf(5).

 -Kimmo

Yeah, this is problem in network.subr. An interface is not recognized
as IPv6 capable if the interface is not in ipv6_network_interfaces
and there's no ifconfig_IF_ipv6 in rc.conf(5), bummer. For IPv4 it
just works because the interface is always assumed to be IPv4
capable.

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Wed, Dec 19, 2012 at 11:47 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Wed, Dec 19, 2012 at 3:46 PM, Łukasz Wąsikowski
 luk...@wasikowski.net wrote:
 W dniu 2012-12-19 07:14, Kimmo Paasiala pisze:

 I wrote a small patch for /etc/network.subr to add support for
 ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
 ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
 aliases can be written like:

 [...]

 Did anyone try my patch? I thought it would be nice to have the
 ipv6_addrs_IF syntax supported to complement the existing
 ipv4_addrs_IF alias syntax.

 Can I use range syntax in it like in ipv4? I mean something like:

 ipv4_addrs_lagg0=x.x.x.10-30/22

 That feature would be very nice to have for ipv6.

 --
 best regards,
 Lukasz Wasikowski

 I have to admit I overlooked the possibility to use ranges like that.
 It doesn't look too hard to add that feature as well for ipv6 aliases
 using the existing code for ipv4 aliases. I'll prepare a new patch and
 update the PR when I have it working.

 -Kimmo

A question related to this for those who have been doing work on the
rc(8) scripts. Can I assume that /usr/bin is available when
network.subr functions are used? Doing calculations on hexadecimal
numbers is going to be very awkward if I can't use for example bc(1).

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

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Thu, Dec 20, 2012 at 3:27 PM, Jilles Tjoelker jil...@stack.nl wrote:
 On Thu, Dec 20, 2012 at 01:04:34PM +0200, Kimmo Paasiala wrote:
 A question related to this for those who have been doing work on the
 rc(8) scripts. Can I assume that /usr/bin is available when
 network.subr functions are used? Doing calculations on hexadecimal
 numbers is going to be very awkward if I can't use for example bc(1).

 You cannot assume that /usr/bin is available when setting up the
 network. It may be that /usr is mounted via NFS.

 You can use hexadecimal numbers (prefixed with 0x) in $((...))
 expressions. In FreeBSD 9.0 or newer, sh has a printf builtin you can
 use; in older versions you can use hexdigit and hexprint from
 network.subr.

 --
 Jilles Tjoelker

Thanks, I've rewitten my patch to support ranges. It is attached in
this message.

Again it's against a very recent 9-STABLE, I still haven't found time
to see if it applies to CURRENT.

It does allow you to do crazy stuff like

ipv6_addrs_re0=2001:db8::::1-/64

However I didn't find anything to limit the number of aliases in the
ipv4 version of the function either.

Please test it :)


Then a question about the PR
(http://www.freebsd.org/cgi/query-pr.cgi?pr=174225) I wrote, how can I
attach this new patch to it? The submit follow up -button fires up my
email client and I'm not so sure how to submit a new patch for the PR
in an email in such a way that it appears properly formatted in the
PR.

Regards,

Kimmo Paasiala
Index: network.subr
===
--- network.subr(revision 244523)
+++ network.subr(working copy)
@@ -562,6 +562,7 @@
fi
 
ifalias_up ${_if} inet6  _ret=0
+   ipv6_addrs_common ${_if} alias  _ret=0
ipv6_prefix_hostid_addr_common ${_if} alias  _ret=0
ipv6_accept_rtadv_up ${_if}  _ret=0
 
@@ -684,6 +685,49 @@
return $_ret
 }
 
+
+ipv6_addrs_common()
+{
+   local _ret _if _action _ip6prefix _ip6prefixes
+   local _ip6addr _prefixlen
+   local _range _ip6net _ip6low _ip6high
+   _ret=1
+   _if=$1
+   _action=$2
+
+# get the prefixes from ipv6_addrs_IF variable
+   _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
+   for _ip6prefix in ${_ip6prefixes}; do
+   _ip6addr=${_ip6prefix%%/*}
+   _prefixlen=${_ip6prefix##*/}
+   _range=${_ip6addr##*:}
+   _ip6net=${_ip6addr%:*}
+   _ip6low=${_range%-*}
+   _ip6high=${_range#*-}
+
+# If deleting an alias, set _prefixlen to null string.
+   if [ ${_action} = -alias ]; then
+   _prefixlen=
+   else
+   _prefixlen=prefixlen $_prefixlen
+   fi
+
+   _ip6high=$((0x${_ip6high}))
+   _ip6count=$((0x${_ip6low}))
+   while [ ${_ip6count} -le ${_ip6high}  ]; do
+# Re-uses the _ip6addr variable from above
+   _ip6addr=$(printf %x ${_ip6count})
+   eval ifconfig ${_if} inet6 ${_ip6net}:${_ip6addr} 
${_prefixlen} ${_action}
+   _ip6count=$((${_ip6count}+1))
+   _ret=0
+   done
+   done
+
+   return $_ret
+}
+
+
+
 # ifalias_up if af
 #  Configure aliases for network interface $if.
 #  It returns 0 if at least one alias was configured or
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Wed, Dec 19, 2012 at 3:46 PM, Łukasz Wąsikowski
luk...@wasikowski.net wrote:
 W dniu 2012-12-19 07:14, Kimmo Paasiala pisze:

 I wrote a small patch for /etc/network.subr to add support for
 ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
 ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
 aliases can be written like:

 [...]

 Did anyone try my patch? I thought it would be nice to have the
 ipv6_addrs_IF syntax supported to complement the existing
 ipv4_addrs_IF alias syntax.

 Can I use range syntax in it like in ipv4? I mean something like:

 ipv4_addrs_lagg0=x.x.x.10-30/22

 That feature would be very nice to have for ipv6.

 --
 best regards,
 Lukasz Wasikowski

I have to admit I overlooked the possibility to use ranges like that.
It doesn't look too hard to add that feature as well for ipv6 aliases
using the existing code for ipv4 aliases. I'll prepare a new patch and
update the PR when I have it working.

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

Re: [HEADSUP] zfs root pool mounting

[Kimmo Paasiala]

On Wed, Nov 28, 2012 at 8:35 PM, Andriy Gapon a...@freebsd.org wrote:

 Recently some changes were made to how a root pool is opened for root 
 filesystem
 mounting.  Previously the root pool had to be present in zpool.cache.  Now it 
 is
 automatically discovered by probing available GEOM providers.
 The new scheme is believed to be more flexible.  For example, it allows to 
 prepare
 a new root pool at one system, then export it and then boot from it on a new
 system without doing any extra/magical steps with zpool.cache.  It could also 
 be
 convenient after zpool split and in some other situations.

 The change was introduced via multiple commits, the latest relevant revision 
 in
 head is r243502.  The changes are partially MFC-ed, the remaining parts are
 scheduled to be MFC-ed soon.

 I have received a report that the change caused a problem with booting on at 
 least
 one system.  The problem has been identified as an issue in local environment 
 and
 has been fixed.  Please read on to see if you might be affected when you 
 upgrade,
 so that you can avoid any unnecessary surprises.

 You might be affected if you ever had a pool named the same as your current 
 root
 pool.  And you still have any disks connected to your system that belonged to 
 that
 pool (in whole or via some partitions).  And that pool was never properly
 destroyed using zpool destroy, but merely abandoned (its disks
 re-purposed/re-partitioned/reused).

 If all of the above are true, then I recommend that you run 'zdb -l disk' 
 for
 all suspect disks and their partitions (or just all disks and partitions).  If
 this command reports at least one valid ZFS label for a disk or a partition 
 that
 do not belong to any current pool, then the problem may affect you.

 The best course is to remove the offending labels.

 If you are affected, please follow up to this email.

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

Hello,

What is the status of the MFC process to 9-STABLE? I'm on 9-STABLE
r244407, should I be able to boot from this ZFS pool without
zpool.cache?

zpool status
  pool: zwhitezone
 state: ONLINE
  scan: scrub repaired 0 in 0h53m with 0 errors on Sat Dec 15 23:41:09 2012
config:

NAME   STATE READ WRITE CKSUM
zwhitezone ONLINE   0 0 0
  mirror-0 ONLINE   0 0 0
label/wzdisk0  ONLINE   0 0 0
label/wzdisk1  ONLINE   0 0 0
  mirror-1 ONLINE   0 0 0
label/wzdisk2  ONLINE   0 0 0
label/wzdisk3  ONLINE   0 0 0

errors: No known data errors
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

On Fri, Dec 7, 2012 at 12:42 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 Hello,

 I wrote a small patch for /etc/network.subr to add support for
 ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
 ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
 aliases can be written like:

 ipv6_addrs_re0=2001:db8::::1/64 2001:db8::::2/64

 Only this syntax is supported, it's not possible to use the prefixlen
 nn syntax in the list.

 The patch is against a recent 9-STABLE, last changed rev of
 network.subr on my SVN checkout is r242187. I don't have a CURRENT
 system to test if it applies to CURRENT as well.

 The patch can be found attached to a PR I sent:

 http://www.freebsd.org/cgi/query-pr.cgi?pr=174225


 I wrote this patch inspired by a question on the FreeBSD forums:

 http://forums.freebsd.org/showthread.php?t=36136

 Please test and report if it works for you :)


 Regards,
 Kimmo Paasiala

Hello,

Did anyone try my patch? I thought it would be nice to have the
ipv6_addrs_IF syntax supported to complement the existing
ipv4_addrs_IF alias syntax.

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

Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.

[Kimmo Paasiala]

On Thu, Dec 13, 2012 at 4:13 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
 On Wed, 2012-12-12 at 20:52 +0200, Kimmo Paasiala wrote:
 On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore
 free...@damnhippie.dyndns.org wrote:
  On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote:
  Hello,
 
  My 9-STABLE buildworld broke in a very inexplicable way,  I was
  getting an error on /usr/src/include/osreldate.h that I couldn't
  figure out until I started looking at the sys/conf/newvers.sh and what
  it does. It turned out that the thing that broke my buildworld was
  having .git directory at the root directory of the system because I
  recently started using GIT to track the configuration files.
 
  I added some debug echos to the newvers.sh and I found out it's
  setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
  the gitdir to /.git and that seems to break the logic in newvers.sh.
 
  Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
  tree (/usr/src/sys default)?
 
  I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
  newvers.sh:
 
  SYSDIR=$(dirname $0)/..
 
  $0 is actually /bin/sh and not the path to newver.sh because the
  newvers.sh is sourced by the Makefile in /usr/src/include instead of
  executing it:
 
  osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh 
  ${.CURDIR}/../sys/sys/param.h \
  ${.CURDIR}/Makefile
  @${ECHO} creating osreldate.h from newvers.sh
  @MAKE=${MAKE}; \
  PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
  . ${.CURDIR}/../sys/conf/newvers.sh; \
 
  Now the question is how to fix this?
 
  -Kimmo
 
  Perhaps it could be handled similar to PARAMFILE, something like this in
  the makefile:
 
PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
SYSDIR=${.CURDIR}/../sys; \
   . ${.CURDIR}/../sys/conf/newvers.sh; \
 
  I'm not sure if newvers.sh needs to work in ways that don't involve
  being invoked from that makefile rule, so to be safe it could have
  default handling, something like:
 
   : ${SYSDIR:=$(dirname $0)/..}
 
  -- Ian
 
 

 Thanks, that works. Should I file a PR about this?

 -Kimmo

 I think that would probably be a good idea, since no committer has
 chimed in on this thread saying they're about to commit a fix.

 -- Ian



Submitted as misc/174422.

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

/usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.

[Kimmo Paasiala]

Hello,

My 9-STABLE buildworld broke in a very inexplicable way,  I was
getting an error on /usr/src/include/osreldate.h that I couldn't
figure out until I started looking at the sys/conf/newvers.sh and what
it does. It turned out that the thing that broke my buildworld was
having .git directory at the root directory of the system because I
recently started using GIT to track the configuration files.

I added some debug echos to the newvers.sh and I found out it's
setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
the gitdir to /.git and that seems to break the logic in newvers.sh.

Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
tree (/usr/src/sys default)?

I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
newvers.sh:

SYSDIR=$(dirname $0)/..

$0 is actually /bin/sh and not the path to newver.sh because the
newvers.sh is sourced by the Makefile in /usr/src/include instead of
executing it:

osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h \
${.CURDIR}/Makefile
@${ECHO} creating osreldate.h from newvers.sh
@MAKE=${MAKE}; \
PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
. ${.CURDIR}/../sys/conf/newvers.sh; \

Now the question is how to fix this?

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

Re: /usr/src/sys/conf/newvers.sh, SYSDIR set to wrong directory.

[Kimmo Paasiala]

On Wed, Dec 12, 2012 at 6:53 PM, Ian Lepore
free...@damnhippie.dyndns.org wrote:
 On Wed, 2012-12-12 at 18:14 +0200, Kimmo Paasiala wrote:
 Hello,

 My 9-STABLE buildworld broke in a very inexplicable way,  I was
 getting an error on /usr/src/include/osreldate.h that I couldn't
 figure out until I started looking at the sys/conf/newvers.sh and what
 it does. It turned out that the thing that broke my buildworld was
 having .git directory at the root directory of the system because I
 recently started using GIT to track the configuration files.

 I added some debug echos to the newvers.sh and I found out it's
 setting SYSDIR to /bin/.. which in turn causes the newvers.sh to set
 the gitdir to /.git and that seems to break the logic in newvers.sh.

 Isn't SYSDIR supposed to be set to the sys -subdirectory of the source
 tree (/usr/src/sys default)?

 I'm guessing the reason the SYSDIR gets set to /bin/.. is the line in
 newvers.sh:

 SYSDIR=$(dirname $0)/..

 $0 is actually /bin/sh and not the path to newver.sh because the
 newvers.sh is sourced by the Makefile in /usr/src/include instead of
 executing it:

 osreldate.h: ${.CURDIR}/../sys/conf/newvers.sh ${.CURDIR}/../sys/sys/param.h 
 \
 ${.CURDIR}/Makefile
 @${ECHO} creating osreldate.h from newvers.sh
 @MAKE=${MAKE}; \
 PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
 . ${.CURDIR}/../sys/conf/newvers.sh; \

 Now the question is how to fix this?

 -Kimmo

 Perhaps it could be handled similar to PARAMFILE, something like this in
 the makefile:

   PARAMFILE=${.CURDIR}/../sys/sys/param.h; \
   SYSDIR=${.CURDIR}/../sys; \
  . ${.CURDIR}/../sys/conf/newvers.sh; \

 I'm not sure if newvers.sh needs to work in ways that don't involve
 being invoked from that makefile rule, so to be safe it could have
 default handling, something like:

  : ${SYSDIR:=$(dirname $0)/..}

 -- Ian



Thanks, that works. Should I file a PR about this?

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

ipv6_addrs_IF aliases in rc.conf(5)

[Kimmo Paasiala]

Hello,

I wrote a small patch for /etc/network.subr to add support for
ipv6_addrs_IF aliases in rc.conf(5) to match the already existing
ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6
aliases can be written like:

ipv6_addrs_re0=2001:db8::::1/64 2001:db8::::2/64

Only this syntax is supported, it's not possible to use the prefixlen
nn syntax in the list.

The patch is against a recent 9-STABLE, last changed rev of
network.subr on my SVN checkout is r242187. I don't have a CURRENT
system to test if it applies to CURRENT as well.

The patch can be found attached to a PR I sent:

http://www.freebsd.org/cgi/query-pr.cgi?pr=174225


I wrote this patch inspired by a question on the FreeBSD forums:

http://forums.freebsd.org/showthread.php?t=36136

Please test and report if it works for you :)


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

Re: agp in kernel

[Kimmo Paasiala]

On Mon, Nov 5, 2012 at 5:00 PM, Zoran Kolic zko...@sbb.rs wrote:
 After several years I replaced desktop and laptop and
 wait for release to start fresh. On desktop I put nvidia
 gt520. Forums say nvidia prop driver dislikes agp op-
 tion in kernel and recommend removing it. Laptop is
 sandy bridge with hd3000 integrated. Would I trigger
 something if I delete agp from conf file in both cases?

 Another issue bothers me also. RC version of amdtemp
 failed to read temperatures on 8120. What version will
 be included in release? Some months ago there was a post
 of people taking source from current and compiling mo-
 dule. It worked on 8 core bulldozer.

 Best regards all

   Zoran


I don't see how the AGP driver could interfere in a system that does
not have any AGP hardware.  The driver does not have any matching
hardware to attach to so it's just unused code in memory.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 9.1-RC2 - could it be that the installer does not write the MBR?

[Kimmo Paasiala]

On Thu, Oct 18, 2012 at 11:05 AM, jb jb.1234a...@gmail.com wrote:
 Brandon Allbery allbery.b at gmail.com writes:


 On Wed, Oct 17, 2012 at 4:56 PM, Rainer Duffner rainer at
 ultra-secure.dewrote:

  I tried to install 9.1-RC2 amd64 on two disks that previously had some
  version of Solaris installed (with grub as boot-manager).
  The installation would always be successful, but it would just boot to
  grub and then sit there.
 

 RC1 wasn't very good at it either.


 I installed RC2 yesterday and noticed that there was no question asked where
 to install boot loader (MBR or FB root slice/partition).
 That's something needing a fix.
 jb




Such question does not make sense if the disk is GPT partitioned which
is the default now. The boot loader is installed on a separate
freebsd-boot partition and the MBR of the disk contains a special
protective MBR.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: PF Configuration - FreeBSD Release 9.0 x64

[Kimmo Paasiala]

On Tue, Sep 11, 2012 at 6:05 PM, Brandon Allbery allber...@gmail.com wrote:
 On Tue, Sep 11, 2012 at 4:26 AM, Damien Fleuriot m...@my.gd wrote:

 On 11 Sep 2012, at 10:15, Shiv. Nath prabh...@digital-infotech.net
 wrote:
  It is FreeBSD Release 9.0 x64 and i see this log very frequent almost
 every second, And i want to block this IP from reaching my server. i
 configured the PF as following but still see the same logs, it is like it
 did not work.
 
  Sep 11 07:49:56 titan avahi-daemon[1567]: Received response from host
 41.211.2.239 with invalid source port 4331 on interface 'em0.0'

 It says it received a *response* so my understanding is *you* are trying
 to connect.


 But it's avahi (a zeroconf implementation) so the response is to a
 broadcast; the remote machine in question may also be broadcasting.

 I would actually question why avahi is even enabled on a server; perhaps
 the correct answer is simply to disable it in rc.conf.


You do know that avahi-daemon's main use is to advertise _services_
running on a host?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: IPv6 default route. Can't see the wood for the trees.

[Kimmo Paasiala]

 On 8/27/2012 12:27 PM, Christian Laursen wrote:
 On 08/27/12 21:03, John Hawkes-Reed wrote:
 On 27/08/2012 19:06, Christian Laursen wrote:
 On 08/27/12 18:49, John Hawkes-Reed wrote:
 rc.conf:

 (I'm not convinced that obfuscating the addresses is worth the
 confusion)

 ipv6_gateway_enable=YES
 ip6addrctl_verbose=YES
 rtadvd_enable=YES
 rtadvd_interfaces=rl0
 ipv6_cpe_wanif=pcn0
 ipv6_defaultrouter=2001:470:1f0a:b5a::1
 gif_interfaces=gif0
 gifconfig_gif0=192.168.1.100 216.66.80.30
 ifconfig_gif0_ipv6=inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1
 prefixlen 128
 ifconfig_pcn0_ipv6=inet6 2001:470:1f0b:b5a::4 prefixlen 64
 ifconfig_rl0_ipv6=inet6  2001:470:1f0b:b5a::3 prefixlen 64
 -accept_rtadv

 It looks like you are trying to use the /64 used for your tunnel on the
 inside network. That's probably what causes the problem.

 You should use the Routed /64 on the inside. If you need more than one
 /64, you can request a /48.

 I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B:

 Sorry, my bad.

 Are pcn0 and rl0 both connected to internal networks?

 Having the same /64 configured on both is probably bad.

 Why would it be?


 --

You can't have the exact same prefix on two different interfaces,
there's no way to decide where to route traffic going to that prefix
if there's two equal routes in the routing table.

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

Re: Get ports tree of the current pkgng repository

[Kimmo Paasiala]

On Thu, Aug 16, 2012 at 10:56 PM, Michael Schnell s-...@s-tlk.org wrote:
 Hi,
 I don't know if this came up already, but not as far as I know. So, I
 was thinking it would be nice to add a mechanism to pkgng, which enables
 the user to get the ports tree corresponding to the current repository.

 At least I've the problem that I really like the idea of the pkgng
 system, but I need a few custom build packages. For instance rawtherapee
 is not working for me with OpenMP, so I have to disable it to get it
 working, or I made some patches for openbox, which of course then needs
 to be compiled. In order to get not in conflict with a more recent
 ports tree the exact version of the repository build would be nice.

 At the moment I can think of two ways to implement it. The easiest way
 would be to add the ports tree as a packages into the repository. A more
 complicated thing is to add a mechanism to portsnap synchronised with
 the pkgng system to direct fetch it, or at least a revision number of
 the current repo, so you can check it out of the subversion.

 How do you guys feel about this?


 Greetings
 Michael


Why not just include the SVN revision of the ports tree that was used
to create the packages in the package metadata?

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

Re: Get ports tree of the current pkgng repository

[Kimmo Paasiala]

On Fri, Aug 17, 2012 at 6:25 AM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Thu, Aug 16, 2012 at 10:56 PM, Michael Schnell s-...@s-tlk.org wrote:
 Hi,
 I don't know if this came up already, but not as far as I know. So, I
 was thinking it would be nice to add a mechanism to pkgng, which enables
 the user to get the ports tree corresponding to the current repository.

 At least I've the problem that I really like the idea of the pkgng
 system, but I need a few custom build packages. For instance rawtherapee
 is not working for me with OpenMP, so I have to disable it to get it
 working, or I made some patches for openbox, which of course then needs
 to be compiled. In order to get not in conflict with a more recent
 ports tree the exact version of the repository build would be nice.

 At the moment I can think of two ways to implement it. The easiest way
 would be to add the ports tree as a packages into the repository. A more
 complicated thing is to add a mechanism to portsnap synchronised with
 the pkgng system to direct fetch it, or at least a revision number of
 the current repo, so you can check it out of the subversion.

 How do you guys feel about this?


 Greetings
 Michael


 Why not just include the SVN revision of the ports tree that was used
 to create the packages in the package metadata?

 -Kimmo

And of course in the repository metadata as you proposed, sorry not
enough coffee yet :P

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

Re: Installworld and /usr/include/*.h modification times

[Kimmo Paasiala]

On Mon, Jun 4, 2012 at 11:12 AM, Doug Barton do...@freebsd.org wrote:
 On 06/04/2012 00:10, Christer Solskogen wrote:
 On Fri, Jun 1, 2012 at 3:42 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 Hello list,

 Why are /usr/include files installed with install -C during make
 installworld  when almost everything else is installed without the -C
 flag? This makes it harder to track which files were actually
 installed during the last make installworld. One can easily find
 obsolete files  (that are not covered with make delete-old(-libs))
 with find -x / -type f -mtime +suitable_time but this doesn't work
 for /usr/include files because the modification times are not bumped
 on make installworld.


 If you want, you can do this /after/ a buildworld

 # mv /usr/include /usr/include.old
 # cd /usr/src

 You don't need to do those last 2 steps below if you mv /usr/include
 right before you do 'make installworld', FYI.

 # make hierarchy
 # make installincludes


 --

    This .signature sanitized for your protection

Thanks! I should have thought of that myself... There are few bits
under /usr/share that behave the same way but now I know how to deal
with those as well.

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

Installworld and /usr/include/*.h modification times

[Kimmo Paasiala]

Hello list,

Why are /usr/include files installed with install -C during make
installworld  when almost everything else is installed without the -C
flag? This makes it harder to track which files were actually
installed during the last make installworld. One can easily find
obsolete files  (that are not covered with make delete-old(-libs))
with find -x / -type f -mtime +suitable_time but this doesn't work
for /usr/include files because the modification times are not bumped
on make installworld.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Installworld and /usr/include/*.h modification times

[Kimmo Paasiala]

On Fri, Jun 1, 2012 at 8:45 PM, Lowell Gilbert
freebsd-stable-lo...@be-well.ilk.org wrote:
 Kimmo Paasiala kpaas...@gmail.com writes:

 Why are /usr/include files installed with install -C during make
 installworld  when almost everything else is installed without the -C
 flag? This makes it harder to track which files were actually
 installed during the last make installworld. One can easily find
 obsolete files  (that are not covered with make delete-old(-libs))
 with find -x / -type f -mtime +suitable_time but this doesn't work
 for /usr/include files because the modification times are not bumped
 on make installworld.

 make uses timestamps to determine whether to trigger a rule. Changing
 timestamps on source files without changing the contents is a bad idea.

Yes, I'm aware of how make uses timestamps for figuring out out of
date targets. However I would argue that after updating world with
make installworld (which is done in single user mode there for
requiring at least one reboot) you should start any compilations from
scratch. The ports system does this by default and cleans up any
previous work files before new compilation. I just don't see where
bumping of mtimes for those files would have that great impact, does
anyone?
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org