Mount command shows wrong information for nullfs mounts

Hi, I have the following nullfs mount: /data/downloads on /usr/jails/dlna/mnt/data (nullfs, local, read-only) For some reason, the mount command output shows this: zroot/virtuals/bhyve/fbsd3@change-volmode/data/downloads on /usr/jails/dlna/mnt/data (nullfs, local, read-only) This happened for

Re: Verification error in daily run on fresh 11.2-RELEASE install

Hi, On Sat, Sep 08, 2018 at 10:08:45AM +0200, Milan Obuch wrote: > Hi, > > I did fresh install of FreeBSD 11.2-RELEASE on new amd64 system, and > daily job run has following in mailed output: > > Checking for rejected mail hosts: > Certificate verification failed for

Re: zfs, mc, mcview and files opening

Hi, On Tue, Nov 10, 2015 at 02:58:32PM +0500, Eugene M. Zheganin wrote: > Hi. > > my midnight commander is terribly slow at vieweing files with mcview. > Opening of a file of approximately 10 megabytes takes about 30-40 > seconds. This isn't related with the compression setting, %busy wait or >

Freebsd-version problem

Hi, after today update to r284993, my /bin/freebsd-version is wrong. It contains both freebsd-version script and newvers.sh as if someone concatenated these two files into /bin/freebsd-version. Can anyone confirm or is it just me? BR, Marko pgpQQn3yVF4ld.pgp Description: PGP signature

Re: Vbox kernel module panic on boot

On Fri, Jun 12, 2015 at 03:54:23PM -0400, Lowell Gilbert wrote: You rebuilt the vbox module, yes? No, I didn't have to before. Thanks for the answer, I will rebuild the module and try again. BR, Marko pgprHpUkSg3CI.pgp Description: PGP signature

Vbox kernel module panic on boot

Hi, I'm running 10-STABLE and I have the following in my rc.conf: vboxdrv_load=YES vboxnet_enable=YES Today I upgraded to r284295 and I get a kernel panic on boot when the vbox module is loaded (panic: ncpus is 0 with non-zero map). Complete backtrace is at the end of the mail. Last time I

vt_core.c vt_is_cursor_in_area different behavior after r282823

Hi, after r282823, new vt_is_cursor_in_area is, in some cases, returning different values than the old function. For example: If (my + vd-vd_mcursor-height) is equal to (area-tr_begin.tp_row), old function will return 1 and new function will return 0. Is this intended behavior or is it a bug?