Re: small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

[Benjamin Kaduk]

On Tue, Jul 11, 2017 at 11:48:55AM +, Rick Macklem wrote:
> Cy Schubert wrote:
> >
> >How about a warning message + an UPDATING entry + no MFC? And, relnotes =
> >yes to say we now support RFC7530 in 12.0?
> Sounds fine to me. I'll wait to see if there are more comments.

Yes, this seems like the sort of thing best done on a major version
boundary and not MFC'd.

-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"

jemalloc_arena.c:821: Failed assertion: "nstime_compare(&decay->epoc h, &time) <= 0")

[Don Lewis]

I'm trying to stabilize my new-ish Ryzen package build box.  I've run
into this error a couple of times:
  (: jemalloc_arena.c:821: Failed assertion: 
"nstime_compare(&decay->epoc h, &time) <= 0")
most recently today when building llvm40. It seems to happen somewhat
randomly.  I don't remember seeing it before the jemalloc 5.0.0 import.

What does it mean?  Any ideas on how I might mitigate the problem?

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

Re: Panic on boot after upgrade from r320827 -> r320869

[Michael Butler]

On 07/11/17 13:13, I wrote:
Take sdhci out of the kernel and try again. If that works, it tells us 
one

thing (need to troubleshoot sdhci stuff more). If not it tells us another
(need to troubleshoot CAM more), do we get errors with the ATA_IDENTIFY
command? Does it try multiple times per AHCI port? What AHCI device do 
you
have? You may need to scroll back with the screen-lock / pageup keys 
to see

these messages.


 [ .. snip .. ]

I'll try this tonight when I'm back at home. The laptop concerned uses 
the ICH-7M part in "legacy mode" so it doesn't do AHCI at all :-(


Without sdhci and mmc, it actually boots but everything KDE aborts with 
signal 6 :-(


I'm not prepared to rebuild the ~1900 ports on this box to pursue this 
further,


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"

VLAN routing fails from VLAN -> non VLAN [was: Re: static routes on VLAN on CURRENT]

[O. Hartmann]

On Mon, 3 Jul 2017 06:29:41 +0200
"O. Hartmann"  wrote:


Hello,

I figured some severe problemes with the configuration of the cheap SoHo
smart-managed switch Netgear GS110TP. This piece of crap is way to smart for me.
For short: If one leaves a port as "U" (untagged) withing a VLANG group in the
membership configuration and this port is also member of another VLAN as
"U" (untagged) (Cisco calls those ports access ports), nothing works. There is
obviously no consistency check for such mistakes.

So, after that, I was able to manage separated VLANs on the switch which get
routed by the a freeBSD 12-CURRENT. The uplink port (igb1) on the FBSD box
"trunks" all VLANs to the switch. 

Now, the router shows this:

Internet:
DestinationGatewayFlags   UseMtu  Netif Expire
defaultxxx.xxx.xxx.xxxUS  513   1492   tun0
xxx.xxx.xxx.xxxlink#12UHS   0   1492   tun0
xxx.xxx.xxx.xxxlink#12UHS   0  16384lo0
127.0.0.1  link#5 UH  111  16384lo0
192.168.2.0/24 link#7 U 0   1500 igb1.2
192.168.2.1link#7 UHS   0  16384lo0
192.168.10.0/24link#8 U 0   1500igb1.10
192.168.10.1   link#8 UHS   0  16384lo0
192.168.66.0/24link#10U 0   1500igb1.66
192.168.66.1   link#10UHS   0  16384lo0
192.168.100.0/24   link#11U 0   1500   igb1.100
192.168.100.1  link#11UHS   0  16384lo0
192.168.0.0/24 link#9 U 0   1500  igb1.1000
192.168.0.1link#9 UHS   0  16384lo0

[ schnipp ] 

tun0 is the ppp opened device towards my VDSL modem.

ssh on the router box is listening on 192.168.0.1 - this for completeness.

I also have FreeBSD hosts in networks   192.168.0.0/24 and 192.168.10.0/24
(network 192.168.10.0/24 is on a dual port NIC, the host is not gatewaying,
checking pinging from 192.168.10.0/24 to 192.168.0.0/24 without the trunk port
from switch towards the router doesn't work, but works, when trunk port is
connected - I consider this a s quick test that routing works).

> > 
> > [ sysctl stuff snipped - not relevant, I think ]
> >   
> > > > > From the routing device itself, it is possible to ssh into a VoIP
> > > > > client attached to the switch to which igb1.2 trunks the net.
> > > > > Pinging is also possible.
> > > > > 
> > > > > Attached to igb1 is the 192.168.0.1/24 network with a bunch of
> > > > > hosts. From any host within this network it is possible to ping
> > > > > the 192.168.2.0/24 network and its hosts within, but no SSH, not
> > > > > web (80, 443). 
> > > > >
> > > > 

The problem still persists.

I did some experiments by setting trying to ssh into several hosts from several 
spots.

the router has 192.168.0.1:ssh
192.168.0.0/24 is on igb1.1000

ping: 192.168.0.111 -> 192.168.0.1 : ok
ssh: 192.168.0.111 -> 192.168.0.1 : ok
ping: 192.168.0.1 -> 192.168.0.111 : ok
ssh: 192.168.0.111 -> 192.168.0.111 : ok
ping: 192.168.0.111 -> google.com : ok

192.168.66.0/24 is on igb1.66
host 192.168.66.111 is a notebook with sshd enabled

ping: 192.168.66.111 -> 192.168.0.1 : ok
ssh: 192.168.66.111 -> 192.168.0.1 : NOT ok
ssh: 192.168.0.1 -> 192.168.66.111 : NOT ok (do not understand this)
ping: 192.168.66.111 -> 8.8.8.8 (no DNS): ok

Ping from any VLAN to another VLAN host without the trunking cable connected to 
the
switch fails. With the cable plugged in, ping works.

ping: 192.168.0.1 -> 192.168.2.50 (VoIP phone): ok
ssh: 192.168.0.1 -> 192.168.2.50 (VoIP phone): ok
ping: 192.168.0.111 -> 192.168.2.50 (VoIP phone): ok
ssh 192.168.0.111 -> 192.168.2.50 (VoIP phone): NOT ok


> > > > Weird - if icmp (ping) works and tcp (web, ssh) not, something is
> > > > filtering traffic. But with net.inet.ip.forwarding=0, even pinging
> > > > host should not work. Try tcpdump to see what's going on.   
> > > 

[ schnipp ]

> > 
> > Then I just recommend tcpdump - I would use 'tcpdump -nepi igb1.2 host
> > 192.168.0.x and host 192.168.2.y' and 'tcpdump -nepi igb1 host
> > 192.168.0.x and host 192.168.2.y' in two session and compare outputs
> > when pinging from 192.168.0.x to 192.168.2.y and when trying to ssh
> > from the former to the later. Also there is a question then what these
> > two devices are, what OS are they running, their network
> > configuration... then we can analyse the problem better. 

Since the VoIP phone has a very restricted interface and shell capability set, 
I need to
do this from another FreeBSD 12-CURRENT host and as I showed above, I put that 
host into
VLAN 66, bound to igb1.66 -> 192.168.66.1/24 on the router:

Pinging from 192.168.0.111 <-> 192.168.66.111 gives on both machines nice 
"ping-pong"
results: echo request and echo reply.

But ssh from one 

Re: Run binary from test suite

[Ngie Cooper]

On Tue, Jul 11, 2017 at 10:38 AM, Panagiotes Mousikides
 wrote:
> (Resending due to moderation.)
>
> Hello!
>
> I'm a Google Summer of Code student, writing some tests for the FreeBSD test
> suite, and putting them under src/tests.  I need to run some binaries,
> specifically pfctl.
>
> How should I call pfctl from my test scripts?  Should I call it directly and
> let the shell find the binary in the path?  Or should I find where the build
> version got created (somewhere under /usr/obj) and call that? How do I find
> where the binary ended up getting created in that case?
>
> Best regards,
> Panagiotes

Hello Panagiotes,
Please call pfctl from $PATH -- don't hardcode the path, ever.
I'll be looking at making "make check" more developer friendly in the
next 3-6 months, so running "make check" from usr.sbin/pf/... will
automatically add a set path/environment which hooks in to *.test.mk.
The goal of this is to simplify developer use for "make check".
Also, if the tests (for whatever reason) aren't going to be
installed alongside pfctl, e.g., tests/sys/pf/... please add 'atf_set
"require.progs" "pfctl"' to the header to ensure that the test is
skipped if/when pfctl isn't installed on the system.
Cheers,
-Ngie
___
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"

Run binary from test suite

[Panagiotes Mousikides]

Hello!

I'm a Google Summer of Code student, writing some tests for the FreeBSD 
test suite, and putting them under src/tests.  I need to run some 
binaries, specifically pfctl.


How should I call pfctl from my test scripts?  Should I call it directly 
and let the shell find the binary in the path?  Or should I find where 
the build version got created (somewhere under /usr/obj) and call that?  
How do I find where the binary ended up getting created in that case?


Best regards,
Panagiotes

___
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"

Run binary from test suite

[Panagiotes Mousikides]

(Resending due to moderation.)

Hello!

I'm a Google Summer of Code student, writing some tests for the FreeBSD 
test suite, and putting them under src/tests.  I need to run some 
binaries, specifically pfctl.


How should I call pfctl from my test scripts?  Should I call it directly 
and let the shell find the binary in the path?  Or should I find where 
the build version got created (somewhere under /usr/obj) and call that? 
How do I find where the binary ended up getting created in that case?


Best regards,
Panagiotes

___
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: Run binary from test suite

[Alan Somers]

Are you using pfctl at build time or does your ATF test script need
it?  I'm assuming the latter.  In that case, it's fine to call it
directly.  Your PATH will be correctly configured.  Don't use
/usr/obj, because that may no longer exist by the time somebody is
running the ATF test.
-Alan

On Tue, Jul 11, 2017 at 11:13 AM, Panagiotes Mousikides
 wrote:
> Hello!
>
> I'm a Google Summer of Code student, writing some tests for the FreeBSD test
> suite, and putting them under src/tests.  I need to run some binaries,
> specifically pfctl.
>
> How should I call pfctl from my test scripts?  Should I call it directly and
> let the shell find the binary in the path?  Or should I find where the build
> version got created (somewhere under /usr/obj) and call that?  How do I find
> where the binary ended up getting created in that case?
>
> Best regards,
> Panagiotes
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Panic on boot after upgrade from r320827 -> r320869

[Michael Butler]

On 7/11/17 1:09 PM, Warner Losh wrote:

On a machine with SDHCI, a clean rebuild (after "r -rf /usr/obj") refuses
to find /dev/ada0 :-(



Take sdhci out of the kernel and try again. If that works, it tells us one
thing (need to troubleshoot sdhci stuff more). If not it tells us another
(need to troubleshoot CAM more), do we get errors with the ATA_IDENTIFY
command? Does it try multiple times per AHCI port? What AHCI device do you
have? You may need to scroll back with the screen-lock / pageup keys to see
these messages.

Plus we know we have at least one bug in meta-mode rebuilding since not
everything is being rebuilt that should be across this change.

The change itself didn't change CAM except for copying one set of data it
didn't used to, into a structure whose size grew (which is why we're seeing
crashes / failures for a 'cross-threaded' rebuild). There's nothing else
that changed (especially after I removed the bogus debug printfs) that I
can see in auditing the change.

I was really hoping David's machine would exhibit the behavior since we're
co-workers and have a shared infrastructure for debugging we can leverage.


I'll try this tonight when I'm back at home. The laptop concerned uses 
the ICH-7M part in "legacy mode" so it doesn't do AHCI at all :-(


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"

Re: Panic on boot after upgrade from r320827 -> r320869

[Bryan Drewery]

On 7/11/17 10:09 AM, Warner Losh wrote:
> Plus we know we have at least one bug in meta-mode rebuilding since not
> everything is being rebuilt that should be across this change.

Yes I'm looking into that.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Panic on boot after upgrade from r320827 -> r320869

[Warner Losh]

On Tue, Jul 11, 2017 at 10:47 AM, Michael Butler  wrote:

> On 7/11/17 10:32 AM, Warner Losh wrote:
>
>> On Tue, Jul 11, 2017 at 6:13 AM, David Wolfskill 
>> wrote:
>>
>>> I believe that each of the machines has an MMC slot, but I also believe
>>> that in each case, it is empty.
>>>
>>> Is there anything else I might be able to do to help resolve this?
>>>
>>>
>> Try building a kernel without sdhci in it.
>>
>> It's looking like the scans for ata devices are returning errors on the
>> desktop machine you have, which shouldn't have been happening.
>>
>> Also, can you try a 100% clean build of GENERIC to make sure there's not a
>> meta-mode bug?
>>
>
> On a machine with SDHCI, a clean rebuild (after "r -rf /usr/obj") refuses
> to find /dev/ada0 :-(
>

Take sdhci out of the kernel and try again. If that works, it tells us one
thing (need to troubleshoot sdhci stuff more). If not it tells us another
(need to troubleshoot CAM more), do we get errors with the ATA_IDENTIFY
command? Does it try multiple times per AHCI port? What AHCI device do you
have? You may need to scroll back with the screen-lock / pageup keys to see
these messages.

Plus we know we have at least one bug in meta-mode rebuilding since not
everything is being rebuilt that should be across this change.

The change itself didn't change CAM except for copying one set of data it
didn't used to, into a structure whose size grew (which is why we're seeing
crashes / failures for a 'cross-threaded' rebuild). There's nothing else
that changed (especially after I removed the bogus debug printfs) that I
can see in auditing the change.

I was really hoping David's machine would exhibit the behavior since we're
co-workers and have a shared infrastructure for debugging we can leverage.

Warner
___
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: Panic on boot after upgrade from r320827 -> r320869

[Michael Butler]

On 7/11/17 10:32 AM, Warner Losh wrote:

On Tue, Jul 11, 2017 at 6:13 AM, David Wolfskill 
wrote:

I believe that each of the machines has an MMC slot, but I also believe
that in each case, it is empty.

Is there anything else I might be able to do to help resolve this?



Try building a kernel without sdhci in it.

It's looking like the scans for ata devices are returning errors on the
desktop machine you have, which shouldn't have been happening.

Also, can you try a 100% clean build of GENERIC to make sure there's not a
meta-mode bug?


On a machine with SDHCI, a clean rebuild (after "r -rf /usr/obj") 
refuses to find /dev/ada0 :-(


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"

r320183 (rpc.lockd cleanup) breaks virtualbox-ose build

[Don Lewis]

This is a really strange problem ...

Last week I upgraded my 12.0-CURRENT package build box from r318774 to
r320570.  I also upgraded the poudriere jail to match.  When I went to
build packages, the virtualbox-ose build failed due to ar segfaulting.

To debug I created a new 12.0-CURRENT poudriere jail with rev r318774
and the build passed.   I then bisected, which took most of the last
week, and found that this commit is what is causing the breakage:

  r320183 | delphij | 2017-06-20 23:34:06 -0700 (Tue, 20 Jun 2017) | 12 lines

  Reduce code duplication in rpc.lockd.

  Reuse create_service code instead of duplicating it in
  lookup_addresses for kernel NLM.

  As a (good) side effect this also fixed a few issues that were
  already fixed in the former but never applied to the latter.

and it only touches usr.sbin/rpc.lockd/lockd.c.

If I rebuild the r320570 jail with the r320183 change backed out, and
then I can successfully build virtualbox-ose.  I confirmed this on
another machine.

I have no idea why the rpc.lockd source would affect ar inside a
poudriere jail where NFS isn't used.  Like I said, really strange ...
ex

___
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: Panic on boot after upgrade from r320827 -> r320869

[David Wolfskill]

On Tue, Jul 11, 2017 at 08:32:26AM -0600, Warner Losh wrote:
> ...
> > While O. Hartmann had written to indicate the he had identified r320844
> > as the culprit, and I had other reason to suspect it, I was a bit busy
> > at work yesterday, and unable to determine this for myself empirically.
> >
> > I went ahead and updated my "head" sources to r320884 (without
> > attempting to revert r320844), while running head @r320827.
> >
> > On reboot, I (again) had a panic on the laptop that looked similar
> > to the one from yesterday (r320869).
> >
> > On the build machine, however, I encountered the "mountroot" issue that
> > O. Hartmann had described.
> ...
> > Is there anything else I might be able to do to help resolve this?
> >
> 
> Try building a kernel without sdhci in it.
> 
> It's looking like the scans for ata devices are returning errors on the
> desktop machine you have, which shouldn't have been happening.
> 
> Also, can you try a 100% clean build of GENERIC to make sure there's not a
> meta-mode bug?
> 
> Warner

In thinking about the order of operations, it occurred to me that
trying the last option first would make sense, so I did that (cleared
/usr/obj/usr/src/sys/GENERIC, then re-built and -installed the
kernel).

And the build machine came up in multi-user mode:

FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #404  
r320884M/320891:1200038: Tue Jul 11 09:12:03 PDT 2017 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC  amd64

I'll call that "success" and stop while I'm ahead. :-)

Thanks!

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
POTUS impeachment requires Congress buy-in.  First, fix Congress, THEN impeach.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: beadm activate, cp: /tmp/BE-.../boot/zfs/zpool.cache: No such file or directory

[Allan Jude]

On 2017-07-11 10:18, Graham Perrin wrote:
> UEFI, booted from GELI-encrypted ZFS.
> 
> Whenever I attempt to activate a boot environment, activation fails.
> Instead, the environment is mounted.
> 
> I tried both beadm and (below) beadm-devel.
> 
> Thoughts? Is this, maybe, a known issue when booting r320599 from
> encrypted ZFS?
> 
> Also: at boot time, the list of boot environments is empty. I might
> workaround,
> 
> lszfs poolname/ROOT
> set vfs.root.mountfrom=zfs:poolname/ROOT/bename
> 
> Thanks
> 
> 
> 
> # date ; uptime ; uname -a
> Tue Jul 11 09:15:42 BST 2017
>  9:15AM  up 9 mins, 3 users, load averages: 0.26, 0.33, 0.19
> FreeBSD momh167-gjp4-hpelitebook8570p-freebsd 12.0-CURRENT FreeBSD
> 12.0-CURRENT #0 r320599: Mon Jul  3 15:34:15 UTC 2017
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> # pkg info beadm
> beadm-1.2.7_2
> Name   : beadm
> Version: 1.2.7_2
> Installed on   : Mon Jul 10 21:44:13 2017 BST
> Origin : sysutils/beadm
> Architecture   : FreeBSD:12:amd64
> Prefix : /usr/local
> Categories : sysutils
> Licenses   : BSD2CLAUSE
> Maintainer : bdrew...@freebsd.org
> WWW: https://github.com/vermaden/beadm/
> Comment: Solaris-like utility to manage Boot Environments on ZFS
> Annotations:
> repo_type  : binary
> repository : FreeBSD
> Flat size  : 30.6KiB
> Description:
> beadm is an Illumos/Solaris-like utility for FreeBSD to manage
> Boot Environments on ZFS filesystems.
> 
> WWW: https://github.com/vermaden/beadm/
> # pkg install beadm-devel
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up to date.
> Updating area51 repository catalogue...
> area51 repository is up to date.
> Updating poudriere repository catalogue...
> poudriere repository is up to date.
> Updating trueos-base repository catalogue...
> trueos-base repository is up to date.
> All repositories are up to date.
> Checking integrity... done (2 conflicting)
>   - beadm-devel-1.2.99.20150924 [poudriere] conflicts with beadm-1.2.7_2
> [installed] on /usr/local/sbin/beadm
>   - beadm-devel-1.2.99.20150924 [FreeBSD] conflicts with beadm-1.2.7_2
> [installed] on /usr/local/sbin/beadm
> Checking integrity... done (0 conflicting)
> The following 2 package(s) will be affected (of 0 checked):
> 
> Installed packages to be REMOVED:
> beadm-1.2.7_2
> 
> New packages to be INSTALLED:
> beadm-devel: 1.2.99.20150924 [poudriere]
> 
> Number of packages to be removed: 1
> Number of packages to be installed: 1
> 
> Proceed with this action? [y/N]: y
> [1/2] Deinstalling beadm-1.2.7_2...
> [1/2] Deleting files for beadm-1.2.7_2: 100%
> [2/2] Installing beadm-devel-1.2.99.20150924...
> [2/2] Extracting beadm-devel-1.2.99.20150924: 100%
> # beadm create 2017-07-11-09
> Created successfully
> # beadm activate 2017-07-11-09
> cp: /tmp/BE-2017-07-11-09.H0k1WFYJ/boot/zfs/zpool.cache: No such file or
> directory
> # beadm list
> BEActive Mountpoint  Space Created
> default   NR /8.3G 2017-07-07 10:50
> 2017-07-11-09 -  /tmp/BE-2017-07-11-09.H0k1WFYJ   8.0K 2017-07-11 09:16
> # gpart show
> =>   40  976773088  ada0  GPT  (466G)
>  40 409600 1  efi  (200M)
>  409640   2008- free -  (1.0M)
>  4116484194304 2  freebsd-zfs  (2.0G)
> 4605952   33554432 3  freebsd-swap  (16G)
>38160384  938612736 4  freebsd-zfs  (448G)
>   976773120  8- free -  (4.0K)
> 
> # mount
> hpelitebook8570p/ROOT/default on / (zfs, local, noatime, nfsv4acls)
> devfs on /dev (devfs, local, multilabel)
> procfs on /proc (procfs, local)
> bootpool on /bootpool (zfs, local, nfsv4acls)
> hpelitebook8570p on /hpelitebook8570p (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere on /hpelitebook8570p/poudriere (zfs, local,
> noatime, nfsv4acls)
> hpelitebook8570p/poudriere/jails on /hpelitebook8570p/poudriere/jails
> (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/ports on /hpelitebook8570p/poudriere/ports
> (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
> hpelitebook8570p/usr/home on /usr/home (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/usr/home/grahamperrin on /usr/home/grahamperrin (zfs,
> local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/data on /usr/local/poudriere/data (zfs,
> local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/data/.m on /usr/local/poudriere/data/.m (zfs,
> local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/data/cache on /usr/local/poudriere/data/cache
> (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/data/logs on /usr/local/poudriere/data/logs
> (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/data/packages on
> /usr/local/poudriere/data/packages (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/data/wrkdirs on
> /u

beadm activate, cp: /tmp/BE-.../boot/zfs/zpool.cache: No such file or directory

[Graham Perrin]

UEFI, booted from GELI-encrypted ZFS.

Whenever I attempt to activate a boot environment, activation fails. Instead, 
the environment is mounted.

I tried both beadm and (below) beadm-devel.

Thoughts? Is this, maybe, a known issue when booting r320599 from encrypted ZFS?

Also: at boot time, the list of boot environments is empty. I might workaround,

lszfs poolname/ROOT
set vfs.root.mountfrom=zfs:poolname/ROOT/bename

Thanks



# date ; uptime ; uname -a
Tue Jul 11 09:15:42 BST 2017
 9:15AM  up 9 mins, 3 users, load averages: 0.26, 0.33, 0.19
FreeBSD momh167-gjp4-hpelitebook8570p-freebsd 12.0-CURRENT FreeBSD 12.0-CURRENT 
#0 r320599: Mon Jul  3 15:34:15 UTC 2017 
r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
# pkg info beadm
beadm-1.2.7_2
Name   : beadm
Version: 1.2.7_2
Installed on   : Mon Jul 10 21:44:13 2017 BST
Origin : sysutils/beadm
Architecture   : FreeBSD:12:amd64
Prefix : /usr/local
Categories : sysutils
Licenses   : BSD2CLAUSE
Maintainer : bdrew...@freebsd.org
WWW: https://github.com/vermaden/beadm/
Comment: Solaris-like utility to manage Boot Environments on ZFS
Annotations:
repo_type  : binary
repository : FreeBSD
Flat size  : 30.6KiB
Description:
beadm is an Illumos/Solaris-like utility for FreeBSD to manage
Boot Environments on ZFS filesystems.

WWW: https://github.com/vermaden/beadm/
# pkg install beadm-devel
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating area51 repository catalogue...
area51 repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
Updating trueos-base repository catalogue...
trueos-base repository is up to date.
All repositories are up to date.
Checking integrity... done (2 conflicting)
  - beadm-devel-1.2.99.20150924 [poudriere] conflicts with beadm-1.2.7_2 
[installed] on /usr/local/sbin/beadm
  - beadm-devel-1.2.99.20150924 [FreeBSD] conflicts with beadm-1.2.7_2 
[installed] on /usr/local/sbin/beadm
Checking integrity... done (0 conflicting)
The following 2 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
beadm-1.2.7_2

New packages to be INSTALLED:
beadm-devel: 1.2.99.20150924 [poudriere]

Number of packages to be removed: 1
Number of packages to be installed: 1

Proceed with this action? [y/N]: y
[1/2] Deinstalling beadm-1.2.7_2...
[1/2] Deleting files for beadm-1.2.7_2: 100%
[2/2] Installing beadm-devel-1.2.99.20150924...
[2/2] Extracting beadm-devel-1.2.99.20150924: 100%
# beadm create 2017-07-11-09
Created successfully
# beadm activate 2017-07-11-09
cp: /tmp/BE-2017-07-11-09.H0k1WFYJ/boot/zfs/zpool.cache: No such file or 
directory
# beadm list
BEActive Mountpoint  Space Created
default   NR /8.3G 2017-07-07 10:50
2017-07-11-09 -  /tmp/BE-2017-07-11-09.H0k1WFYJ   8.0K 2017-07-11 09:16
# gpart show
=>   40  976773088  ada0  GPT  (466G)
 40 409600 1  efi  (200M)
 409640   2008- free -  (1.0M)
 4116484194304 2  freebsd-zfs  (2.0G)
4605952   33554432 3  freebsd-swap  (16G)
   38160384  938612736 4  freebsd-zfs  (448G)
  976773120  8- free -  (4.0K)

# mount
hpelitebook8570p/ROOT/default on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs, local, multilabel)
procfs on /proc (procfs, local)
bootpool on /bootpool (zfs, local, nfsv4acls)
hpelitebook8570p on /hpelitebook8570p (zfs, local, noatime, nfsv4acls)
hpelitebook8570p/poudriere on /hpelitebook8570p/poudriere (zfs, local, noatime, 
nfsv4acls)
hpelitebook8570p/poudriere/jails on /hpelitebook8570p/poudriere/jails (zfs, 
local, noatime, nfsv4acls)
hpelitebook8570p/poudriere/ports on /hpelitebook8570p/poudriere/ports (zfs, 
local, noatime, nfsv4acls)
hpelitebook8570p/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
hpelitebook8570p/usr/home on /usr/home (zfs, local, noatime, nfsv4acls)
hpelitebook8570p/usr/home/grahamperrin on /usr/home/grahamperrin (zfs, local, 
noatime, nfsv4acls)
hpelitebook8570p/poudriere/data on /usr/local/poudriere/data (zfs, local, 
noatime, nfsv4acls)
hpelitebook8570p/poudriere/data/.m on /usr/local/poudriere/data/.m (zfs, local, 
noatime, nfsv4acls)
hpelitebook8570p/poudriere/data/cache on /usr/local/poudriere/data/cache (zfs, 
local, noatime, nfsv4acls)
hpelitebook8570p/poudriere/data/logs on /usr/local/poudriere/data/logs (zfs, 
local, noatime, nfsv4acls)
hpelitebook8570p/poudriere/data/packages on /usr/local/poudriere/data/packages 
(zfs, local, noatime, nfsv4acls)
hpelitebook8570p/poudriere/data/wrkdirs on /usr/local/poudriere/data/wrkdirs 
(zfs, local, noatime, nfsv4acls)
hpelitebook8570p/poudriere/jails/current on /usr/local/poudriere/jails/current 
(zfs, local, noatime, nfsv4acls)
hpelitebook8570p/poudriere/ports/freebsd-ports-kde on 
/usr/local/poudriere/ports/freebsd-ports-kde

Re: Panic on boot after upgrade from r320827 -> r320869

[Warner Losh]

On Tue, Jul 11, 2017 at 6:13 AM, David Wolfskill 
wrote:

> On Mon, Jul 10, 2017 at 04:51:09AM -0700, David Wolfskill wrote:
> > Pnic occurred prior to mounting file systems
>
> While O. Hartmann had written to indicate the he had identified r320844
> as the culprit, and I had other reason to suspect it, I was a bit busy
> at work yesterday, and unable to determine this for myself empirically.
>
> I went ahead and updated my "head" sources to r320884 (without
> attempting to revert r320844), while running head @r320827.
>
> On reboot, I (again) had a panic on the laptop that looked similar
> to the one from yesterday (r320869).
>
> On the build machine, however, I encountered the "mountroot" issue that
> O. Hartmann had described.
>
> I have again created screenshots; they may be found in
> .  For the
> laptop, the last of them shows the backtrace; the one previous shows
> the panic message.  For the build machine ("freebeast"), the last
> shows that when I asked for a list of "valid disk boot devices,"
> what was presented was an empty list.  (I found a working keyboard for
> it.)
>
> The most recent verbnose dmesg.boot from a successful boot of the
> laptop (running head) may still be found at
> .
> For the build machine, it is
> .
>
> I believe that each of the machines has an MMC slot, but I also believe
> that in each case, it is empty.
>
> Is there anything else I might be able to do to help resolve this?
>

Try building a kernel without sdhci in it.

It's looking like the scans for ata devices are returning errors on the
desktop machine you have, which shouldn't have been happening.

Also, can you try a 100% clean build of GENERIC to make sure there's not a
meta-mode bug?

Warner
___
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"

strip: elf_strptr failed: Invalid argument

[Gergely Czuczy]

Hello,

I'm trying to build packages on an rpi3, on a freshly build image (with 
crochet), and when it's trying to build pkg from ports, I'm getting the 
following error message:


libtool: link: cc -D_BSD_SOURCE -I../libpkg -I../libpkg -I../compat 
-I../external/libucl/klib -I../external/uthash -I../external/expat/lib 
-DGITHASH=\"\" -O2 -pipe -Wno-error -fno-strict-aliasing -Wall 
-Wno-unused-function -D_BSD_SOURCE -DINET6=1 -Wl,--enable-new-dtags -o 
.libs/pkg pkg-add.o pkg-alias.o pkg-annotate.o pkg-audit.o 
pkg-autoremove.o pkg-backup.o pkg-check.o pkg-clean.o pkg-config.o 
pkg-convert.o pkg-create.o pkg-delete.o pkg-event.o pkg-fetch.o 
pkg-globals.o pkg-info.o pkg-install.o pkg-lock.o pkg-main.o 
pkg-plugins.o pkg-query.o pkg-register.o pkg-repo.o pkg-rquery.o 
pkg-search.o pkg-set.o pkg-shell.o pkg-shlib.o pkg-ssh.o pkg-stats.o 
pkg-update.o pkg-updating.o pkg-upgrade.o pkg-utils.o pkg-version.o 
pkg-which.o  ../libpkg/.libs/libpkg.so ../compat/.libs/libbsd_compat.a 
-lutil -lssl -lcrypto -lm -lelf -ljail -larchive -lz -lbz2 -llzma 
-Wl,-rpath -Wl,/usr/local/lib

 /bin/mkdir -p '/usr/ports/ports-mgmt/pkg/work/stage/usr/local/etc'
 install  -m 0644 pkg.conf.sample 
'/usr/ports/ports-mgmt/pkg/work/stage/usr/local/etc'

 /bin/mkdir -p '/usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin'
 STRIPPROG='strip' /bin/sh ../libtool   --mode=install /bin/sh 
/usr/ports/ports-mgmt/pkg/work/pkg-1.10.1/install-sh -c -s pkg-static 
pkg '/usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin'
libtool: install: /bin/sh 
/usr/ports/ports-mgmt/pkg/work/pkg-1.10.1/install-sh -c -s pkg-static 
/usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin/pkg-static

strip: elf_strptr failed: Invalid argument
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/ports-mgmt/pkg/work/pkg-1.10.1/src
*** Error code 1

Strange part, it says it's stripped already:

root@build:/usr/ports/ports-mgmt/pkg # file -s 
./work/pkg-1.10.1/src/pkg-static
./work/pkg-1.10.1/src/pkg-static: ELF 64-bit LSB executable, ARM 
aarch64, version 1 (FreeBSD), statically linked, stripped


However, trying to strip(1) manually reproduces the error:

# strip ~/pkg-static.1
strip: elf_strptr failed: Invalid argument

ktrace didn't reveal anything about the failing elf_strptr(3) call.

The system is:

FreeBSD build.aegir 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320657: Tue 
Jul  4 22:28:33 CEST 2017 
ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.aarch64/tank/rpi3/src/sys/AEGIR 
arm64


Could someone please help me with this? I don't really know how to solve 
this, or where to start looking. Usually building pkg works out of box.


Best regards,
Gergely



___
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: Panic on boot after upgrade from r320827 -> r320869

[David Wolfskill]

On Mon, Jul 10, 2017 at 04:51:09AM -0700, David Wolfskill wrote:
> Pnic occurred prior to mounting file systems

While O. Hartmann had written to indicate the he had identified r320844
as the culprit, and I had other reason to suspect it, I was a bit busy
at work yesterday, and unable to determine this for myself empirically.

I went ahead and updated my "head" sources to r320884 (without
attempting to revert r320844), while running head @r320827.

On reboot, I (again) had a panic on the laptop that looked similar
to the one from yesterday (r320869).

On the build machine, however, I encountered the "mountroot" issue that
O. Hartmann had described.

I have again created screenshots; they may be found in
.  For the
laptop, the last of them shows the backtrace; the one previous shows
the panic message.  For the build machine ("freebeast"), the last
shows that when I asked for a list of "valid disk boot devices,"
what was presented was an empty list.  (I found a working keyboard for
it.)

The most recent verbnose dmesg.boot from a successful boot of the
laptop (running head) may still be found at
.
For the build machine, it is
.

I believe that each of the machines has an MMC slot, but I also believe
that in each case, it is empty.

Is there anything else I might be able to do to help resolve this?

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
POTUS impeachment requires Congress buy-in.  First, fix Congress, THEN impeach.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: small patch for /etc/rc.d/nfsd, bugfix or POLA violation?

[Rick Macklem]

Cy Schubert wrote:
>Rick Macklem wrote:
>> Hi,
>>
>> The attached one line patch to /etc/rc.d/nfsd modifies the script so that i=
>> t
>> does not force the nfsuserd to be run when nfsv4_server_enable is set.
>> (nfsuserd can still be enabled via nfsuserd_enable=3D"YES" is /etc/rc.conf.=
>> )
>>
>> Here's why I think this patch might be appropriate...
>> (a) - The original RFC for NFSv4 (RFC3530) essentially required Owners and
>>Owner_groups to be specified as @ and this required
>>the nfsuserd daemon to be running.
>> (b) - RFC7530, which replace RFC3530, allows a Owner/Owner_group string to =
>> be
>>   the uid/gid number in a string when using AUTH_SYS. This simplifies confi=
>> guration
>>   for an all AUTH_SYS/POSIX environment (most NFS uses, I suspect?).
>>
>> To make the server do (b), two things need to be done:
>> 1 - set vfs.nfsd.enable_stringtouid=3D1
>> 2 - set vfs.nfsd.enable_uidtostring=3D1 (for head, I don't know if it will =
>> be MFC'd?)
>> OR
>>   - never run nfsuserd after booting (killing it off after it has been runn=
>> ing is not
>> sufficient)
>>  =20
>> Given the above, it would seem that /etc/rc.d/nfsd should not force running=
>>  of
>> the nfsuserd daemon, due to changes in the protocol.
>>
>> However, this will result in a POLA violation, in that after the patch, nfs=
>> userd won't
>> start when booting, unless nfsuserd_enable=3D"YES" is added to /etc/rc.conf=
>> .
>>
>> So, what do people think about this patch? rick=
>
>How about a warning message + an UPDATING entry + no MFC? And, relnotes =
>yes to say we now support RFC7530 in 12.0?
Sounds fine to me. I'll wait to see if there are more comments.

Thanks, rick


___
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"