Does building linux packages under poudriere require linux compatibility emulation?

[Mark Martinec]

When building packages under poudriere on 11.0-RELEASE-p7 (from a 
command
line in a terminal window) I'm noticing occasional streams of 
diagnostic:


  ELF binary type "3" not known.

which seem to be related to building some linux packages (example below,
parallel builds). Poudriere still reports success for these builds.

The host where poudriere is running does not have linux.ko loaded.

Does building such packages really require linuxilator configured
on the build host ???

   Mark


[00:23:56] >> [02][00:00:00] Starting build of 
www/linux-c6-qt47-webkit
[00:23:57] >> [13][00:00:00] Starting build of 
textproc/linux-c6-libxml2

ELF binary type "3" not known.
ELF binary type "3" not known.
[00:24:09] >> [19][00:00:28] Finished build of 
textproc/linux-c6-aspell: Success

[00:24:11] >> [19][00:00:00] Starting build of devel/qt4-makeqpf
[00:24:11] >> [11][00:00:24] Finished build of 
security/linux-c6-openssl-compat: Success

ELF binary type "3" not known.
ELF binary type "3" not known.
ELF binary type "3" not known.
ELF binary type "3" not known.
ELF binary type "3" not known.
[00:24:12] >> [11][00:00:00] Starting build of x11-toolkits/vte
ELF binary type "3" not known.
ELF binary type "3" not known.
ELF binary type "3" not known.
ELF binary type "3" not known.
[00:24:16] >> [07][00:00:24] Finished build of 
graphics/linux-c6-glx-utils: Success

ELF binary type "3" not known.
ELF binary type "3" not known.
ELF binary type "3" not known.
[00:24:17] >> [07][00:00:00] Starting build of devel/qt4-qdoc3
ELF binary type "3" not known.
ELF binary type "3" not known.
[00:24:19] >> [13][00:00:22] Finished build of 
textproc/linux-c6-libxml2: Success

[00:24:19] >> [13][00:00:00] Starting build of graphics/goocanvas
[00:24:27] >> [10][00:02:26] Finished build of graphics/sdl_gfx: 
Success

[00:24:29] >> [10][00:00:00] Starting build of multimedia/mjpegtools
[00:24:34] >> [04][00:02:15] Finished build of 
devel/linux-c6-devtools: Success
[00:24:35] >> [04][00:00:00] Starting build of 
devel/linux-c6-ncurses-base

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

Re: NFS and amd on older FreeBSD

[Rick Macklem]

Do you have exactly the same export options specified in /etc/exports
for the 9.3 server as the 6.3 one?
Beyond that, I can only suggest capturing packets when the automount fails
and looking at them in wireshark to see what is actually happening.

rick


From: owner-freebsd-sta...@freebsd.org  on 
behalf of Daniel Braniss 
Sent: Friday, January 13, 2017 3:06:56 AM
To: Karl Young
Cc: FreeBSD Stable Mailing List
Subject: Re: NFS and amd on older FreeBSD

> On 12 Jan 2017, at 21:01, Karl Young  wrote:
>
> Daniel Braniss(da...@cs.huji.ac.il)@2017.01.12 10:25:03 +0200:
>>
>>> On 12 Jan 2017, at 9:49 AM, Daniel Braniss  wrote:
>>>
>>>
 On 12 Jan 2017, at 1:47 AM, Karl Young  wrote:

 I inherited a lab that has a few hundred hosts running FreeBSD 7.2.
 These hosts run test scripts that access files that are stored on
 FreeBSD 6.3 host.  The 6.3 host exports a /data directory with NFS


 On the 7.2 hosts, I can see the exported directory:

 $ showmount -e 6.3-host
 Exports list on 6.3-host
 /data  Everyone

 And access it with amd

 $ ls -l /net/6-3.host/data

 drwxr-xr-x 5 root  wheel  512 Jun  4  2009 git
 drwxr-xr-x  4586 root  wheel83968 Nov  2 04:50 home

 I'm trying to retire the 6.3 host and replace it with 9.3 (I know it's
 old, but it's the best I can do for now).

 I export the /data directory on the 9.3 system, and I can see it on my
 7.2 hosts.

 $ showmount -e  9.3-host
 Exports list on 9.3-host:
 /data   Everyone

 But I can't automount it:

 $ ls -l /net/9.3-host/data
 ls: /net/9.3-host/data: No such file or directory

 If I manually mount the exported directory, it works:

 $ sudo mount -t nfs 9.3-host:/data /mnt/data/
 $ mount | grep nfs
 9.3-host:/data on /mnt/data (nfs)

 $ ls -l /mnt/data
 total 4
 drwxr-xr-x  9 root  wheel  512 Dec 20 17:41 iaf2

 I've spent some time on Google, but haven't found a solution.  I realize
 these are very old versions, but I'm not in a position to upgrade them
 right now.  My last resort will be to use /etc/fstab to do the NFS
 mount, but I'd rather avoid that if I can.

 Thanks for any pointers on how to resolve this.

 -karl


>>>
>>> if you changed the export file on the server after you tried to mount in on 
>>> the client,
>>> and will not realise this, if that’s the case, usually rebooting the client 
>>> helps.
>>>
>> s/and/amd/ ^%$# hate spell checkers
>>
>
> Thanks Danny
>
> I did try rebooting the client (and server) multiple times to no avail.


what does amq say?
you can, from another host do: amq -h client-host

btw, I thing that nfs_server must also run on the client …
I have nfs_server_enable=YES

danny

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

Re: Can't boot on ZFS -- /boot/zfsloader not found

[Jeremie Le Hen]

On Thu, Jan 12, 2017 at 10:55 PM, Steven Hartland
 wrote:
> On 12/01/2017 21:12, Jeremie Le Hen wrote:
>
> Hey Steven,
>
> (Please cc: me on reply)
>
> On Thu, Jan 12, 2017 at 1:32 AM, Steven Hartlan
>
> The reason I'd recommend 512k for boot is to provide room for expansion
> moving forward, as repartitioning to upgrade is a scary / hard thing to do.
> Remember it wasn't long ago when it was well under 64k and that's what was
> recommend, its not like with disk sizes these days you'll miss the extra
> 384k ;-)
>
> Yeah, that's wise you're right.
>
> Boot to a live cd, I'd recommend mfsbsd, and make sure the boot loader was
> written to ALL boot disks correctly e.g.
> if you have a mirrored pool with ada0 and ada1:
> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
>
> If this doesn't help the output from gpart show, uname -a and zpool status
> would also be helpful.
>
> This is all assuming standard BIOS mode and not UEFI which is done
> differently.
>
> I just use the installation media on an USB key and then drop to the
> shell.  This is a full FreeBSD running, so that's fine.
>
> % # gpart show ada0
> % =>   40  312581728  ada0  GPT  (149G)
> % 40   1024 1  freebsd-boot  (512K)
> %   10648387840 2  freebsd-swap  (4.0G)
> %8388904  304192864 3  freebsd-zfs  (145G)
> %
> % # uname -a
> % FreeBSD  11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep
> 29 01:43:23 UTC 2016 % %
> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> %
> % # zpool status
> %  pool: zroot
> % state: ONLINE
> %  scan: none requested
> % config:
> %
> %NAME  STATE READ
> WRITE CKSUM
> %zroot ONLINE   0
>0 0
> %  gptid/1c387d3b-d892-11e6-944b-f44d30620eeb  ONLINE   0
>0 0
> %
> % errors: No known data errors
>
> Here are the steps to write the bootloader:
>
> % # gpart bootcode -b /boot/pmbr -p  /boot/gptzfsboot -i 1 ada0
> % partcode written to ada0p1
> % bootcode written to ada0
> % # zpool get bootfs zroot
> % NAME   PROPERTY  VALUE   SOURCE
> % zroot  bootfszroot   local
>
> Two things spring to mind
>
> Idea 1:
> Is your root fs actually your direct pool or is it actually /root off your
> pool.
> If so you want to run:
> zpool set bootfs=zroot/root zroot

That was it. My boot volume is "zroot/root" and I was just following
brainlessly the doc which said to use "zroot". This didn't shock me
because this at least points to the right pool

>
> Idea 2:
> You mentioned in your original post and you used zfs send / recv to restore
> the pool, so I wonder if your cache file is out of date.
>
> Try the following:
> zpool export zroot
> zpool import -R /mnt -o cachefile=/boot/zfs/zpool.cache zroot
> cp /boot/zfs/zpool.cache /mnt/boot/zfs/zpool.cache
> zpool set bootfs=zroot/root zroot

I think that was wrong too, but this would probably have caused
problems later in the boot I think.

Anyway, thanks a lot for your help.  I'll give a quick lifting to the wiki page.

-jlh

>
> Regards
> Steve



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

Re: stable/11 debugging kernel unable to produce crashdump

[Mark Johnston]

On Sat, Jan 14, 2017 at 02:21:23AM +0700, Eugene Grosbein wrote:
> Hi!
> 
> I'm struggling to debug a panic in 11.0-STABLE/i386 that successfully 
> produces crashdump
> but I want more information. So I've rebuilt my custom kernel to include
> options INVARIANTS, WITNESS and DEADLKRES. Now any panic results in quick 
> unclean reboot
> without crashdump generation. Serial console shows:
> 
> Script started on Sat Jan 14 02:03:16 2017
> Command: cu -l cuau0 -s 115200
> Connected
> 
> root@gw:~ # sysctl debug.kdb.panic=1
> debug.kdb.panic:panic: kdb_sysctl_panic
> KDB: stack backtrace:
> db_trace_self_wrapper(e8bc2ae8,0,e8bc2ae8,e8bc2a48,c06b4af4,...) at 
> 0xc04c457b = db_trace_self_wrapper+0x2b/frame 0xe8bc2a20
> vpanic(c0a4916e,e8bc2a54,e8bc2a54,e8bc2a5c,c06e881f,...) at 0xc06b4a7f = 
> vpanic+0x6f/frame 0xe8bc2a34
> panic(c0a4916e,1,c0ae7e48,e8bc2a88,c06bfdd3,...) at 0xc06b4af4 = 
> panic+0x14/frame 0xe8bc2a48
> kdb_sysctl_panic(c0ae7e48,0,0,0,e8bc2ae8) at 0xc06e881f = 
> kdb_sysctl_panic+0x4f/frame 0xe8bc2a5c
> sysctl_root_handler_locked(0,0,e8bc2ae8,e8bc2aa8) at 0xc06bfdd3 = 
> sysctl_root_handler_locked+0x83/frame 0xe8bc2a88
> sysctl_root(0,e8bc2ae8) at 0xc06bf744 = sysctl_root+0x144/frame 0xe8bc2ad8
> userland_sysctl(c759f9c0,e8bc2b60,3,0,0,0,bfbfdc5c,4,e8bc2bc0,0) at 
> 0xc06bfb9d = userland_sysctl+0x12d/frame 0xe8bc2b30
> sys___sysctl(c759f9c0,e8bc2c00) at 0xc06bfa32 = sys___sysctl+0x52/frame 
> 0xe8bc2bd0
> syscall(e8bc2ce8) at 0xc0980801 = syscall+0x2a1/frame 0xe8bc2cdc
> Xint0x80_syscall() at 0xc096e45e = Xint0x80_syscall+0x2e/frame 0xe8bc2cdc
> --- syscall (202, FreeBSD ELF32, sys___sysctl), eip = 0x2818541b, esp = 
> 0xbfbfdbc8, ebp = 0xbfbfdbf0 ---
> Uptime: 4m36s
> panic: malloc: called with spinlock or critical section held
> Uptime: 4m36s
> panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
> /home/src/sys/cam/ata/ata_da.c:3382

I suspect that this is because we only stop the scheduler upon a panic
if SMP is configured. Can you retest with the patch below applied?

Index: sys/kern/kern_shutdown.c
===
--- sys/kern/kern_shutdown.c(revision 312082)
+++ sys/kern/kern_shutdown.c(working copy)
@@ -713,6 +713,7 @@
CPU_CLR(PCPU_GET(cpuid), _cpus);
stop_cpus_hard(other_cpus);
}
+#endif
 
/*
 * Ensure that the scheduler is stopped while panicking, even if panic
@@ -719,7 +720,6 @@
 * has been entered from kdb.
 */
td->td_stopsched = 1;
-#endif
 
bootopt = RB_AUTOBOOT;
newpanic = 0;
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

stable/11 debugging kernel unable to produce crashdump

[Eugene Grosbein]

Hi!

I'm struggling to debug a panic in 11.0-STABLE/i386 that successfully produces 
crashdump
but I want more information. So I've rebuilt my custom kernel to include
options INVARIANTS, WITNESS and DEADLKRES. Now any panic results in quick 
unclean reboot
without crashdump generation. Serial console shows:

Script started on Sat Jan 14 02:03:16 2017
Command: cu -l cuau0 -s 115200
Connected

root@gw:~ # sysctl debug.kdb.panic=1
debug.kdb.panic:panic: kdb_sysctl_panic
KDB: stack backtrace:
db_trace_self_wrapper(e8bc2ae8,0,e8bc2ae8,e8bc2a48,c06b4af4,...) at 0xc04c457b 
= db_trace_self_wrapper+0x2b/frame 0xe8bc2a20
vpanic(c0a4916e,e8bc2a54,e8bc2a54,e8bc2a5c,c06e881f,...) at 0xc06b4a7f = 
vpanic+0x6f/frame 0xe8bc2a34
panic(c0a4916e,1,c0ae7e48,e8bc2a88,c06bfdd3,...) at 0xc06b4af4 = 
panic+0x14/frame 0xe8bc2a48
kdb_sysctl_panic(c0ae7e48,0,0,0,e8bc2ae8) at 0xc06e881f = 
kdb_sysctl_panic+0x4f/frame 0xe8bc2a5c
sysctl_root_handler_locked(0,0,e8bc2ae8,e8bc2aa8) at 0xc06bfdd3 = 
sysctl_root_handler_locked+0x83/frame 0xe8bc2a88
sysctl_root(0,e8bc2ae8) at 0xc06bf744 = sysctl_root+0x144/frame 0xe8bc2ad8
userland_sysctl(c759f9c0,e8bc2b60,3,0,0,0,bfbfdc5c,4,e8bc2bc0,0) at 0xc06bfb9d 
= userland_sysctl+0x12d/frame 0xe8bc2b30
sys___sysctl(c759f9c0,e8bc2c00) at 0xc06bfa32 = sys___sysctl+0x52/frame 
0xe8bc2bd0
syscall(e8bc2ce8) at 0xc0980801 = syscall+0x2a1/frame 0xe8bc2cdc
Xint0x80_syscall() at 0xc096e45e = Xint0x80_syscall+0x2e/frame 0xe8bc2cdc
--- syscall (202, FreeBSD ELF32, sys___sysctl), eip = 0x2818541b, esp = 
0xbfbfdbc8, ebp = 0xbfbfdbf0 ---
Uptime: 4m36s
panic: malloc: called with spinlock or critical section held
Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ 
/home/src/sys/cam/ata/ata_da.c:3382

Uptime: 4m36s
panic: /boot/config: -D

FreeBSD/x86 boot
Default: 0:ad(0,a)/boot/loader
boot:

Also, I get a Lock Order Reversal at boot time:

lock order reversal:
 1st 0xc6c2aa30 ufs (ufs) @ /home/src/sys/kern/vfs_subr.c:2523
 2nd 0xd99a3b80 bufwait (bufwait) @ /home/src/sys/ufs/ffs/ffs_vnops.c:277
 3rd 0xc6c53a30 ufs (ufs) @ /home/src/sys/kern/vfs_subr.c:2523
stack backtrace:
#0 0xc0700442 at witness_debugger+0x62
#1 0xc0700386 at witness_checkorder+0xb56
#2 0xc069757c at __lockmgr_args+0x5bc
#3 0xc0908db2 at ffs_lock+0x62
#4 0xc099f63f at VOP_LOCK1_APV+0xbf
#5 0xc0762b8e at _vn_lock+0x8e
#6 0xc0755477 at vget+0x57
#7 0xc0749783 at vfs_hash_get+0xb3
#8 0xc0904da7 at ffs_vgetf+0x27
#9 0xc08fc47d at softdep_sync_buf+0xa1d
#10 0xc09099b1 at ffs_syncvnode+0x281
#11 0xc090758c at ffs_sync+0x19c
#12 0xc074eb93 at dounmount+0x583
#13 

Re: pkg upgrade wants to install old postgresql-client-version. why?

[Paul Mather]

On Jan 13, 2017, at 10:19 AM, Holger Kipp  wrote:

> Dear Paul,
> 
>> Am 13.01.2017 um 15:49 schrieb Paul Mather > >:
>> 
>> On Jan 13, 2017, at 9:24 AM, Holger Kipp > > wrote:
>> 
>>> Dear all,
>>> 
>>> I have a little FreeBSD system upgraded from 10.2-p24 to 10.3-p11. GENERIC 
>>> Kernel.
>>> This also included upgrading postgresql from 9.5.4 to 9.5.5_1. and about 
>>> 220 other ports.
>>> Most were upgraded using pkg upgrade, but postgresql had to be upgraded 
>>> using the manual
>>> make, make package, make deinstall && make reinstall.
>>> 
>>> root@gw2:~ # pkg info | grep postgresql
>>> postgresql95-client-9.5.5_1PostgreSQL database (client)
>>> postgresql95-contrib-9.5.5 The contrib utilities from the PostgreSQL 
>>> distribution
>>> postgresql95-server-9.5.5_1PostgreSQL is the most advanced open-source 
>>> database available anywhere
>>> root@gw2:~ #
>>> 
>>> All Ports were originally installed from source but with default config.
>>> 
>>> 
>>> 
>>> Now pkg upgrade wants to install postgresql-client 9.3.15_1:
>>> 
>>> root@gw2:~ # pkg upgrade
>>> Updating FreeBSD repository catalogue...
>>> FreeBSD repository is up-to-date.
>>> All repositories are up-to-date.
>>> Checking for upgrades (28 candidates): 100%
>>> Processing candidates (28 candidates): 100%
>>> The following 3 package(s) will be affected (of 0 checked):
>>> 
>>> New packages to be INSTALLED:
>>>   postgresql93-client: 9.3.15_1
>>> 
>>> Installed packages to be REINSTALLED:
>>>   p5-Pg-2.1.1_4,1 (direct dependency changed: perl5)
>>>   p5-DBD-Pg-3.5.3 (direct dependency changed: p5-DBI)
>>> 
>>> Number of packages to be installed: 1
>>> Number of packages to be reinstalled: 2
>>> 
>>> The process will require 9 MiB more space.
>>> 2 MiB to be downloaded.
>>> 
>>> Proceed with this action? [y/N]:
>>> 
>>> 
>>> My programs using p5-Pg or p5-DBD-Pg seem to work just fine, and perl5 has 
>>> current version perl5-5.24.1.r4_1.
>>> However I had to reinstall both packages manually because they were not 
>>> properly working after upgrade via pkg upgrade.
>> 
>> 
>> You are using the official FreeBSD packages for your upgrade.  They are 
>> built with postgresql93 as the default version of PostgreSQL. Thus, p5-Pg 
>> and p5-DBD-Pg will both have a dependency on the postgresql-client packages 
>> (for libraries allowing them to interface with PostgreSQL servers), which, 
>> in the FreeBSD repository, is postgresql93-client.
>> 
>> Because postgresql93-client conflicts with postgresql95-client, it will try 
>> and uninstall the latter when trying to satisfy the postgresql93-client 
>> dependency.  The same will be true of any other package you try and use from 
>> the FreeBSD repository that has a dependency upon PostgreSQL.
>> 
>> 
>>> How can I check where from pkg upgrade gets the idea to install old 
>>> 9.3.15_1 postgresql client?
>>> And is there a way to rectify this?
>> 
>> 
>> I would imagine that, like you did with the PostgreSQL 9.5 ports, you would 
>> also have to build and reinstall p5-Pg and p5-DBD-Pg manually, too.  Be sure 
>> to add "DEFAULT_VERSIONS+= pgsql=9.5" or otherwise amend your 
>> DEFAULT_VERSIONS setting in /etc/make.conf before building so that p5-Pg and 
>> p5-DBD-Pg depend upon the version of PostgreSQL you want.
>> 
>> Mixing custom local ports and stock ports from the FreeBSD official packages 
>> repository will often lead to these sorts of problems, due to differences in 
>> build options and such.
>> 
>> Another way to rectify it is to build your own ports using something like 
>> Poudriere.
> 
> Thank you very much for the good explanation. I’ll go with the 
> DEFAULT_VERSIONS-Setting in make.conf then.
> Is there a list of dependencies for the FreeBSD repository so I can check if 
> my system is also affected there?


I'm not sure if this is what you're asking, but one thing you can do is query 
the FreeBSD packages repository for such information.  See "pkg help rquery" 
for details.  E.g., to see what packages (and versions) the p5-DBD-Pg package 
depends upon, use the following command:

pkg rquery %dn-%dv p5-DBD-Pg

Currently, this returns:

p5-DBI-1.636
perl5-5.24.1.r4_1
postgresql93-client-9.3.15_1

To see which packages potentially are affected by manually installing a 
different version of PostgreSQL (i.e., those packages that depend upon 
postgresql93-client), use the following command:

pkg rquery %ro postgresql93-client

This currently returns a list of 115 packages.

Note also that the standard FreeBSD package repository distributed with recent 
releases is based upon the "quarterly" ports tree.  Make sure you use the same 
source in your local /usr/ports, otherwise you have scope for even more 
divergence between your local ports being built and the ones you're using from 

Re: pkg upgrade problem with Perl 5.24

[Chris H]

On Fri, 13 Jan 2017 16:38:59 + Matthew Seaman  wrote

> On 2017/01/13 16:31, Chris H wrote:
> > As a general rule:
> > install from pkg(8) remove with pkg(8)
> > install from ports(7), remove with ports(7)
> > 
> 
> Sorry -- this is completely bogus.
Not entirely.

>  You can freely mix and match either
> way. Just make sure that the package names match up.
> 
> In fact the ports removes packages using pkg(8), so it all comes down to
> the same thing in the end.
That is the *intended* outcome, to be sure. *But* as noted in the OP[1],
and from some edge cases I've personally run into; the "general rule"
I listed, does apply. :)
> 
> Cheers,
> 
> Matthew

I have now removed the package using pkg delete -f -n perl5-5.24.1.r4_1 and was
then able to install from ports without problems:

[1] root@gw2:/usr/ports/lang/perl5.24 # pkg info perl5.24-5.24.1.r5_1
perl5.24-5.24.1.r5_1
Name   : perl5.24
Version: 5.24.1.r5_1
Installed on   : Thu Jan 12 17:53:45 2017 CET
Origin : lang/perl5.24

--Chris


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

Re: pkg upgrade problem with Perl 5.24

[Matthew Seaman]

On 2017/01/13 16:31, Chris H wrote:
> As a general rule:
> install from pkg(8) remove with pkg(8)
> install from ports(7), remove with ports(7)
> 

Sorry -- this is completely bogus.  You can freely mix and match either
way. Just make sure that the package names match up.

In fact the ports removes packages using pkg(8), so it all comes down to
the same thing in the end.

Cheers,

Matthew



signature.asc
Description: OpenPGP digital signature

Re: pkg upgrade problem with Perl 5.24

[Chris H]

On Fri, 13 Jan 2017 15:43:41 + Holger Kipp  wrote

> Dear all,
> 
> I upgraded Perl to 5.24(1.r4_1) (via pkg upgrade).
> When I now try to install the latest version from ports (1.r5_1), the system
> can’t install the new version because of the older version, but can’t
> deinstall(*) the older version (eg. via make deinstall && make reinstall).
> 
> 
> 
> root@gw2:/usr/ports/lang/perl5.24 # pkg info | grep perl
> p5-Data-Dumper-2.161   Stringified perl data structures, suitable for
> both printing and eval p5-Pg-2.1.1_4,1Interface for using
> perl5 to access PostgreSQL databases p5-Scalar-List-Utils-1.45,1Perl
> subroutines that would be nice to have in the perl core perl5-5.24.1.r4_1
>  Practical Extraction and Report Language 
>
> so currently via pkg upgrade I got perl5-5.24.1.r4_1, which perl itself
> confirms: root@gw2:/usr/ports/lang/perl5.24 # perl -v
> 
> This is perl 5, version 24, subversion 1 (v5.24.1) built for
> amd64-freebsd-thread-multi (with 1 registered patch, see perl -V for more
> detail) 
>
> This is then obviously the version from FreeBSD repository.
> 
> If I try to install the latest version from ports (perl5-5.24.1.r5_1), I get
> the following (make install just to get the messages): 
>
> 
> root@gw2:/usr/ports/lang/perl5.24 # make install
> ===>  Installing for perl5.24-5.24.1.r5_1
> ===>  Checking if perl5.24 already installed
> ===>   Registering installation for perl5.24-5.24.1.r5_1
> Installing perl5.24-5.24.1.r5_1...
> pkg-static: perl5.24-5.24.1.r5_1 conflicts with perl5-5.24.1.r4_1 (installs
> files into the same place).  Problematic file: /usr/local/bin/perl5.24.1
> *** Error code 70
> 
> Stop.
> make[1]: stopped in /usr/ports/lang/perl5.24
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/lang/perl5.24
> 
> 
> Deinstalling the existing version does not work:
> 
> root@gw2:/usr/ports/lang/perl5.24 # make deinstall
> ===>  Deinstalling for perl5.24
> ===>   perl5.24 not installed, skipping
> 
> But according to pkg info it is installed:
> 
> root@gw2:/usr/ports/lang/perl5.24 # pkg info perl5
> perl5-5.24.1.r4_1
> Name   : perl5
> Version: 5.24.1.r4_1
> Installed on   : Thu Jan 12 12:51:03 2017 CET
> Origin : lang/perl5.24
> 
> 
> This sees to be a bit strange.
> 
> (*) I have now removed the package using pkg delete -f -n perl5-5.24.1.r4_1
> and was then able to install from ports without problems: 
>
> root@gw2:/usr/ports/lang/perl5.24 # pkg info perl5.24-5.24.1.r5_1
> perl5.24-5.24.1.r5_1
> Name   : perl5.24
> Version: 5.24.1.r5_1
> Installed on   : Thu Jan 12 17:53:45 2017 CET
> Origin : lang/perl5.24
> 
> 
> Any ideas what happened here? I’m not sure if this is expected behaviour.
> 
> Many thanks and best regards,
> Holger
As a general rule:
install from pkg(8) remove with pkg(8)
install from ports(7), remove with ports(7)

That said; I didn't notice any evidence of which version of
FreeBSD, you're running (uname -a) --
It's important where Perl is concerned.

How about make.conf(5)? Anything interesting in there;
DEFAULT_VERSIONS+=
or
WITH_PKGNG=

HTH

--Chris


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

Re: pkg upgrade problem with Perl 5.24

[Matthew Seaman]

On 2017/01/13 15:43, Holger Kipp wrote:
> so currently via pkg upgrade I got perl5-5.24.1.r4_1, which perl itself 
> confirms:
 ^
> ===>  Installing for perl5.24-5.24.1.r5_1
   

Notice the difference in package names.  One is calling itself 'perl5'
and the other 'perl5.24' which means pkg(8) thinks they are completely
different packages.  This is why compiling from ports can't delete the
version you installed as a pkg.

The reason for the different names is because in one case, that port was
designated the default perl version when the package was built, and in
the other case it wasn't.  5.24 is currently the default version of perl
in the FreeBSD package build cluster, as of the beginning of this month
for the latest quarterly branch.

Check your /etc/make.conf or similar -- do you have a DEFAULT_VERSIONS
setting for perl?  You should use something like:

   DEFAULT_VERSIONS+= perl5=5.24

which will at least make the pkg cluster and your own-build packages
agree on the package name.

Cheers,

Matthew




signature.asc
Description: OpenPGP digital signature

pkg upgrade problem with Perl 5.24

[Holger Kipp]

Dear all,

I upgraded Perl to 5.24(1.r4_1) (via pkg upgrade).
When I now try to install the latest version from ports (1.r5_1), the system 
can’t install the new version because of the older version, but can’t 
deinstall(*) the older version (eg. via make deinstall && make reinstall).



root@gw2:/usr/ports/lang/perl5.24 # pkg info | grep perl
p5-Data-Dumper-2.161   Stringified perl data structures, suitable for 
both printing and eval
p5-Pg-2.1.1_4,1Interface for using perl5 to access PostgreSQL 
databases
p5-Scalar-List-Utils-1.45,1Perl subroutines that would be nice to have in 
the perl core
perl5-5.24.1.r4_1  Practical Extraction and Report Language

so currently via pkg upgrade I got perl5-5.24.1.r4_1, which perl itself 
confirms:
root@gw2:/usr/ports/lang/perl5.24 # perl -v

This is perl 5, version 24, subversion 1 (v5.24.1) built for 
amd64-freebsd-thread-multi
(with 1 registered patch, see perl -V for more detail)

This is then obviously the version from FreeBSD repository.

If I try to install the latest version from ports (perl5-5.24.1.r5_1), I get 
the following (make install just to get the messages):


root@gw2:/usr/ports/lang/perl5.24 # make install
===>  Installing for perl5.24-5.24.1.r5_1
===>  Checking if perl5.24 already installed
===>   Registering installation for perl5.24-5.24.1.r5_1
Installing perl5.24-5.24.1.r5_1...
pkg-static: perl5.24-5.24.1.r5_1 conflicts with perl5-5.24.1.r4_1 (installs 
files into the same place).  Problematic file: /usr/local/bin/perl5.24.1
*** Error code 70

Stop.
make[1]: stopped in /usr/ports/lang/perl5.24
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/perl5.24


Deinstalling the existing version does not work:

root@gw2:/usr/ports/lang/perl5.24 # make deinstall
===>  Deinstalling for perl5.24
===>   perl5.24 not installed, skipping

But according to pkg info it is installed:

root@gw2:/usr/ports/lang/perl5.24 # pkg info perl5
perl5-5.24.1.r4_1
Name   : perl5
Version: 5.24.1.r4_1
Installed on   : Thu Jan 12 12:51:03 2017 CET
Origin : lang/perl5.24


This sees to be a bit strange.

(*) I have now removed the package using pkg delete -f -n perl5-5.24.1.r4_1 and 
was then able to install from ports without problems:

root@gw2:/usr/ports/lang/perl5.24 # pkg info perl5.24-5.24.1.r5_1
perl5.24-5.24.1.r5_1
Name   : perl5.24
Version: 5.24.1.r5_1
Installed on   : Thu Jan 12 17:53:45 2017 CET
Origin : lang/perl5.24


Any ideas what happened here? I’m not sure if this is expected behaviour.

Many thanks and best regards,
Holger

__

Holger Kipp
Diplom-Mathematiker
Senior Consultant

Tel. : +49 30 436 58 114
Fax. : +49 30 436 58 214
Mobil: +49 178 36 58 114
Email: holger.k...@alogis.com

alogis AG
Alt-Moabit 90b
D-10559 Berlin

http://www.alogis.com
__

alogis AG
Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484
Vorstand: Arne Friedrichs, Joern Samuelson
Aufsichtsratsvorsitzender: Reinhard Mielke

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

Re: pkg upgrade wants to install old postgresql-client-version. why?

[Holger Kipp]

Dear Paul,

Am 13.01.2017 um 15:49 schrieb Paul Mather 
>:

On Jan 13, 2017, at 9:24 AM, Holger Kipp 
> wrote:

Dear all,

I have a little FreeBSD system upgraded from 10.2-p24 to 10.3-p11. GENERIC 
Kernel.
This also included upgrading postgresql from 9.5.4 to 9.5.5_1. and about 220 
other ports.
Most were upgraded using pkg upgrade, but postgresql had to be upgraded using 
the manual
make, make package, make deinstall && make reinstall.

root@gw2:~ # pkg info | grep postgresql
postgresql95-client-9.5.5_1PostgreSQL database (client)
postgresql95-contrib-9.5.5 The contrib utilities from the PostgreSQL 
distribution
postgresql95-server-9.5.5_1PostgreSQL is the most advanced open-source 
database available anywhere
root@gw2:~ #

All Ports were originally installed from source but with default config.



Now pkg upgrade wants to install postgresql-client 9.3.15_1:

root@gw2:~ # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (28 candidates): 100%
Processing candidates (28 candidates): 100%
The following 3 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
  postgresql93-client: 9.3.15_1

Installed packages to be REINSTALLED:
  p5-Pg-2.1.1_4,1 (direct dependency changed: perl5)
  p5-DBD-Pg-3.5.3 (direct dependency changed: p5-DBI)

Number of packages to be installed: 1
Number of packages to be reinstalled: 2

The process will require 9 MiB more space.
2 MiB to be downloaded.

Proceed with this action? [y/N]:


My programs using p5-Pg or p5-DBD-Pg seem to work just fine, and perl5 has 
current version perl5-5.24.1.r4_1.
However I had to reinstall both packages manually because they were not 
properly working after upgrade via pkg upgrade.


You are using the official FreeBSD packages for your upgrade.  They are built 
with postgresql93 as the default version of PostgreSQL. Thus, p5-Pg and 
p5-DBD-Pg will both have a dependency on the postgresql-client packages (for 
libraries allowing them to interface with PostgreSQL servers), which, in the 
FreeBSD repository, is postgresql93-client.

Because postgresql93-client conflicts with postgresql95-client, it will try and 
uninstall the latter when trying to satisfy the postgresql93-client dependency. 
 The same will be true of any other package you try and use from the FreeBSD 
repository that has a dependency upon PostgreSQL.


How can I check where from pkg upgrade gets the idea to install old 9.3.15_1 
postgresql client?
And is there a way to rectify this?


I would imagine that, like you did with the PostgreSQL 9.5 ports, you would 
also have to build and reinstall p5-Pg and p5-DBD-Pg manually, too.  Be sure to 
add "DEFAULT_VERSIONS+= pgsql=9.5" or otherwise amend your DEFAULT_VERSIONS 
setting in /etc/make.conf before building so that p5-Pg and p5-DBD-Pg depend 
upon the version of PostgreSQL you want.

Mixing custom local ports and stock ports from the FreeBSD official packages 
repository will often lead to these sorts of problems, due to differences in 
build options and such.

Another way to rectify it is to build your own ports using something like 
Poudriere.

Thank you very much for the good explanation. I’ll go with the 
DEFAULT_VERSIONS-Setting in make.conf then.
Is there a list of dependencies for the FreeBSD repository so I can check if my 
system is also affected there?

Many thanks and best regards,
Holger


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

Re: pkg upgrade wants to install old postgresql-client-version. why?

[Paul Mather]

On Jan 13, 2017, at 9:24 AM, Holger Kipp  wrote:

> Dear all,
> 
> I have a little FreeBSD system upgraded from 10.2-p24 to 10.3-p11. GENERIC 
> Kernel.
> This also included upgrading postgresql from 9.5.4 to 9.5.5_1. and about 220 
> other ports.
> Most were upgraded using pkg upgrade, but postgresql had to be upgraded using 
> the manual
> make, make package, make deinstall && make reinstall.
> 
> root@gw2:~ # pkg info | grep postgresql
> postgresql95-client-9.5.5_1PostgreSQL database (client)
> postgresql95-contrib-9.5.5 The contrib utilities from the PostgreSQL 
> distribution
> postgresql95-server-9.5.5_1PostgreSQL is the most advanced open-source 
> database available anywhere
> root@gw2:~ #
> 
> All Ports were originally installed from source but with default config.
> 
> 
> 
> Now pkg upgrade wants to install postgresql-client 9.3.15_1:
> 
> root@gw2:~ # pkg upgrade
> Updating FreeBSD repository catalogue...
> FreeBSD repository is up-to-date.
> All repositories are up-to-date.
> Checking for upgrades (28 candidates): 100%
> Processing candidates (28 candidates): 100%
> The following 3 package(s) will be affected (of 0 checked):
> 
> New packages to be INSTALLED:
>postgresql93-client: 9.3.15_1
> 
> Installed packages to be REINSTALLED:
>p5-Pg-2.1.1_4,1 (direct dependency changed: perl5)
>p5-DBD-Pg-3.5.3 (direct dependency changed: p5-DBI)
> 
> Number of packages to be installed: 1
> Number of packages to be reinstalled: 2
> 
> The process will require 9 MiB more space.
> 2 MiB to be downloaded.
> 
> Proceed with this action? [y/N]:
> 
> 
> My programs using p5-Pg or p5-DBD-Pg seem to work just fine, and perl5 has 
> current version perl5-5.24.1.r4_1.
> However I had to reinstall both packages manually because they were not 
> properly working after upgrade via pkg upgrade.


You are using the official FreeBSD packages for your upgrade.  They are built 
with postgresql93 as the default version of PostgreSQL.  Thus, p5-Pg and 
p5-DBD-Pg will both have a dependency on the postgresql-client packages (for 
libraries allowing them to interface with PostgreSQL servers), which, in the 
FreeBSD repository, is postgresql93-client.

Because postgresql93-client conflicts with postgresql95-client, it will try and 
uninstall the latter when trying to satisfy the postgresql93-client dependency. 
 The same will be true of any other package you try and use from the FreeBSD 
repository that has a dependency upon PostgreSQL.


> How can I check where from pkg upgrade gets the idea to install old 9.3.15_1 
> postgresql client?
> And is there a way to rectify this?


I would imagine that, like you did with the PostgreSQL 9.5 ports, you would 
also have to build and reinstall p5-Pg and p5-DBD-Pg manually, too.  Be sure to 
add "DEFAULT_VERSIONS+= pgsql=9.5" or otherwise amend your DEFAULT_VERSIONS 
setting in /etc/make.conf before building so that p5-Pg and p5-DBD-Pg depend 
upon the version of PostgreSQL you want.

Mixing custom local ports and stock ports from the FreeBSD official packages 
repository will often lead to these sorts of problems, due to differences in 
build options and such.

Another way to rectify it is to build your own ports using something like 
Poudriere.

Cheers,

Paul.

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

pkg upgrade wants to install old postgresql-client-version. why?

[Holger Kipp]

Dear all,

I have a little FreeBSD system upgraded from 10.2-p24 to 10.3-p11. GENERIC 
Kernel.
This also included upgrading postgresql from 9.5.4 to 9.5.5_1. and about 220 
other ports.
Most were upgraded using pkg upgrade, but postgresql had to be upgraded using 
the manual
make, make package, make deinstall && make reinstall.

root@gw2:~ # pkg info | grep postgresql
postgresql95-client-9.5.5_1PostgreSQL database (client)
postgresql95-contrib-9.5.5 The contrib utilities from the PostgreSQL 
distribution
postgresql95-server-9.5.5_1PostgreSQL is the most advanced open-source 
database available anywhere
root@gw2:~ #

All Ports were originally installed from source but with default config.



Now pkg upgrade wants to install postgresql-client 9.3.15_1:

root@gw2:~ # pkg upgrade
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
Checking for upgrades (28 candidates): 100%
Processing candidates (28 candidates): 100%
The following 3 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
postgresql93-client: 9.3.15_1

Installed packages to be REINSTALLED:
p5-Pg-2.1.1_4,1 (direct dependency changed: perl5)
p5-DBD-Pg-3.5.3 (direct dependency changed: p5-DBI)

Number of packages to be installed: 1
Number of packages to be reinstalled: 2

The process will require 9 MiB more space.
2 MiB to be downloaded.

Proceed with this action? [y/N]:


My programs using p5-Pg or p5-DBD-Pg seem to work just fine, and perl5 has 
current version perl5-5.24.1.r4_1.
However I had to reinstall both packages manually because they were not 
properly working after upgrade via pkg upgrade.

How can I check where from pkg upgrade gets the idea to install old 9.3.15_1 
postgresql client?
And is there a way to rectify this?

Many thanks and best regards,
Holger



__

Holger Kipp
Diplom-Mathematiker
Senior Consultant

Tel. : +49 30 436 58 114
Fax. : +49 30 436 58 214
Mobil: +49 178 36 58 114
Email: holger.k...@alogis.com

alogis AG
Alt-Moabit 90b
D-10559 Berlin

http://www.alogis.com
__

alogis AG
Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484
Vorstand: Arne Friedrichs, Joern Samuelson
Aufsichtsratsvorsitzender: Reinhard Mielke

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

Re: NFS and amd on older FreeBSD

[Daniel Braniss]

> On 12 Jan 2017, at 21:01, Karl Young  wrote:
> 
> Daniel Braniss(da...@cs.huji.ac.il)@2017.01.12 10:25:03 +0200:
>> 
>>> On 12 Jan 2017, at 9:49 AM, Daniel Braniss  wrote:
>>> 
>>> 
 On 12 Jan 2017, at 1:47 AM, Karl Young  wrote:
 
 I inherited a lab that has a few hundred hosts running FreeBSD 7.2.
 These hosts run test scripts that access files that are stored on
 FreeBSD 6.3 host.  The 6.3 host exports a /data directory with NFS
 
 
 On the 7.2 hosts, I can see the exported directory:
 
 $ showmount -e 6.3-host
 Exports list on 6.3-host
 /data  Everyone
 
 And access it with amd
 
 $ ls -l /net/6-3.host/data
 
 drwxr-xr-x 5 root  wheel  512 Jun  4  2009 git
 drwxr-xr-x  4586 root  wheel83968 Nov  2 04:50 home
 
 I'm trying to retire the 6.3 host and replace it with 9.3 (I know it's
 old, but it's the best I can do for now).
 
 I export the /data directory on the 9.3 system, and I can see it on my
 7.2 hosts.
 
 $ showmount -e  9.3-host
 Exports list on 9.3-host:
 /data   Everyone
 
 But I can't automount it:
 
 $ ls -l /net/9.3-host/data
 ls: /net/9.3-host/data: No such file or directory
 
 If I manually mount the exported directory, it works:
 
 $ sudo mount -t nfs 9.3-host:/data /mnt/data/
 $ mount | grep nfs
 9.3-host:/data on /mnt/data (nfs)
 
 $ ls -l /mnt/data
 total 4
 drwxr-xr-x  9 root  wheel  512 Dec 20 17:41 iaf2
 
 I've spent some time on Google, but haven't found a solution.  I realize
 these are very old versions, but I'm not in a position to upgrade them
 right now.  My last resort will be to use /etc/fstab to do the NFS
 mount, but I'd rather avoid that if I can.
 
 Thanks for any pointers on how to resolve this.
 
 -karl
 
 
>>> 
>>> if you changed the export file on the server after you tried to mount in on 
>>> the client,
>>> and will not realise this, if that’s the case, usually rebooting the client 
>>> helps.
>>> 
>> s/and/amd/ ^%$# hate spell checkers
>> 
> 
> Thanks Danny
> 
> I did try rebooting the client (and server) multiple times to no avail.


what does amq say?
you can, from another host do: amq -h client-host

btw, I thing that nfs_server must also run on the client …
I have nfs_server_enable=YES

danny

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