Re: OpenZFS support merged

[Ben Woods]

On Tue, 25 Aug 2020 at 10:39 am, Matthew Macy  wrote:

> r364746 merged OpenZFS support in to HEAD.
>
>
>
> The change should be transparent unless you want to use new features.
>
> I caution against 'zpool upgrade' for the next few weeks.
>
>
>
> https://svnweb.freebsd.org/base?view=revision&revision=364746



Congratulations and thank you to all involved. This is a great step forward
for FreeBSD.

Looking forward to trying ZFS native encryption, and send/recv of encrypted
datasets!

I’ll second that boot loader support for ZFS native encryption and zstd
compression would greatly complement this change once they are ready.

Regards,
Ben

> 

-- 

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

Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd

[Ben Woods]

On Sat, 15 Feb 2020 at 4:27 am, Joey Kelly  wrote:

> On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote:
> > Upstream OpenSSH-portable removed libwrap support in version 6.7,
> > released in October 2014. We've maintained a patch in our tree to
> > restore it, but it causes friction on each OpenSSH update and may
> > introduce security vulnerabilities not present upstream. It's (past)
> > time to remove it.
>
>
> So color me ignorant, but how does this affect things like DenyHosts? Or
> is
> there an in-application way to block dictionary attacks? I can't go back
> to
> having my servers pounded on day and night (and yes, I listed on an
> alternative port).



DenyHosts can be configured to use PF firewall tables directly, rather than
using TCP wrappers:
https://github.com/denyhosts/denyhosts/blob/master/denyhosts.conf#L261

###
#
# On FreeBSD/OpenBSD/TrueOS/PC-BSD/NetBSD/OS X we may want to block incoming
# traffic using the PF firewall instead of the hosts.deny file
# (aka tcp_wrapper).
# The admin can set up a PF table that is persistent
# and DenyHost can add new addresses to be blocked to that table.
# The TrueOS operating system enables this by default, blocking
# all addresses in the "blacklist" table.
#
# To have DenyHost update the blocking PF table in real time, uncomment
# these next two options. Make sure the table name specificed
# is one created in the pf.conf file of your operating system.
# The PFCTL_PATH variable must point to the pfctl extectuable on your OS.
# PFCTL_PATH = /sbin/pfctl
# PF_TABLE = blacklist
# Note, a good rule to have in your pf.conf file to enable the
# blacklist table is:
#
# table  persist file "/etc/blacklist"
# block in quick from  to any
#
# Warning: If you are using PF, please make sure to disable the
# IPTABLES rule above as these two packet filters should not be
# run together on the same operating system.
# Note: Even if you decide to run DenyHost with PF filtering
# only and no hosts.deny support, please still create an empty
# file called /etc/hosts.deny for backward compatibility.
# Also, please make sure PF is enabled prior to launching
# DenyHosts. To do this run "pfctl -e".
#
# To write all blocked hosts to a PF table file enable this next option.
# This will make hosts added to the PF table persistent across reboots.
# PF_TABLE_FILE = /etc/blacklist
#
###

Regards,
Ben

> --

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

Re: 13.0-CURRENT r356767 wanted ZFS

[Ben Woods]

On Sat, 18 Jan 2020 at 05:06, Clay Daniels 
wrote:

> Thanks, Ben. I'm fine with ZFS for this week. I got involved with a little
> project of my own on this weeks snapshot, and will see what next week
> brings.
>
> Clay
>

This has been fixed in r356855, and the next CURRENT snapshot should
include this fix.
https://svnweb.freebsd.org/changeset/base/356855

Regards,
Ben

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

Re: 13.0-CURRENT r356767 wanted ZFS

[Ben Woods]

On Fri, 17 Jan 2020 at 17:24, Ben Woods  wrote:

> > On Fri, Jan 17, 2020 at 12:18:41AM +, Clay Daniels wrote:
>
>> >> 13.0-CURRENT r356767 would not take NO for an answer, and kept up a
>> loop
>> >> until I gave up trying to use UFS. No big deal, seems to work fine...
>> >>
>> >> Clay
>>
>
> It does seem like this could be related to my commit (see below). Although
> I runtime tested installs with both ZFS and UFS options, so I’m surprised.
> https://svnweb.freebsd.org/changeset/base/356758
>
> I’ll try to have a look at it tonight.
>
> Regards,
> Ben
>

Hi Clay,

Thanks for reporting this issue. I was able to replicate it using
bsdinstall on the latest snapshot ISO
FreeBSD-13.0-CURRENT-amd64-20200116-r356767-disc1.iso.

It turns out the commit that introduced the regression was r356740.

I have submitted a fix for review here:
https://reviews.freebsd.org/D23232

Regards,
Ben

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

Re: 13.0-CURRENT r356767 wanted ZFS

[Ben Woods]

On Fri, 17 Jan 2020 at 10:30 am, Yuri Pankov  wrote:

> David Wolfskill wrote:
> > On Fri, Jan 17, 2020 at 12:18:41AM +, Clay Daniels wrote:
> >> 13.0-CURRENT r356767 would not take NO for an answer, and kept up a loop
> >> until I gave up trying to use UFS. No big deal, seems to work fine...
> >>
> >> Clay
> >> 
> >
> > Err...?  Is there some additional context that I'm missing?
> >
> > I've been tracking head daily for ... longer than I really want to
> > think about, including on at least one system that has no ZFS file
> > systems; the last couple of smoke-tests were at:
> >
> > FreeBSD g1-53.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #7
> r356758M/356758: Wed Jan 15 03:49:49 PST 2020 
> r...@g1-53.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> amd64 1300076 1300076
> >
> > and
> >
> > FreeBSD g1-53.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #8
> r356786M/356787: Thu Jan 16 03:56:45 PST 2020 
> r...@g1-53.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> amd64 1300076 1300076
> >
> > It is not clear to me at what point anything might have a chance
> > to indicate that it "wanted ZFS" and request an action.
>
> Likely it's about the latest 13.0-CURRENT snapshot image (r356767) and
> the change to bsdinstall to make ZFS default partitioning scheme, now
> discussed on arch@.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


It does seem like this could be related to my commit (see below). Although
I runtime tested installs with both ZFS and UFS options, so I’m surprised.

https://svnweb.freebsd.org/changeset/base/356758

I’ll try to have a look at it tonight.

Regards,
Ben

> --

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

Re: head -r355027 context, poudiere jail constructions with the likes of -a arm64.aarch64 -x : awk: can't open file /sys/param.h

[Ben Woods]

On Sun, 24 Nov 2019 at 1:27 pm, Mark Millard  wrote:

> My poudiere jail constructions with the likes of -a arm64.aarch64 -x are
> all getting:
>
> awk: can't open file /sys/param.h
>  source line number 1


Hi Mark,

I have been getting this same error on amd64 for some time when I use the
command below.
# poudriere jail -j 13amd64 -u -m src=/usr/src

Any ideas what it could be?

Regards,
Ben

> --

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

Re: Boot freezing after kernel load - root on zfs

[Ben Woods]

On 23 June 2018 at 22:56, Joe Maloney  wrote:

> Ben,
> do you by chance have multicons enabled with comconsole, vidconsole?  This
> looks exactly like a race we encountered where the remaining output was
> actually being redirected to serial on some systems when multicons was
> being used.  It appeared to be a lockup when it wasn’t because keyboard
> input would also break.
>

Hi Joe,

Indeed, you are right - I have now fixed the problem! Thanks very much for
your help!

I was previously using a serial console to boot the machine, whereas now I
have an IP KVM.

The lines I commented out in my /boot/loader.conf to fix this were:
boot_multicons="YES"
boot_serial="YES"
comconsole_speed="115200"
console="comconsole,vidconsole"

I would have thought that the boot should still complete regardless of
whether the serial console is connected or not?

Regards,
Ben

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

Re: Boot freezing after kernel load - root on zfs

[Ben Woods]

On 23 June 2018 at 12:37, Warner Losh  wrote:

> There were some issues with legacy geely booting recently. What version?
> UEFI or legacy BIOS booting?
>
> Warner
>


Hi Warner,

This was occurring with both my old and new beadm boot environments -
r330554 and r334554.

I am booting with legacy BIOS.

Regards,
Ben

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

Re: Boot freezing after kernel load - root on zfs

[Ben Woods]

On 23 June 2018 at 12:08, Allan Jude  wrote:

> If you just press shift a bunch of times, does it print the Mount root
> prompt?
> --
> Allan Jude
>


No, unfortunately not. But please keep any troubleshooting suggestions
coming!

I have tried booting with the KVM monitor and USB disconnected, with the
same result.

It is also worth noting I can successfully boot from a USB stick running
the latest 12-current snapshot
FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there I can
import both of my zpools (zroot and zstore), and then export them again
before rebooting - still can't boot from disk.

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

Boot freezing after kernel load - root on zfs

[Ben Woods]

Hi everyone,

After shutting down to connect a new IP KVM switch (VGA and USB), my
FreeNAS mini hardware is no longer booting FreeBSD with root in zfs (no
encryption) - it is getting stuck after the kernel finishes loading and it
tries to mount root and start_init. It just stops printing any more output
to the screen, but I know the keyboard is working as ctrl+alt+delete works.

I wonder if this could be due to hard drives names being re-ordered (e.g.
what was ada0 is now ada1). I have 2 SATA3 SSDs in a zfs mirror for root
(showing as ada4 and ada5 during boot), and 4 SATA3 HDDs in a raidz2 with
geli for further storage (showing as ada0-3, but these are only mounted
during rc init - after the point the boot process is getting stuck). I have
no USB storage, although the IP KVM may present a virtual disk for loading
media remotely.

I am running 12-CURRENT, but know the recent upgrade is not the issue
because I can’t load from the previous boot environment either.

Is anyone able to recommend a fix or a way to troubleshoot further? Please
see below a link with screenshots at the end of the boot where it gets
stuck.

https://imgur.com/gallery/vhn7ScC

Thanks in advance for any help!

Regards,
Ben

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

Re: Buildworld failing during llvm

[Ben Woods]

On 18 February 2018 at 09:52, Ben Woods  wrote:

> Hi everyone,
>
> My attempts to build FreeBSD 12-current have been failing as of yesterday
> with the error below. This problem persists with current at the time of
> writing this email (r329497).
>
> Given llvm was updated to 6.0 around that time, I suspect it is related:
> https://svnweb.freebsd.org/base?view=revision&revision=329410
>
>
> --- clang.full ---
> c++ -O2 -pipe -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang
> -I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm
> -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include
> -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\"
> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\"
> -ffunction-sections -fdata-sections -g -O0 -Qunused-arguments
> -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11
> -fno-exceptions -fno-rtti -g -O0 -stdlib=libc++ -Wno-c++11-extensions
> -Wl,--gc-sections -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib
> -o clang.full  cc1_main.o cc1as_main.o driver.o
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang/libclang.a
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a
> -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz
> -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw
> -lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr
> -lpthread -legacy
> /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a:
> could not read symbols: Malformed archive
> c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [clang.full] Error code 1
>
>
> Regards,
> Ben
>
> --
> From: Benjamin Woods
> woods...@gmail.com
>


I found this issue was caused by having the following line in my
/etc/make.conf (which I had there for some ports debugging):
DEBUG_FLAGS=-g -O0

I wouldn't have thought this should cause the clang build to fail...


Regards,
Ben

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

Buildworld failing during llvm

[Ben Woods]

Hi everyone,

My attempts to build FreeBSD 12-current have been failing as of yesterday
with the error below. This problem persists with current at the time of
writing this email (r329497).

Given llvm was updated to 6.0 around that time, I suspect it is related:
https://svnweb.freebsd.org/base?view=revision&revision=329410


--- clang.full ---
c++ -O2 -pipe
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang
-I/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm
-I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include
-I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd12.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd12.0\"
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -ffunction-sections
-fdata-sections -g -O0 -Qunused-arguments
-I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -std=c++11
-fno-exceptions -fno-rtti -g -O0 -stdlib=libc++ -Wno-c++11-extensions
-Wl,--gc-sections -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib
-o clang.full  cc1_main.o cc1as_main.o driver.o
/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclang/libclang.a
/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libz -lz
-L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/ncurses/ncursesw
-lncursesw -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libthr
-lpthread -legacy
/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a:
could not read symbols: Malformed archive
c++: error: linker command failed with exit code 1 (use -v to see
invocation)
*** [clang.full] Error code 1


Regards,
Ben

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

Re: PkgBase: Can not upgrade base system

[Ben Woods]

On Tue, 23 Jan 2018 at 4:12 pm, O. Hartmann  wrote:

> For a client I tried PkgBase and followed the procedures recommended (first
> build the OS from /usr/src/, installworld/kernel, then proceed with pkg
> update
> -r FreeBSD-base and pkg install -g 'FreeBSD-*'.
>
> This doesn't work for any update I try to apply. Since the target host is
> a two
> years old Intel NUC based on some Broadwell snail CPU, building world and
> kernel is performed on another, much more potent host.
>
> In the first place, when performing a "pkg upgrade", the system complains
> about
> mismatching OSVERSION, 1200055 forthe running system, and 1200056 for the
> packages to be updated. When setting env OSVERSION=1200056, pkg (not
> pkg-static!) complains about revision numbers (the long date trailing the
> package's name), for instance the newest one is
>
> FreeBSD-hast-12.0.s20180123050738.txz
>
> contained within the repository to be used for the update, but installed is
> something older, like FreeBSD-hast-12.0.s20171103114456.txz.
>
> When trying pkg-static, I get a crash of pkg-static, segmentation fault is
> its
> death-cause.
>
> How am I supposed to update a base system via PkgBase?
>
> Kind regards,
>
> oh
>
> p.s. sorry for the lack of data, the box in question is on a remote site
> without net.
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



This issue was discussed on the FreeBSD-current mailing list. A workaround
has been provided there, but a proper fix is still to be developed:

https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068153.html


Workaround:

# pkg -o OSVERSION=1200056 upgrade


Regards,
Ben

> --

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

Re: what's changed with newsyslog?

[Ben Woods]

On Mon, 18 Dec 2017 at 3:47 am, Michael Butler 
wrote:

> In the past week or so I've been getting warnings like this ..
>
> bzip2: Can't open input file /var/log/snmpd.log.0: No such file or
> directory.
> newsyslog: `/usr/bin/bzip2 -f /var/log/snmpd.log.0
> /var/log/fwlw_clean_log.0' terminated with a non-zero status (1)
>
> I've checked the relevant /etc/newsyslog.conf and its /usr/local/etc
> counterpart to ensure there are tabs in the right places but the errors
> persist.
>
> Similarly, the relevant files are there and seem to be rotated as
> expected/desired ..
>
> -rw-r--r--  1 root  wheel 77 Dec 17 09:00 fwlw_clean_log
> -rw-r--r--  1 root  wheel  11282 Dec 17 09:00 fwlw_clean_log.0.bz2
> -rw-r--r--  1 root  wheel   9452 Dec 17 05:00 fwlw_clean_log.1.bz2
>
>  [ .. ]
>
> -rw-r--r--  1 root  wheel  50992 Dec 17 09:45 snmpd.log
> -rw-r--r--  1 root  wheel   1834 Dec 17 09:00 snmpd.log.0.bz2
> -rw-r--r--  1 root  wheel   1846 Dec 17 07:00 snmpd.log.1.bz2
>
>
> Hints?
>
> imb
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Could this be related to bapt’s recent change 11 days ago to allow
newsyslog to use different style of compression commands?
https://svnweb.freebsd.org/base?view=revision&revision=326617

Regards,
Ben
-- 

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

casper issues with pkgbase

[Ben Woods]

Hi everyone,

I recently upgraded my FreeBSD 12-current machine which uses pkgbase from
r324720 to r325426, and it looks like an error has been introduced in the
naming of base packages for casper.

Without having looked into it deeper, I suspect one of the following
changes is at fault:
https://svnweb.freebsd.org/base/head/lib/libcasper/libcasper/Makefile?r1=325062&r2=325061&pathrev=325062
https://svnweb.freebsd.org/base/head/lib/libcasper/libcasper/Makefile?r1=325398&r2=325397&pathrev=325398
https://svnweb.freebsd.org/base/head/lib/libcasper/libcasper/Makefile?r1=325399&r2=325398&pathrev=325399

** SHORT VERSION **

FreeBSD-casper no longer exists
FreeBSD-casper-debug has been renamed to FreeBSD--debug
FreeBSD-casper-development has been renamed to FreeBSD--development (and
libcasper.a deleted)
FreeBSD-casper-profile no longer exists
FreeBSD-libcasper-profile no longer exists

** MORE DETAILS **

The upgrade removed the following base packages:
FreeBSD-casper
FreeBSD-casper-debug
FreeBSD-casper-development
FreeBSD-casper-profile
FreeBSD-libcasper-profile

$ pkg info -l FreeBSD-casper FreeBSD-casper-debug
FreeBSD-casper-development FreeBSD-casper-profile FreeBSD-libcasper-profile
FreeBSD-casper-12.0.s20171018115534:
/lib/libcasper.so.0
/usr/share/man/man3/cap_clone.3.gz
/usr/share/man/man3/cap_close.3.gz
/usr/share/man/man3/cap_init.3.gz
/usr/share/man/man3/cap_limit_get.3.gz
/usr/share/man/man3/cap_limit_set.3.gz
/usr/share/man/man3/cap_recv_nvlist.3.gz
/usr/share/man/man3/cap_send_nvlist.3.gz
/usr/share/man/man3/cap_service_open.3.gz
/usr/share/man/man3/cap_sock.3.gz
/usr/share/man/man3/cap_unwrap.3.gz
/usr/share/man/man3/cap_wrap.3.gz
/usr/share/man/man3/cap_xfer_nvlist.3.gz
/usr/share/man/man3/libcasper.3.gz
FreeBSD-casper-debug-12.0.s20171018115534:
/usr/lib/debug/lib/libcasper.so.0.debug
FreeBSD-casper-development-12.0.s20171018115534:
/usr/include/libcasper.h
/usr/include/libcasper_service.h
/usr/lib/libcasper.a
/usr/lib/libcasper.so
FreeBSD-casper-profile-12.0.s20171018115534:
/usr/lib/libcasper_p.a
FreeBSD-libcasper-profile-12.0.s20171018115534:
/usr/lib/libcap_dns_p.a
/usr/lib/libcap_grp_p.a
/usr/lib/libcap_pwd_p.a
/usr/lib/libcap_random_p.a
/usr/lib/libcap_sysctl_p.a


It also added the following new base packages (the last 5 are unrelated):
FreeBSD--debug
FreeBSD--development
FreeBSD-libpathconv
FreeBSD-libpathconv-debug
FreeBSD-libpathconv-development
FreeBSD-libpathconv-profile
FreeBSD-libpmcstat-development

$ pkg info -l FreeBSD--debug FreeBSD--development
FreeBSD--debug-12.0.s20171105083526:
/usr/lib/debug/lib/libcasper.so.0.debug
FreeBSD--development-12.0.s20171105083526:
/usr/include/libcasper.h
/usr/include/libcasper_service.h
/usr/lib/libcasper.so


Regards,
Ben

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

Re: [base pkg] update !GENERIC kernel

[Ben Woods]

On Wed, 19 Jul 2017 at 7:37 pm, Boris Samorodov  wrote:

> Hi All,
>
> I use self-made base packages for an ARM board. The kernel I use
> is IMX6 one. While pkg update I get this:
> ---
> [271/302] Upgrading FreeBSD-kernel-imx6-debug from 12.0.s20170718113533
> to 12.0.s20170719070514...
> [271/302] Extracting FreeBSD-kernel-imx6-debug-12.0.s20170719070514:
> 100%
> kldxref: //boot/kernel: No such file or directory
> pkg: POST-INSTALL script failed
> [272/302] Upgrading FreeBSD-kernel-imx6 from 12.0.s20170718113533 to
> 12.0.s20170719070514...
> [272/302] Extracting FreeBSD-kernel-imx6-12.0.s20170719070514: 100%
>
> kldxref: //boot/kernel: No such file or directory
> pkg: POST-INSTALL script failed
> ---
>
> All is fine except those messages.
>
> There is no /boot/kernel, but there is /boot/kernel.IMX6. The kernel
> is defined at /boot/loader.conf:
> ---
> kernel="kernel.IMX6"
> ---
>
> Seems that for now pkg can't handle non-default kernel. Should I just
> ignore those messages? Or should I run some post-update commands/scripts
> by hand?


I had the same problem on my machine using pkg-base with a non-default
named kernel package.

As a workaround, I created a symlink at /boot/kernel pointing to the
correct kernel directory. This seemed to fix the problem, but required this
manual intervention.

It would be good if this wasn't required, and the kernel package used the
kernel parameter in loader.conf to determine where to run the post-install
script.

Regards,
Ben
-- 

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

Re: r316958: booting a server takes >10 minutes!

[Ben Woods]

On 16 April 2017 at 03:24, Larry Rosenman  wrote:

> Current SVN seems to have fixed it (via sobomax@ syslogd commit).
>


I experienced this issue too, and can confirm that it existing on r316952,
but is resolve on r317033.

It was extremely strange. The symptoms I was experiencing were:
- lightdm display manager would fail to start
- slim display manager would start, but then fail to login to xfce
- "service hald restart" and "service dbus restart" would fail
- "pkg upgrade hal" would fail

Regards,
Ben

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

Re: r313938 breaks portsnap

[Ben Woods]

On Tue, 21 Feb 2017 at 10:44 pm, Vladimir Zakharov 
wrote:

> Hello
>
> After recent upgrade portsnap doesn't work anymore:
>
> # portsnap fetch update
> Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
> Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
> Fetching snapshot metadata... done.
> Updating from Tue Feb 21 16:05:39 MSK 2017 to Tue Feb 21 16:59:30 MSK 2017.
> Fetching 5 metadata patches.lam: unable to limit stdio: Capabilities
> insufficient
>  done.
> Applying metadata patches... done.
> Fetching 5 metadata files... lam: unable to limit stdio: Capabilities
> insufficient
> /usr/sbin/portsnap: cannot open
> 8c94d2c3f8fcea20eb1fd82021566c99c63a010e6b3702ee11e7a491795bcfb8.gz: No
> such file or directory
> metadata is corrupt.
>
> Reverting r313938 fixes the problem.



As it wasn't immediately clear to me:

The r313938 being referred to is the change to base to capsicumize lam(1).

https://svnweb.freebsd.org/base?view=revision&revision=313938

Regards,
Ben

-- 

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

Re: Log spam: Limiting * response from 1 to 200 packets/sec

[Ben Woods]

On Thu., 22 Dec. 2016 at 12:45 am, Gleb Smirnoff 
wrote:

> That was my failure and already fixed.
>
Thanks for the fix!

For those of us playing along at home, I believe the fix can in r310032.










https://svnweb.freebsd.org/base?view=revision&revision=310032




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

Re: service netif restart fails starting ppp/routing

[Ben Woods]

On Mon., 19 Dec. 2016 at 1:37 am, O. Hartmann 
wrote:

> After changing paraemters on my router which uses a modem via ppp/pppoed,
> service netif restart
> does not bring up ppp and named!
>
> After "netif restart" and "routing restart" (in this order), tun0 which is
> supposed to
> have the ISP's IP address is empty and named (the router has bind911
> running) is offline
> and needs also to be restarted via "service named restart".
>
> Is there something I miss or is this a serious bug? It is the first time
> on CURRENT
> (FreeBSD 12.0-CURRENT #74 r310129: Fri Dec 16 00:33:09 CET 2016 amd64) I
> realize this
> behaviour. I never had problems before.
>

I was about to say you will also need to do:
# service pppoed restart

But a quick look at that rc script seems to show that stop or restart are
not implemented:
https://github.com/freebsd/freebsd/blob/master/etc/rc.d/pppoed

Having a quick look at my router which also uses pppoe, I note that in
/etc/rc.conf I am not using the pppoed rc script, but the following:
ppp_enable="YES"
ppp_nat="NO"
ppp_profile="myisp"
ppp_myisp_mode="ddial"
ppp_myisp_nat="NO"
ppp_myisp_unit="0"

Therefore when I need to restart my pppoe after making config changes I
would use:
# service ppp restart

Which one are you using in your rc.conf: ppp or pppoe?

In my /etc/ppp/ppp.conf I have the following:
default:
set log Phase tun command # you can add more detailed logging if
you wish
set speed sync
set mru 1492
set mtu 1492
set ctsrts off
enable echo
set echoperiod 15
enable ipv6cp
enable ipcp
set timeout 0
set redial 0 0

myisp:
set ifaddr MY.IP.ADDR.ESS/0 THEIR.IP.ADDR.ESS/0
set server /var/run/ppp/myisp "" 0177
set device PPPoE:INTERFACE
set authname USERNAME
set authkey PASSWORD
set dial
set login
add default HISADDR
disable dns

Note that I handle the NAT and DNS myself through pf and dnsmasq.

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

Re: CFT EFI Boot Refactoring

[Ben Woods]

On 3 December 2016 at 01:02, Eric McCorkle  wrote:

> Therefore, I would like to issue a CFT for this changeset.  We need
> people using the boot1/loader EFI boot setup to test their setup using
> boot1 and loader as built with this patch applied.
>

After I got this to build, I managed to install the new world, and copy the
new boot1.efi to /EFI/BOOT/BOOTX64.EFI.

Upon reboot, my machine hung at the loader, with the following text on the
screen:
>> FreeBSD EFI boot block
 Loader path: /boot/loader.efi

 Initializing modules: FS Backend|

Unfortunately it stopped there and didn't continue.

I was able to recover my system by moving my BOOTX64.BAK to BOOTX64.EFI,
and changing back to my old loader.efi.

Any thoughts of how we can debug this?

Regards,
Ben

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

Re: CFT EFI Boot Refactoring

[Ben Woods]

On 3 December 2016 at 14:40, Ben Woods  wrote:

> I just applied your diff to my subversion repository, and tried to
> buildworld, but the build failed with the following error:
>
> make[6]: make[6]: don't know how to make efipart.c. Stop
>
> make[6]: stopped in /usr/src/sys/boot/efi/drivers
> *** [all_subdir_sys/boot/efi/drivers] Error code 2
>
>
> Does it build ok for you?
>
> Because I use subversion, and I wanted to build it from my main tree, I
> had to regenerate your patch using "git diff --no-prefix
> master..origin/efize_new > /tmp/efize_new.diff".
> I could then apply this cleanly with "svn patch /tmp/efize_new.diff".
>
>
Never mind, I have realised that efipart.c was moved from boot/efi/libefi/
to boot/efi/drivers/ in your git patch, but subversion did not interpret
this change and simply patched the file in place.
I have fixed this with:
$ svn mv boot/efi/libefi/efipart.c boot/efi/drivers/efipart.c

Sorry for the noise (and the previous top post).

Regards,
Ben

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

Re: drm-next update and longer term plans

[Ben Woods]

On Fri., 2 Dec. 2016 at 6:25 am, Matthew Macy  wrote:

> I imagine that for most users the state of graphics support for
> post-Haswell hardware is a bit of a black box so I'm sending out this note
> to let users know what they can and cannot expect.
>
> Wayland has actually become a reality for some. Talk to Johannes Lundberg
> if you're interested in tracking that.
>
> The i915 (Intel integrated GPUs) driver is currently best supported by the
> drm-next-4.7 branch. Broadwell and Skylake support is complete and some
> support came in late in the cycle for Kaby Lake. I can still consistently
> lock up the kernel in the later stages of the piglit test suite, there is
> no backlight support, and suspend/resume do not work on Skylake. The
> drm-next branch is integrated with upstream up through Linux 4.8-rc5 and
> thus has complete support for Kaby Lake, but there is a lockup in i915 that
> occurs some time within an hour of startx. This takes too long for it to
> have shown up in my limited integration smoke testing.
>
> The amdgpu driver is, in terms of KPI dependencies - as far as I can tell
> - a strict superset of the radeon driver. For example, when I tested my one
> older card that uses the radeon driver it manifested the same ttm bugs as
> amdgpu did at that time. Thus, when amdgpu reaches a complete working state
> I expect radeon to largely "just" work. As of this past Sunday amdgpu with
> the amdgpu DDX works with 2D, supports external monitors - selecting the
> appropriate resolution on a per display basis, and backlight works. It will
> also typically panic in ttm within ~90 minutes of startx. Although this is
> huge progress over panicking within 30s of startx (which was the case as of
> Saturday) or not starting at all due to bugs in the libdrm port a few weeks
> prior, it's obviously not something I encourage anyone to use.
>
> My primary motivation for starting with the work is being able to to train
> DNNs/RNNs and other model types using Theano/Caffe/Tensorflow/BidMach etc
> GPU accelerated whilst still running FreeBSD. The Radeon Open Compute stack
> holds out the promise of doing that without using the closed source CUDA
> stack on top of the Linux ABI emulation - which would inevitably be opaque
> and fragile. My plan is to keep on fixing bugs and tracking upstream until
> the first long term branch after ROC support has been integrated in to
> Linux mainline. I have no exact knowledge of when exactly that will be (AMD
> doesn't have sufficient developer resources to make any concrete
> guarantees) but think it should happen by the summer of 2017. I would like
> to think that by that time the i915, amdgpu, and radeon will be feature
> complete and at least as stable as the drm2 support currently in tree.
>
> I need to weigh my soft commitment to make long-term DRM support happen
> with paid work and other activities which are much more important to me
> long term. Thus I've currently committed to spending every Sunday fixing
> bugs in the drm-next branches. Amdgpu is both more important to me and has
> gotten much less attention than i915. Thus I will be devoting my efforts to
> it in the near term. I'd very much welcome efforts by others to triage the
> issues in i915.
>
> Many people ask when drm-next will be available on 11. I am not a
> committer and thus have no direct say in that. However, if you are a
> motivated individual with kernel knowledge you should contact Adrian Chadd.
> There are a few places where I was not able to provide proper linuxkpi
> semantics without making (mostly quite modest) changes to sys/kern. There
> is a general reluctance by some core developers to make changes to
> accommodate Linux. It is possible that, with additional effort, the
> linuxkpi can both be complete enough to avoid needing to port the graphics
> drivers to FreeBSD (something clearly shown by past efforts to be
> unsustainable) and not need to make any kernel changes. If you would like
> to help with that, let Adrian know. In the meantime, TrueOS will continue
> to use my development branches for the benefit of users with newer hardware.
>
> -M
>
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-unsubscr...@freebsd.org"
>

Hi Matthew / others,

Thanks for your work - I sincerely appreciate every minute of your personal
time spent on this.

What are your thoughts on whether this is ready for committing to
12-current, with plenty of time for polishing before it makes it into a
release?

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

Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

[Ben Woods]

On 24 September 2016 at 18:13, Ben Woods  wrote:

> On 22 September 2016 at 21:01, Mateusz Guzik  wrote:
>
>> On Thu, Sep 22, 2016 at 08:48:29PM +0800, Ben Woods wrote:
>> > #13 0x80b4d91c in turnstile_broadcast (ts=0x0, queue=1) at
>> > /usr/src/sys/kern/subr_turnstile.c:837
>> > #14 0x80ae5e1f in __rw_wunlock_hard (c=0xf803f886d960,
>> > tid=, file=, line=> > optimized out>)
>> > at /usr/src/sys/kern/kern_rwlock.c:1027
>>
>> can you please:
>> f 14
>> x/xg c
>>
>>
>> --
>> Mateusz Guzik 
>>
>
> Thanks for the help Mateusz.
>
> (kgdb) f 14
> #14 0x80ae5e1f in __rw_wunlock_hard (c=0xf803f886d960,
> tid=, file=, line= optimized out>)
> at /usr/src/sys/kern/kern_rwlock.c:1027
> 1027turnstile_broadcast(ts, queue);
> Current language:  auto; currently minimal
> (kgdb) x/xg c
> 0xf803f886d960: 0xf8032893aa00
>
> Regards,
> Ben
>

Hi everyone,

Just a heads up that after updating my FreeBSD 12-current machine to
r307773 I am still getting this kernel panic.

Note that I have compiled the kernel with VIMAGE support if that makes any
difference.

Mateusz: any further ideas on what it could be?

Any help is appreciated :)

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

Re: Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

[Ben Woods]

On 22 September 2016 at 21:01, Mateusz Guzik  wrote:

> On Thu, Sep 22, 2016 at 08:48:29PM +0800, Ben Woods wrote:
> > #13 0x80b4d91c in turnstile_broadcast (ts=0x0, queue=1) at
> > /usr/src/sys/kern/subr_turnstile.c:837
> > #14 0x80ae5e1f in __rw_wunlock_hard (c=0xf803f886d960,
> > tid=, file=, line= > optimized out>)
> > at /usr/src/sys/kern/kern_rwlock.c:1027
>
> can you please:
> f 14
> x/xg c
>
>
> --
> Mateusz Guzik 
>

Thanks for the help Mateusz.

(kgdb) f 14
#14 0x80ae5e1f in __rw_wunlock_hard (c=0xf803f886d960,
tid=, file=, line=)
at /usr/src/sys/kern/kern_rwlock.c:1027
1027turnstile_broadcast(ts, queue);
Current language:  auto; currently minimal
(kgdb) x/xg c
0xf803f886d960: 0xf8032893aa00

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

Kernel crashes from turnstile_broadcast (/usr/src/sys/kern/subr_turnstile.c:837)

[Ben Woods]

Hi everyone,

I am currently experiencing semi-regular kernel crashes on my FreeBSD
12-current machine. I am new to kernel debugging, and hoping someone can
have a look at the debugging output below to point me in the direction of
what the problem might be.

My machine is a FreeNAS-mini from iXsystems which I have formatted and
installed stock FreeBSD onto. My kernel is the default generic-nodebug with
the VIMAGE options added.

$ uname -a
FreeBSD freenas.woods.am 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r305311M: Sat
Sep  3 12:29:01 AWST 2016
woods...@freenas.woods.am:/usr/obj/usr/src/sys/GENERIC-NODEBUG-VIMAGE
amd64

$ cat /usr/src/sys/amd64/conf/GENERIC-NODEBUG-VIMAGE
# SPARTICUS -- WITNESS and INVARIANTS free kernel configuration file
#   for FreeBSD/amd64

include GENERIC-NODEBUG

ident   GENERIC-NODEBUG-VIMAGE

#nooptions  SCTP# Stream Control Transmission Protocol
options VIMAGE  # VNET/Vimage support


Output from kernel crash dump debug with kgdb below:

/usr/obj/usr/src/sys/GENERIC-NODEBUG-VIMAGE)# kgdb kernel.debug
/var/crash/vmcore.last
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address   = 0x30
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80b4d91c
stack pointer   = 0x28:0xfe046813a440
frame pointer   = 0x28:0xfe046813a470
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 33487 (sh)
Uptime: 15m16s
Dumping 1664 out of 16338
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel.GENERIC-NODEBUG-VIMAGE/zfs.ko...Reading
symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/zfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/zfs.ko
Reading symbols from
/boot/kernel.GENERIC-NODEBUG-VIMAGE/opensolaris.ko...Reading symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/opensolaris.ko.debug...
done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/opensolaris.ko
Reading symbols from
/boot/kernel.GENERIC-NODEBUG-VIMAGE/geom_eli.ko...Reading symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/geom_eli.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/geom_eli.ko
Reading symbols from
/boot/kernel.GENERIC-NODEBUG-VIMAGE/accf_http.ko...Reading symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/accf_http.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/accf_http.ko
Reading symbols from
/boot/kernel.GENERIC-NODEBUG-VIMAGE/coretemp.ko...Reading symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/coretemp.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/coretemp.ko
Reading symbols from /boot/kernel.GENERIC-NODEBUG-VIMAGE/aesni.ko...Reading
symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/aesni.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/aesni.ko
Reading symbols from
/boot/kernel.GENERIC-NODEBUG-VIMAGE/if_bridge.ko...Reading symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/if_bridge.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/if_bridge.ko
Reading symbols from
/boot/kernel.GENERIC-NODEBUG-VIMAGE/bridgestp.ko...Reading symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/bridgestp.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/bridgestp.ko
Reading symbols from /boot/kernel.GENERIC-NODEBUG-VIMAGE/ums.ko...Reading
symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/ums.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/ums.ko
Reading symbols from
/boot/kernel.GENERIC-NODEBUG-VIMAGE/netgraph.ko...Reading symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/netgraph.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/netgraph.ko
Reading symbols from
/boot/kernel.GENERIC-NODEBUG-VIMAGE/ng_netflow.ko...Reading symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/ng_netflow.ko.debug...done.
done.
Loaded symbols for /boot/kernel.GENERIC-NODEBUG-VIMAGE/ng_netflow.ko
Reading symbols from
/boot/kernel.GENERIC-NODEBUG-VIMAGE/ng_ksocket.ko...Reading symbols from
/usr/lib/debug//boot/kernel.GENERIC-NODEBUG-VIMAGE/ng_ksocket.ko.

Re: Support for Elantech trackpads (common on new laptops)

[Ben Woods]

On Thursday, 16 June 2016, Ben Woods  wrote:

> Hi everyone,
>
> [Vladimir Kondratyev] has kindly submitted a patch to bring support for
> Elantech trackpads, which are common in new laptops.
>
> ... It is attached to PR205690.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205690
>
> Could someone familiar with moused and mice drivers in
> sys/dev/atkbdc/psm.c please have a look?
>
> Thanks,
> Ben
>

Hi everyone,

Could I please ask someone who is familiar with moused and mice drivers to
have a look at this patch and consider its inclusion in FreeBSD 12-current?

A couple of people have been running this for some time now without
problems, and one synaptics user has confirm they are not seeing any
regressions in the synaptics driver with the patch applied.

Thanks,
Ben


-- 

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

Re: Somethign missing in my environment?

[Ben Woods]

On Monday, 22 August 2016, Willem Jan Withagen  wrote:
>
> Tried an old trick:
> Build on another system (10.3) and then mount
> /usr/src
> /usr/obj
> on the system to install on.
> But that generates things like:
> ERROR-tried-to-rebuild-during-make-install
> So I guess that doesn't work any longer.
>
> --WjW
>

That trick still works for me, but you have to make sure the build
environment and the install environment are the same. Namely that
/etc/make.conf and /etc/src.conf are the same on both machines, and that
they have the same architecture... Otherwise it will try and rebuild the
differences during the install process.

Regards,
Ben


-- 

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

Re: gfx-next update: drm-4.8-rc2 tagged in drm-next

[Ben Woods]

On Tuesday, 16 August 2016, Matthew Macy  wrote:

> As of this moment sys/dev/drm in the drm-next tree is sync with
> https://github.com/torvalds/linux drivers/gpu/drm (albeit only for the
> subset of drivers that FreeBSD supports -  i915, radeon, and amdgpu). I
> feel this is a bit of a milestone as it means that it is possible that in
> the future graphics support on FreeBSD could proceed in lockstep with Linux.
>
> In addition I have IFCed both drm-next-4.6 and drm-next to HEAD as of
> today.
>
> Once I'm done working on Kaby Lake support I intend to get radeon and
> amdgpu to the point where they work as well as i915. Following that we'll
> need to spend some time resolving general correctness issues.
>
> -M
>

May I just say, congratulations on the great milestone, and thank you very
much for your efforts!

I owe you beer.

Thanks,
Ben


-- 

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

ACPI errors when booting laptop

[Ben Woods]

Hi everyone,

I get the following ACPI errors in my dmesg when booting my NEC Lavie HZ750
laptop with FreeBSD 12-current. I have noticed things not functioning
correct (except suspend/resume not working), but then again I don't really
know much about ACPI or what I should expect to see. Any ideas what the
problem is?

Full dmesg is also attached.

acpi0:  on motherboard
acpi_ec_ecdt_probe: can't get handle
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC._REG] (Node
0xf80005494980), AE_NOT_EXIST (20160527/psparse-559)
acpi0: Power Button (fixed)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160527/exfldio-320)
ACPI Error: Method parse/execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA]
(Node 0xf8000549a640), AE_NOT_EXIST (20160527/psparse-559)
ACPI Error: Method execution failed [\134_SB.PCI0.LPCB.EC.BAT1._STA] (Node
0xf8000549a640), AE_NOT_EXIST (20160527/uteval-111)
ACPI Error: No handler for Region [EC__] (0xf8000548fc80)
[EmbeddedControl] (20160527/evregion-180)
ACPI Error: Region EmbeddedControl (ID=3) has no handler
(20160

Re: Support for Elantech trackpads (common on new laptops)

[Ben Woods]

On Thu, Jun 16, 2016 at 11:46:41AM +0200, Ben Woods wrote:
> On Thu, Jun 16, 2016 at 09:14:20AM +0200, Raphael 'kena' Poss wrote:
> > Please give credit where credit is due, the patch was originally posted 
> > here:
> > 
> > https://lists.freebsd.org/pipermail/freebsd-mobile/2015-September/013327.html
> > 
> 
> I've done some testing, and the short update is "it's working fine for me".
> I love having two-finger scroll support!
> 
> A few more testing details added to the bug report.
> 
> Vladimir: Thanks for porting this from OpenBSD!
> Thanks to the OpenBSD developers stsp, mpi, jcs, shadchin for the initial 
> work on this [1].
> Raphael: Thanks for ensuring this was captured in Bugzilla and for porting to 
> 10-STABLE.
> Adrian: Thanks in advance for your testing and help!
> 
> [1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pckbc/pms.c
> 
> Regards,
> Ben

Looking closer, it looks like this is largely Vladimir's original work, which
uses some of the absolute mode driver work from OpenBSD.

Regards,
Ben

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

Re: Support for Elantech trackpads (common on new laptops)

[Ben Woods]

On Thu, Jun 16, 2016 at 09:14:20AM +0200, Raphael 'kena' Poss wrote:
> Please give credit where credit is due, the patch was originally posted here:
> 
> https://lists.freebsd.org/pipermail/freebsd-mobile/2015-September/013327.html
> 
> Adrian Chadd  schreef op 16 juni 2016 04:20:13 CEST:
> >I'll test it out tonight to see if anything is regressing
> >
> >a-
> >
> >On 15 June 2016 at 16:50, Ben Woods  wrote:
> >> Hi everyone,
> >>
> >> Raphael Poss has kindly submitted a patch to bring support for Elantech
> >> trackpads, which are common in new laptops.
> >>
> >> I have tidied the patch so that it applies cleanly to 11-current (as of
> >> r301929). It is attached to PR205690.
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205690
> >>
> >> Could someone familiar with moused and mice drivers in sys/dev/atkbdc/psm.c
> >> please have a look?
> >>
> >> Thanks,
> >> Ben

I've done some testing, and the short update is "it's working fine for me".
I love having two-finger scroll support!

A few more testing details added to the bug report.

Vladimir: Thanks for porting this from OpenBSD!
Thanks to the OpenBSD developers stsp, mpi, jcs, shadchin for the initial work 
on this [1].
Raphael: Thanks for ensuring this was captured in Bugzilla and for porting to 
10-STABLE.
Adrian: Thanks in advance for your testing and help!

[1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pckbc/pms.c

Regards,
Ben

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

Support for Elantech trackpads (common on new laptops)

[Ben Woods]

Hi everyone,

Raphael Poss has kindly submitted a patch to bring support for Elantech
trackpads, which are common in new laptops.

I have tidied the patch so that it applies cleanly to 11-current (as of
r301929). It is attached to PR205690.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205690

Could someone familiar with moused and mice drivers in sys/dev/atkbdc/psm.c
please have a look?

Thanks,
Ben

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

Re: libpam.so lost in update to 11.0-ALPHA3

[Ben Woods]

On Tuesday, 14 June 2016, Pavel Timofeev  wrote:

>
> 14 июня 2016 г. 10:37 пользователь "Ben Woods"  > написал:
> >
> > On 14 June 2016 at 09:11, René Ladan  > wrote:
> >
> > > Hi,
> > >
> > > I updated my pkgbase installation (11.0-amd64 from a few weeks ago) to
> > > 11.0-ALPHA3. Building and installing went fine but it turns out that
> > > libpam.so* is lost in the update (both the symlink and the actual so,
> > > currently so.6) :
> > >
> > > # pkg upgrade
> > > # pkg autoremove
> > >< > > version lower)
> > >   << yes, I forgot to run mergemaster>>
> > > # reboot
> > >   < > >
> > > Is this a known bug?
> > >
> > > Regards,
> > > René
> > >
> >
> > Michael Lucas mentioned on twitter a few days ago that pam was broken
> > recently in FreeBSD current.
> >
> > Michael: was this a problem with libpam.so going missing? Were you using
> > pkgbase, or is this an issue with the normal build/install system also?
> >
> > Regards,
> > Ben
> >
> > --
>
> Hi!
> I have the same problem with normal build/install system.
>

Ok, thanks for the feedback.

Bringing in the FreeBSD-current@ mailing list as it is not a problem with
PkgBase, but with 11-current.

Regards,
Ben


-- 

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

2 config files not installed from recent 11-current snapshot

[Ben Woods]

Hi everyone,

I recently reinstalled my FreeBSD laptop using a 11-current snapshot from
the end of April.

Today I noticed that 2 cofiguration files were not install in the system:
/etc/ppp/ppp.conf
/etc/dma/dma.conf

I have done 2 PkgBase upgrades since then (with an etcupdate run also after
each upgrade), but PkgBase shouldn't have touched these files since config
files are not included in packages yet.

Given that FreeBSD 11 is nearing release, it might be worth double checking
that this isn't a problem on the latest 11 snapshots (those 2 files are on
the system after the installer is run). I would check myself, but am
travelling and don't have the resources, sorry.

Cheers,
Ben


-- 

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

Re: UEFI dual boot zfs root

[Ben Woods]

On Tuesday, 17 May 2016, Warren Block  wrote:

> On Sun, 15 May 2016, Andreas Nilsson wrote:
>
> Hello,
>>
>> I'm trying to install current on my lenovo x1 yoga ( and keeping it dual
>> boot for now).
>>
>> I have a fair amount of disk free after resizing. I can't seem to workout
>> how to do the partitioning. Do I only need the freebsd-zfs partition (
>> assuming no/zvol-swap?
>>
>
> I would think, but have not tested ZFS with UEFI.
>
> Do I manually copy boot1.efi to the existing EFI partition?
>>
>
> Yes.  Mount the EFI partition with msdosfs, then copy boot1.efi to
> /EFI/BOOT/.  Then comes the tricky part, getting the UEFI firmware to add
> that as a boot option.  In a Dell UEFI system, it could be added to the
> boot options, and the firmware has the user select the file from the EFI
> partition for that option.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>

Indeed, just 4 days ago I installed a recent snapshot of FreeBSD 11
current, with root on ZFS and UEFI.

I had to do 2 steps manually, as they were not supported by the installer
as an auto option:

1. The auto root on ZFS settings don't let you use a partition or spare
space... You must give it a full disk. But because I was dual booting
Windows I chose manual partitioning, dropped to a shell and setup the zpool
and zfs datasets manually, with altroot=/mnt. Rather than follow one of the
outdated wiki manuals, I used them as a general guide, but read the
bsdinstall auto shell script to set it up with the same datasets and
properties.

2. After the install had completed, I had to mount my efi partition as
msdosfs and copy the boot1.efi to it. For me, I have installed the rEFInd
boot loader, so I just copy the file into /EFI/Boot/ and it shows up in the
menu upon boot.
http://www.rodsbooks.com/refind/

The FreeBSD EFI loading of a ZFS file system works great!

Cheers,
Ben


-- 

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

Re: UEFI root on ZFS (encrypted?)

[Ben Woods]

On Sunday, 15 May 2016, Allan Jude  wrote:

> On 2016-05-15 05:19, Ben Woods wrote:
> > Hi everyone,
> >
> > I would like to reinstall my laptop to get root on ZFS with UEFI. I will
> > use a recent snapshot image to install FreeBSD 11 current.
> >
> > There has been a lot of good work on this lately, and I have fallen out
> > of touch with the status. A couple of questions:
> >
> > 1. Can the UEFI loader now boot root on ZFS without a freebsd-boot
> > partition?
>
> Yes, you just need the EFI partition
>
> >
> > 2. Can it do it with geli encryption?
> >
>
> Not yet
>
> --
> Allan Jude
>

Ok, thanks for that. Is there a review on phabricator (or multiple) that I
can build a release iso with and help test for this setup (with or without
it being in the installer)?

A search of phabricator shows there are a number that could be related.

Thanks,
Ben


-- 

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

UEFI root on ZFS (encrypted?)

[Ben Woods]

Hi everyone,

I would like to reinstall my laptop to get root on ZFS with UEFI. I will
use a recent snapshot image to install FreeBSD 11 current.

There has been a lot of good work on this lately, and I have fallen out of
touch with the status. A couple of questions:

1. Can the UEFI loader now boot root on ZFS without a freebsd-boot
partition?

2. Can it do it with geli encryption?

3. Have these been added to the installer, so that if I grab a recent
snapshot iso I can install it?

Thanks again for all the work on this.

Regards,
Ben


-- 

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

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

On Saturday, 7 May 2016, David Wolfskill  wrote:
>
> > If you list 2 kernels in the KERNCONF variable, why is it astonishing
> that
> > 2 kernels get installed? Even if the old behaviour was to only install 1
> > kernel, if you are listing 2 kernels in KERNCONF presumably that is
> because
> > you want to install 2 kernels?
>
> Errr... no: I don't.  At least, not on the machine where I built them.
>
> The process I've been using (with "variations on the theme" over the
> years) since around 1999 or so for updating my "production" machines at
> home is described in some detail at
> ; in summary, the
> production machines (only) mount /usr/src & /usr/obj from a dedicated
> "build machine" via NFS during the "upgrade window," during which time
> the production machine's kernel & userland are installed (from the build
> machine, which had built them).
>
> The build machine does all of the compilation; each production machine
> merely does installation.
>
> There is no value in "installing" the production machine kernels on the
> build machine -- and I never configured the build machine with the
> expectation that the root filesystem would ever need to be big enough to
> store kernels that would never be loaded on that machine.
>
> Fundamentally, just as we separate "build{world,kernel}" targets from
> "install{world,kernel}" targets, it is appopriate to separate -- and not
> conflate -- building of a kernel on a machine from installing that kernel
> on that machine.
>

Thanks for the explanation - the use case and POLA are clear to me now.

Perhaps we need the "make packages" to somehow ignore this variable, as it
makes that would not want to install multiple kernels on a machine, but
that you may want to build multiple kernel packages anyway, for use on
other machines?

Regards,
Ben

-- 

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

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

On 7 May 2016 at 09:48, Ngie Cooper (yaneurabeya) 
wrote:

> glebius changed the defaults to fix POLA, but the naming per the behavior
> is confusing. Right now the behavior between ^/head and ^/stable/10
> before/now match -- I just had to wrap my mind around the default being the
> affirmative of a negative (i.e. only install one kernel, as opposed to
> install all extra kernels by default).
> -Ngie


Indeed, I am not sure I understand the POLA violation entirely (ignoring
the fact that this variable requires affirmation of a negative).

If you list 2 kernels in the KERNCONF variable, why is it astonishing that
2 kernels get installed? Even if the old behaviour was to only install 1
kernel, if you are listing 2 kernels in KERNCONF presumably that is because
you want to install 2 kernels?

Regardless, perhaps it is ok to leave behaviour on stable 9/10 unchanged,
but to make the behaviour on head to install multiple kernels by default?
That is the option that makes sense for PkgBase (build multiple kernel
packages if more than one are listed in KERNCONF).

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

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

On 7 May 2016 at 09:41, Glen Barber  wrote:

> I think this raises a larger question - did "something" change that
> otherwise violates POLA?  The commit recently was intended to revert
> a POLA violation, so maybe I am not entirely clear on what branch this
> affects.
>
> Are we talking about head or stable/10 here?
>
> Glen
>

I am talking about head, which no longer installs/packages multiple kernels
by default.
https://svnweb.freebsd.org/base/head/Makefile.inc1?revision=299088&view=markup

Whilst the r299088 commit is referring to a stable POLA violation, the
commit itself is a change to head with a proposed MFC after 3 days. Its
interesting, because this has surprised me when testing PkgBase on head, as
the behaviour has changed from the initial announcement.

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

Re: NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

On Saturday, 7 May 2016, Glen Barber  wrote:

> With 'installkernel', the first kernel listed in KERNCONF is installed
> as the default (/boot/kernel), and subsequent kernels are installed with
> the kernel name included in the path (/boot/kernel.${INSTKERNNAME}).  In
> both cases (source-based upgrades and with pkgbase), the behavior will
> remain the same.
>
> Glen
>

Hi Glen,

With the recent commit mentioned previously, only the first kernel listed
in KERNCONF is installed unless make.conf contains the following line:
NO_INSTALLEXTRAKERNELS=no

This affects both source-based upgrades (make installkernel) and package
building (make packages).

Is this the desired behaviour?

Regards,
Ben


-- 

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

NO_INSTALLEXTRAKERNELS and PkgBase

[Ben Woods]

Hi everyone,

The commit in r299088 changes the behaviour for building multiple kernels
when the KERNCONF value contains multiple (space-separated) kernel conf
names.
https://svnweb.freebsd.org/base?view=revision&revision=299088

When PkgBase was announced by Glen Barber in March, note 4 of his email
stated that multiple kernels would be built and packaged if multiple are
listed in KERNCONF.
https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-March/32.html

Can I please clarify the desired behaviour so that I can update the PkgBase
wiki article accordingly? I personally think it is quite a neat feature to
build multiple kernels if they are listed in KERNCONF.

Regards,
Ben

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

Re: Multicast routing on FreeBSD 11 current

[Ben Woods]

On 24 January 2016 at 11:36, Otacílio  wrote:

> Em 24/01/2016 07:24, Olivier Cochard-Labbé escreveu:
>
>> On Sun, Jan 24, 2016 at 9:41 AM, Ben Woods  wrote:
>>
>> Hi everyone,
>>>
>>> Could someone running FreeBSD current on a test machine try loading the
>>> ip_mroute driver on their machine?
>>>
>>> ​Hi,
>>
>> no problem here:
>>
>> root@lame5 # uname -a
>> FreeBSD lame5.bsdrp.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294522: Thu
>> Jan 21 20:07:04 CET 2016
>> r...@lame5.bsdrp.net:/usr/obj/usr/src/sys/GENERIC-NODEBUG
>>   amd64
>> root@lame5 # kldload ip_mroute
>> root@lame5
>> ​
>> # kldstat -m ip_mroute
>> Id  Refs Name
>> 4971 ip_mroute
>>
>>
>> ​Regards,
>>
>> Olivier​
>>
>>
> No problem here also.
>
> root@nostromo:~ # kldload ip_mroute
> root@nostromo:~ # kldstat
> Id Refs AddressSize Name
>  1   34 0x8020 1e39ca8  kernel
>  21 0x8203b000 e3b8 cuse.ko
>  31 0x8204a000 3d90 pty.ko
>  41 0x82221000 57b8 fdescfs.ko
>  51 0x82227000 a3ac linprocfs.ko
>  61 0x82232000 695a linux_common.ko
>  71 0x82239000 26f8avboxguest.ko
>  81 0x8226 7a9  vboxvideo.ko
>  91 0x82261000 52092drm2.ko
> 101 0x822b4000 2679 iicbus.ko
> 111 0x822b7000 1f6a imgact_binmisc.ko
> 121 0x822b9000 657f nullfs.ko
> 131 0x822c abe8 tmpfs.ko
> 141 0x822cb000 ceff ip_mroute.ko
> root@nostromo:~ # uname -a
> FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294319M: Tue Jan 19
> 20:29:21 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/GENERIC  amd64
>


Thanks for your feedback everyone. Having spent some time now
investigating, I have confirmed that this problem is related to VIMAGE.

With VIMAGE enabled in the kernel, loading the ip_mroute kernel module will
fail.

With VIMAGE disabled on the same kernel source (no other changes), loading
the ip_mroute kernel module works fine.

I have submitted this bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206583

Regards,
Ben

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

Re: Multicast routing on FreeBSD 11 current

[Ben Woods]

On Saturday, 23 January 2016, Ben Woods  wrote:
>
> I am running the GENERIC kernel, except with VIMAGE enabled and SCTP
> disabled.
>
> When I try to load the kernel module, I am getting an error:
> % sudo kldload -v ip_mroute
> kldload: an error occurred while loading the module. Please check dmesg(8)
> for more details.
> % dmesg
> linker_load_file: Unsupported file type
>
> Any ideas what could be causing this error?
>
> Thanks for your help.
>
> Regards,
> Ben
>
> --
> From: Benjamin Woods
> woods...@gmail.com 
>

Hi everyone,

Could someone running FreeBSD current on a test machine try loading the
ip_mroute driver on their machine?

This is to enable multicast routing, but I am wondering if it fails to load
for everyone, or it is specific to my build some how.

I am running r294463, please let me know which version you are running if
it works or doesn't work.

Regards,
Ben


-- 

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

Re: forwarding didn't work if wlan0 is member of a bridge

[Ben Woods]

On Wednesday, 23 December 2015, Adrian Chadd  wrote:

> Hi,
>
> inet 10.239.142.126 netmask 0xffe0 broadcast 10.239.142.127
>
> This looks like a problem with your addressing. That netmask != that
> broadcast.
>
> Please recheck your networking setup!
>
>
> -a
>

That broadcast looks correct for me for a bet mask of 0xffe0 (/27).

http://jodies.de/ipcalc?host=10.239.142.126&mask1=27&mask2=

Regards,
Ben


-- 

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

Re: OpenSSH HPN

[Ben Woods]

On Wednesday, 11 November 2015, John-Mark Gurney  wrote:

> Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > I have to agree that there are cases when the NONE cipher makes sense,
> and
> > it is up to the end user to make sure they know what they are doing.
> >
> > Personally I have used it at home to backup my old FreeBSD server (which
> > does not have AESNI) over a dedicated network connection to a backup
> server
> > using rsync/ssh. Since it was not possible for anyone else to be on that
> > local network, and the server was so old it didn't have AESNI and would
> > soon be retired, using the NONE cipher sped up the transfer
> significantly.
>
> If you have a trusted network, why not just use nc?
>

Honest answer: ignorance of how I can use netcat together with rsync.


-- 

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

Re: OpenSSH HPN

[Ben Woods]

On Wednesday, 11 November 2015, Bryan Drewery  wrote:

> On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > My vote is to remove the HPN patches.  First, the NONE cipher made more
> > sense back when we didn't have AES-NI widely available, and you were
> > seriously limited by it's performance.  Now we have both aes-gcm and
> > chacha-poly which it's performance should be more than acceptable for
> > today's uses (i.e. cipher performance is 2GB/sec+).
>
> AES-NI doesn't help the absurdity of double-encrypting when using scp or
> rsync/ssh over an encrypted VPN, which is where NONE makes sense to use
> for me.
>

I have to agree that there are cases when the NONE cipher makes sense, and
it is up to the end user to make sure they know what they are doing.

Personally I have used it at home to backup my old FreeBSD server (which
does not have AESNI) over a dedicated network connection to a backup server
using rsync/ssh. Since it was not possible for anyone else to be on that
local network, and the server was so old it didn't have AESNI and would
soon be retired, using the NONE cipher sped up the transfer significantly.

If the patch is made easy enough to maintain (as some subsequent posts have
implied), I quote the NONE cipher stays. I would even like to see it
compiled in by default (but disabled in the default configuration file).
That way you wouldn't need a custom compiled base to use it - just edit the
config file.

Regards,
Ben


-- 

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

Re: CFT: wpa_supplicant/hostapd 2.5

[Ben Woods]

On 14 October 2015 at 13:00, Rui Paulo  wrote:

> Hi,
>
> Please download and test the wpa_supplicant/hostapd import patch:
>
> http://people.freebsd.org/~rpaulo/patches/wpa-2.5.diff
>
>
> Changelog:
>
> http://w1.fi/cgit/hostap/plain/hostapd/ChangeLog
> http://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog
>
>
> Please report success/failures.
>
> Thanks,
> --
> Rui Paulo
>


Hi Rui,

I've build FreeBSD head with your patch and have been using it on my home
wireless router for a couple of days now (running on a Netgate RCC-VE 8860
running FreeBSD head amd64 with AR9280 wifi chip).

All working fine for me. Thanks for your work.

Regards,
Ben

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

Re: E1000 mbuf leaks

[Ben Woods]

On Monday, July 27, 2015, Hans Petter Selasky  wrote:

> Hi,
>
> I'm currently doing some busdma work, and possibly stepped over some
> driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf chain
> is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()" for that
> error code or is there a possible memory leak in all E1000 drivers? See
> attached patch.


Would this explain the high mbuf usage seen on pfsense when using the
igb(4) or em(4) Intel NIC drivers?


https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Intel_igb.284.29_and_em.284.29_Cards

Regards,
Ben


-- 

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

ssh None cipher

[Ben Woods]

Whilst trying to replicate data from my FreeNAS to my FreeBSD home theater
PC on my local LAN, I came across this bug preventing use of the None
cipher:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=163127

I think I could enable the None cipher by recompiling base with a flag in
/etc/src.conf.

Is there any harm in enabling this by default, but having the None cipher
remain disabled in /etc/ssh/sshd_config? That way people wouldn't have it
on my default, but wouldn't have to recompile to enable it.

Thoughts?


-- 

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