On 2021-May-23, at 01:27, Mark Millard wrote:
> On 2021-May-23, at 00:44, Mark Millard wrote:
>
>> On 2021-May-21, at 17:56, Rick Macklem wrote:
>>
>>> Mark Millard wrote:
>>> [stuff snipped]
Well, why is it that ls -R, find, and diff -r all get file
name problems via genet0 but
On 2021-May-23, at 00:44, Mark Millard wrote:
> On 2021-May-21, at 17:56, Rick Macklem wrote:
>
>> Mark Millard wrote:
>> [stuff snipped]
>>> Well, why is it that ls -R, find, and diff -r all get file
>>> name problems via genet0 but diff -r gets no problems
>>> comparing the content of files
On 2021-May-21, at 17:56, Rick Macklem wrote:
> Mark Millard wrote:
> [stuff snipped]
>> Well, why is it that ls -R, find, and diff -r all get file
>> name problems via genet0 but diff -r gets no problems
>> comparing the content of files that it does match up (the
>> vast majority)? Any clue
Mark Millard wrote:
[stuff snipped]
>Well, why is it that ls -R, find, and diff -r all get file
>name problems via genet0 but diff -r gets no problems
>comparing the content of files that it does match up (the
>vast majority)? Any clue how could the problems possibly
>be unique to the handling of
On 2021-May-21, at 09:00, Rick Macklem wrote:
> Mark Millard wrote:
>> On 2021-May-20, at 22:19, Rick Macklem wrote:
> [stuff snipped]
>>> ps: I do not think that r367492 could cause this, but it would be
>>>nice if you try a kernel with the r367492 patch reverted.
>>>It is currently
Mark Millard wrote:
>On 2021-May-20, at 22:19, Rick Macklem wrote:
[stuff snipped]
>> ps: I do not think that r367492 could cause this, but it would be
>> nice if you try a kernel with the r367492 patch reverted.
>> It is currently in all of releng13, stable13 and main, although
>>
W dniu 25.02.2019 o 18:47, Marek Zarychta pisze:
> W dniu 08.01.2019 o 12:51, Stefan Bethke pisze:
>> Am 08.01.2019 um 10:34 schrieb Marek Zarychta
>> :
>>> W dniu 03.01.2019 o 14:13, Stefan Bethke pisze:
> I have under supervision a few old servers running 11.2-STABLE. The
> hardware is
Hi List,
I’m observing some odd behaviour after I decided to put the 2 interfaces in my
system into a lagg failover bond
- Can’t add the lagg to a bridge, it will say:
$ sudo ifconfig vm-public addm lagg0
ifconfig: BRDGADD lagg0: Device busy
I also witnessed that starting a vm after having it
[Looks like the RPi4B genet0 handling is involved.]
On 2021-May-20, at 22:56, Mark Millard wrote:
>
> On 2021-May-20, at 22:19, Rick Macklem wrote:
>
>> Ok, so it isn't related to "soft".
>> I am wondering if it is something specific to what
>> "diff -r" does?
>>
>> Could you try:
>> # cd
On 2021-May-20, at 22:19, Rick Macklem wrote:
> Ok, so it isn't related to "soft".
> I am wondering if it is something specific to what
> "diff -r" does?
>
> Could you try:
> # cd /usr/ports
> # ls -R > /tmp/x
> # cd /mnt
> # ls -R > /tmp/y
> # cd /tmp
> # diff -u -p x y
> --> To see if "ls
Ok, so it isn't related to "soft".
I am wondering if it is something specific to what
"diff -r" does?
Could you try:
# cd /usr/ports
# ls -R > /tmp/x
# cd /mnt
# ls -R > /tmp/y
# cd /tmp
# diff -u -p x y
--> To see if "ls -R" finds any difference?
rick
ps: I do not think that r367492 could cause
[Direct drive connection to machine: no problem.]
On 2021-May-20, at 21:40, Mark Millard wrote:
> [main test example and main/releng/13 mixed example]
>
> On 2021-May-20, at 20:36, Mark Millard wrote:
>
>> [stable/13 test: example ends up being odder. That might
>> allow eliminating some
[main test example and main/releng/13 mixed example]
On 2021-May-20, at 20:36, Mark Millard wrote:
> [stable/13 test: example ends up being odder. That might
> allow eliminating some potential alternatives.]
>
> On 2021-May-20, at 19:38, Mark Millard wrote:
>>
>> On 2021-May-20, at 18:09,
[stable/13 test: example ends up being odder. That might
allow eliminating some potential alternatives.]
On 2021-May-20, at 19:38, Mark Millard wrote:
>
> On 2021-May-20, at 18:09, Rick Macklem wrote:
>>
>> Oh, one additional thing that I'll dare to top post...
>> r367492 broke the TCP
> On 2021-May-20, at 18:09, Rick Macklem wrote:
>
> Oh, one additional thing that I'll dare to top post...
> r367492 broke the TCP upcalls that the NFS server uses, such
> that intermittent hangs of NFS mounts to FreeBSD13 servers can occur.
> This has not yet been resolved in "main" etc and
Oh, one additional thing that I'll dare to top post...
r367492 broke the TCP upcalls that the NFS server uses, such
that intermittent hangs of NFS mounts to FreeBSD13 servers can occur.
This has not yet been resolved in "main" etc and could explain
why an RPC could time out for a soft mount.
You
Mark Millard wrote:
>[I warn that I'm a fairly minimal user of NFS
>mounts, not knowing all that much. I'm mostly
>reporting this in case it ends up as evidence
>via eventually matching up with others observing
>possibly related oddities.]
>
>I got the following odd sequence (that I've
>mixed
[I warn that I'm a fairly minimal user of NFS
mounts, not knowing all that much. I'm mostly
reporting this in case it ends up as evidence
via eventually matching up with others observing
possibly related oddities.]
I got the following odd sequence (that I've
mixed notes into). It involved a diff
Asus S510UQ laptop
acpiconf -s 3 susp/resume works perfectly on 11.[12], 12.[012]
On 12.2 susp/resume worked with iichid.ko loaded from port
sysutils/iichid 0.0.6.
On 13.0-RELEASE susp/resume works when kernel iichid.ko is not loaded
but resume breaks if iichid.ko is loaded.
When loading
Hello,
since last 'pkg upgrade' I get an error:
Rscript ./web_ft-c_skripte/m_trading/R_import/update_currency.R ;
Error: package or namespace load failed for ‘RPostgreSQL’ in
dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object
On 2021-May-16 11:48:24 +1000, Peter Jeremy via freebsd-stable
wrote:
>I am running 13-stable from a couple of weeks ago, without Capsicum
>(neither CAPABILITY_MODE nor CAPABILITIES are specified in my kernel).
>Despite this, I am getting Capsicum-related errors. As an example:
>
I am running 13-stable from a couple of weeks ago, without Capsicum
(neither CAPABILITY_MODE nor CAPABILITIES are specified in my kernel).
Despite this, I am getting Capsicum-related errors. As an example:
openat(AT_FDCWD, "/")
will return ENOTCAPABLE.
Rummaging around the sources, it seems
> Could you check the values of the following sysctl variables:
>
> vfs.zfs.vdev.cache_size
> vfs.zfs.vdev.cache_bshift
> vfs.zfs.vdev.cache_max
> kstat.zfs.misc.vdev_cache_stats.misses
> kstat.zfs.misc.vdev_cache_stats.hits
> kstat.zfs.misc.vdev_cache_stats.delegations
As predicted, all zero,
Am 14.05.21 um 10:34 schrieb Pete French:
>
> Am just upgrading my machiens, and have noticed an oddity.
> This is on a machine runnign 12.2
>
> # zfs-stats -D
>
>
> ZFS Subsystem Report Fri May 14
Am just upgrading my machiens, and have noticed an oddity.
This is on a machine runnign 12.2
# zfs-stats -D
ZFS Subsystem ReportFri May 14 08:30:50 2021
___
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"
Your mailbox is almost full.
Dear
sta...@freebsd.org mailto:sta...@freebsd.org
,
15153 MB
15206 MB
Current size
Maximum size
Please reduce your mailbox size. Delete any items you don't need from your
mailbox and empty your Deleted Items folder.
Go here-
On Sat, May 08, 2021 at 06:33:02PM +0700, Eugene Grosbein wrote:
> 08.05.2021 2:52, Konstantin Belousov wrote:
>
> > i386 kernel uses memory up to 24G since 13.0.
> >
> > PAE only means that devices that can access full 64bit address are allowed
> > to avoid dma bouncing.
>
> Maybe you could
On 08/05/2021 15:20, Dimitry Andric wrote:
On 8 May 2021, at 16:02, Roger Leigh wrote:
This might sound like a bit of an odd one, but I’ll try to describe it. When I
run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work
correctly, but randomly stops working.
If I focus
On 8 May 2021, at 16:02, Roger Leigh wrote:
>
> This might sound like a bit of an odd one, but I’ll try to describe it. When
> I run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work
> correctly, but randomly stops working.
>
> If I focus the VMware window, and press
Hi,
This might sound like a bit of an odd one, but I’ll try to describe it. When I
run a FreeBSD 13-RELEASE virtual machine under VMware, it appears to work
correctly, but randomly stops working.
If I focus the VMware window, and press Ctrl-G to grab input focus (or click in
the window), I
From: Yasuhiro Kimura
Subject: Re: Loading zfs module results in hangup on i386
Date: Sat, 08 May 2021 07:44:15 +0900 (JST)
>> Now I think I know what is the source of problem. After all, on
>> 13.0-RELEASE i386 system simply loading zfs module results in system
>> hang up.
>>
>> The steps to
08.05.2021 2:52, Konstantin Belousov wrote:
> i386 kernel uses memory up to 24G since 13.0.
>
> PAE only means that devices that can access full 64bit address are allowed
> to avoid dma bouncing.
Maybe you could tell something on similar topic?
There is FreeBSD 12.2-STABLE r369567 Base12 amd64
From: Yasuhiro Kimura
Subject: Loading zfs module results in hangup on i386 (Re: Install of
13.0-RELEASE i386 with ZFS root hangs up)
Date: Sat, 08 May 2021 07:31:47 +0900 (JST)
> Now I think I know what is the source of problem. After all, on
> 13.0-RELEASE i386 system simply loading zfs
From: Yasuhiro Kimura
Subject: Install of 13.0-RELEASE i386 with ZFS root hangs up
Date: Fri, 07 May 2021 21:47:59 +0900 (JST)
> Hello,
>
> Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
>
> I tried this with VirtualBox and VMware Player on Windows with
> following VM
On Fri, May 07, 2021 at 09:48:07AM -0700, Freddie Cash wrote:
> On Fri, May 7, 2021 at 5:49 AM Yasuhiro Kimura wrote:
>
> > Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
> >
> > I tried this with VirtualBox and VMware Player on Windows with
> > following VM condition.
> >
> > *
On Fri, May 7, 2021 at 5:49 AM Yasuhiro Kimura wrote:
> Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
>
> I tried this with VirtualBox and VMware Player on Windows with
> following VM condition.
>
> * 4 CPUs
> * 8GB memory
> * 100GB disk
> * Bridge mode NIC
>
> But in both
On Wed, May 05, 2021 at 07:33:23PM +, Glen Barber wrote:
> On Wed, May 05, 2021 at 09:16:19PM +0200, Gordon Bergling wrote:
> > On Wed, May 05, 2021 at 07:02:42PM +, Glen Barber wrote:
> > > On Wed, May 05, 2021 at 08:56:58PM +0200, Gordon Bergling wrote:
> > > > I am currently try to
From: 8zwk...@oldach.net (Helge Oldach)
Subject: Re: Install of 13.0-RELEASE i386 with ZFS root hangs up
Date: Fri, 7 May 2021 15:41:45 +0200 (CEST)
> Yasuhiro Kimura wrote on Fri, 07 May 2021 14:47:59 +0200 (CEST):
>> Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
>
Hello,
Does anyone succeed to install 13.0-RELEASE i386 with ZFS root?
I tried this with VirtualBox and VMware Player on Windows with
following VM condition.
* 4 CPUs
* 8GB memory
* 100GB disk
* Bridge mode NIC
But in both cases, VM gets high CPU load and hangs up after I moved
to 'YES' at
On 2021-May-06 19:07:23 -0400, monochrome wrote:
...
>On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote:
...
>> server% tail /COPYRIGHT <&-
>> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file
>> /usr/src/lib/libcasper/libcasper/service.c, line 394.
>> tail: unable
On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote:
On 2021-May-06 12:59:54 +0200, Mariusz Zaborski wrote:
Could you provide details how to reproduce this?
On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable
wrote:
Since updating from 12-stable to 13-stable, I've found
On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote:
tail /COPYRIGHT <&-
I get a different error on a 13.0-RELEASE machine I converted from 12 to
current about a year ago:
$ tail /COPYRIGHT <&-
tail: can't limit stdio rights: Bad file descriptor
Having used bsdinstall to make a USB3 SSD on a RPi4B
(zfs-on-root, GPT parition, RPi4B materials copied
copied to msdos file system), booting gets error notices:
newsyslog: malformed 'at' value:
/var/log/all.log600 7 *@T00 J
newsyslog: malformed 'at' value:
On 2021-May-06 12:59:54 +0200, Mariusz Zaborski wrote:
>Could you provide details how to reproduce this?
>
>On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable
> wrote:
>>
>> Since updating from 12-stable to 13-stable, I've found that tail(1)
>> crashes, reporting:
>> Assertion failed:
Could you provide details how to reproduce this?
On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable
wrote:
>
> Since updating from 12-stable to 13-stable, I've found that tail(1)
> crashes, reporting:
> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file
>
Since updating from 12-stable to 13-stable, I've found that tail(1)
crashes, reporting:
Assertion failed: (procfd > STDERR_FILENO), function service_clean, file
/usr/src/lib/libcasper/libcasper/service.c, line 394.
tail: unable to init casper: Socket is not connected
unless all three of stdin,
On 2021-May-5, at 17:01, Yuri Pankov wrote:
> Mark Millard via freebsd-current wrote:
>> Context:
>>
>> # gpart show -pl da0
>> => 40 468862048da0 GPT (224G)
>> 40 532480 da0p1 efiboot0 (260M)
>> 532520 2008 - free - (1.0M)
>> 534528
Mark Millard via freebsd-current wrote:
> Context:
>
> # gpart show -pl da0
> => 40 468862048da0 GPT (224G)
> 40 532480 da0p1 efiboot0 (260M)
> 532520 2008 - free - (1.0M)
> 534528 25165824 da0p2 swp12a (12G)
>25700352 25165824
Introduction
This report covers FreeBSD related projects for the period between January and
March, and is the first of four planned reports for 2021.
The first quarter of 2021 has been very active in both FreeBSD-CURRENT and
-STABLE, with 13.0-RELEASE work starting in January and finishing up
Context:
# gpart show -pl da0
=> 40 468862048da0 GPT (224G)
40 532480 da0p1 efiboot0 (260M)
532520 2008 - free - (1.0M)
534528 25165824 da0p2 swp12a (12G)
25700352 25165824 da0p4 swp12b (12G)
50866176 417994752 da0p3 zfs0
On 2021-May-5, at 05:28, Mark Millard wrote:
> On 2021-May-5, at 02:47, Andriy Gapon wrote:
>
>> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>>> I had a:
>>> # zfs list -tall
>>> NAME USED AVAIL REFER MOUNTPOINT
>>> . . .
>>>
On Wed, May 05, 2021 at 09:16:19PM +0200, Gordon Bergling wrote:
> On Wed, May 05, 2021 at 07:02:42PM +, Glen Barber wrote:
> > On Wed, May 05, 2021 at 08:56:58PM +0200, Gordon Bergling wrote:
> > > Hi,
> > >
> > > I am currently try to build a custom 13-STABLE release for i386, build on
> >
On Wed, May 05, 2021 at 07:02:42PM +, Glen Barber wrote:
> On Wed, May 05, 2021 at 08:56:58PM +0200, Gordon Bergling wrote:
> > Hi,
> >
> > I am currently try to build a custom 13-STABLE release for i386, build on
> > an amd64 system. According to release(7) the following command should
> >
On Wed, May 05, 2021 at 08:56:58PM +0200, Gordon Bergling wrote:
> Hi,
>
> I am currently try to build a custom 13-STABLE release for i386, build on
> an amd64 system. According to release(7) the following command should
> do the trick, but it fails with the following error message.
>
> $ doas
Hi,
I am currently try to build a custom 13-STABLE release for i386, build on
an amd64 system. According to release(7) the following command should
do the trick, but it fails with the following error message.
$ doas sh release.sh -c i386/i386.conf
ld-elf32.so.1: Shared object "libedit.so.8" not
On 2021-May-4, at 20:26, Mark Millard wrote:
> On 2021-May-4, at 13:38, Mark Millard wrote:
>
>> [The first buidlworld is still in process. So while waiting . . .]
>>
>> On 2021-May-4, at 10:31, Mark Millard wrote:
>>
>>> I probably know why the huge count of differences this time
>>>
On 2021-May-5, at 02:47, Andriy Gapon wrote:
> On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
>> I had a:
>> # zfs list -tall
>> NAME USED AVAIL REFER MOUNTPOINT
>> . . .
>> zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G
On 05/05/2021 01:59, Mark Millard via freebsd-current wrote:
I had a:
# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
On 2021-May-4, at 13:38, Mark Millard wrote:
> [The first buidlworld is still in process. So while waiting . . .]
>
> On 2021-May-4, at 10:31, Mark Millard wrote:
>
>> I probably know why the huge count of differences this time
>> unlike the original report . . .
>>
>> Previously I built
I had a:
# zfs list -tall
NAME USED AVAIL REFER MOUNTPOINT
. . .
zroot/DESTDIRs/13_0R-CA72-instwrld-norm 1.44G 117G 96K
/usr/obj/DESTDIRs/13_0R-CA72-instwrld-norm
zroot/DESTDIRs/13_0R-CA72-instwrld-norm@dirty-style 1.44G -
[The first buidlworld is still in process. So while waiting . . .]
On 2021-May-4, at 10:31, Mark Millard wrote:
> I probably know why the huge count of differences this time
> unlike the original report . . .
>
> Previously I built based on a checked-in branch as part of
> my experimenting.
I had reported in the reproducable build list messages:
> # diffoscope /.zfs/snapshot/2021-04-*-01:40:48-0/bin/sh
> [...]
> $<3/>2021-05-04 08:49:21 W: diffoscope.main: Fuzzy-matching is currently
> disabled as the "tlsh" module is unavailable.
> UnicodeDecodeError: 'utf-8' codec can't decode
I probably know why the huge count of differences this time
unlike the original report . . .
Previously I built based on a checked-in branch as part of
my experimenting. This time it was in a -dirty form (not
checked in), again as part of my experimental exploration.
WITH_REPRODUCIBLE_BUILD=
[Just adding readelf -S info since it seems to show more.]
On 2021-May-4, at 10:01, Mark Millard wrote:
> On 2021-May-4, at 08:51, Mark Millard wrote:
>
>> On 2021-May-4, at 06:01, Ed Maste wrote:
>>
>>> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
But I'll note that I've
On 2021-May-4, at 08:51, Mark Millard wrote:
> On 2021-May-4, at 06:01, Ed Maste wrote:
>
>> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>>
>>> But I'll note that I've built and stalled py37-diffoscope
>>> (new to me). A basic quick test showed that it reports:
>>>
>>> W:
On Tue, 4 May 2021 at 11:52, Mark Millard wrote:
>
> > As far as the utf-8 issues go, diffoscope requires a utf-8 locale and
> > I suspect that is the issue. If you don't have LANG set already, try
> > setting LANG=C.UTF-8 in your environment.
>
> That is not the issue for the UnicodeDecodeError:
On 2021-May-4, at 06:01, Ed Maste wrote:
> On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>>
>> But I'll note that I've built and stalled py37-diffoscope
>> (new to me). A basic quick test showed that it reports:
>>
>> W: diffoscope.main: Fuzzy-matching is currently disabled as the
> On 4 May 2021, at 15:23, Shawn Webb wrote:
>
> Unfortunately, bhyve doesn't support renamed tap devices. You'll need
> to keep the original tapN name.
>
> What you might want to experiment with is setting a description for
> the tap device. For example:
>
> ifconfig tapN description
On Mon, May 03, 2021 at 10:46:34PM +0200, Juraj Lutter wrote:
> Hi,
>
> my bhyve command line (on 13.0-RELEASE) is:
>
> /usr/sbin/bhyve -c 2 -m 4G -H -A -P -u -s 0:0,hostbridge -s 1:0,lpc -s
> 2:0,virtio-net,tap100 -s 3:0,virtio-net,priv0 -s
>
On Mon, 3 May 2021 at 22:26, Mark Millard wrote:
>
> But I'll note that I've built and stalled py37-diffoscope
> (new to me). A basic quick test showed that it reports:
>
> W: diffoscope.main: Fuzzy-matching is currently disabled as the "tlsh" module
> is unavailable.
I just looked up tlsh -
On 2021-May-3, at 21:27, Mark Millard wrote:
> On 2021-May-3, at 19:26, Mark Millard wrote:
>
>> On 2021-May-3, at 10:51, Mark Millard wrote:
>>
>>> On 2021-May-3, at 07:47, Ed Maste wrote:
>>>
On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
wrote:
>
>
On 2021-May-3, at 19:26, Mark Millard wrote:
> On 2021-May-3, at 10:51, Mark Millard wrote:
>
>> On 2021-May-3, at 07:47, Ed Maste wrote:
>>
>>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>>> wrote:
Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
On 2021-May-3, at 10:51, Mark Millard wrote:
> On 2021-May-3, at 07:47, Ed Maste wrote:
>
>> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
>> wrote:
>>>
>>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
>>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
>>>
Hi,
my bhyve command line (on 13.0-RELEASE) is:
/usr/sbin/bhyve -c 2 -m 4G -H -A -P -u -s 0:0,hostbridge -s 1:0,lpc -s
2:0,virtio-net,tap100 -s 3:0,virtio-net,priv0 -s
4:0,virtio-blk,/dev/zvol/zroot/data/minio/host0/root -l com1,/dev/nmdm100B mr
the result is:
device emulation initialization
On 2021-May-3, at 07:47, Ed Maste wrote:
> On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
> wrote:
>>
>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
>> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
>> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and
On Thu, 29 Apr 2021 at 02:50, Mark Millard via freebsd-current
wrote:
>
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping and
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping differ
> Files /usr/obj/DESTDIRs/13_0R-CA7-chroot/sbin/ping6 and
> /usr/obj/DESTDIRs/13_0R-CA7-poud/sbin/ping6 differ
>
On Sun, May 2, 2021 at 6:27 PM Rick Macklem wrote:
> Rick Macklem wrote:
> >Hi,
> >
> >I posted recently that enabling delegations should be avoided at this
> time,
> >especially if your FreeBSD NFS server has Linux client mounts...
> >
> >I thought some of you might be curious why, and I
Rick Macklem wrote:
>Hi,
>
>I posted recently that enabling delegations should be avoided at this time,
>especially if your FreeBSD NFS server has Linux client mounts...
>
>I thought some of you might be curious why, and I thought it would be
>more fun if you look for yourselves.
>To play the
On 25.04.21 11:15, dashdruid via freebsd-stable wrote:
Hello,
I have reinstalled it with GPT/ZFS and your right it's much better. Same search
taking 3-6 seconds so I have deleted now all my old UFS based FreeBSD images.
If the partitioning alone changed something it was probably an
* Andrew Reilly [20210501 11:45]:
> mergemaster -p
> make -s installworld
> mergemaster -U
Note you shouldn't use mergemaster any more. It works fine for upgrading
to 13, but after that, I'd expect problems because it relies on the old
VCS tags. Use etcupdate instead, see here for details:
> 1 maj 2021 kl. 03:45 skrev Andrew Reilly :
>
> In case anyone's interested: for this morning's software maintenance
> session (at home) I upgraded my file server from FreeBSD stable/12
> to the recently released stable/13. From source, in-place, on a
> running, on-line system. Despite the
In case anyone's interested: for this morning's software maintenance
session (at home) I upgraded my file server from FreeBSD stable/12
to the recently released stable/13. From source, in-place, on a
running, on-line system. Despite the fact that the entire ZFS
subsystem has been replaced,
On 2021-04-30 00:30, Yasuhiro Kimura wrote:
I installed dns/bind916 on my home server and configured it so it
worked as both authoritative and recursor. Then I added
'nameserver 127.0.0.1' to /etc/resolv.conf and everything worked fine.
But after updating OS from 12.2-RELEASE to 13.0-RELEASE I
30.04.2021 14:30, Yasuhiro Kimura wrote:
> I installed dns/bind916 on my home server and configured it so it
> worked as both authoritative and recursor. Then I added
> 'nameserver 127.0.0.1' to /etc/resolv.conf and everything worked fine.
>
> But after updating OS from 12.2-RELEASE to
From: b56...@oldach.net (Helge Oldach)
Subject: Re: How to make 'named' rc script invokded earlier at boot time
Date: Fri, 30 Apr 2021 11:25:03 +0200 (CEST)
> Looks like this is caused by security/trousers which has "BEFORE: named
> hastd". This port had been touched 3 weeks ago.
You provide me
On 2021-04-30 11:12, Arrigo Marchiori via freebsd-stable wrote:
> On Fri, Apr 30, 2021 at 10:29:33AM +0200, Andrea Brancatelli via
> freebsd-stable wrote:
>
>> Hello,
>>
>> I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
>> geom multiparty, a Dell MD3200i and fstab.
>>
From: Yasuhiro Kimura
Subject: Re: How to make 'named' rc script invokded earlier at boot time
Date: Fri, 30 Apr 2021 17:18:26 +0900 (JST)
>> The only way I can see is modify the named rc script and add the
>> services that needs named to be started on the BEFORE line at the
>> beginning of the
Hello,
On Fri, Apr 30, 2021 at 10:29:33AM +0200, Andrea Brancatelli via freebsd-stable
wrote:
> Hello,
>
> I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
> geom multiparty, a Dell MD3200i and fstab.
>
> Long story short, iSCSI login/connection/whatever is slower than
On 2021-04-30 10:29, Andrea Brancatelli via freebsd-stable wrote:
> Hello,
>
> I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
> geom multiparty, a Dell MD3200i and fstab.
Geom multiparty is probably the best typo/autocorrect ever.
---
Andrea Brancatelli
Hello,
I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
geom multiparty, a Dell MD3200i and fstab.
Long story short, iSCSI login/connection/whatever is slower than the
boot process and the machine always get stuck with "cannot find
/san_storage (/dev/multipath/...) please
From: Mathieu Arnold
Subject: Re: How to make 'named' rc script invokded earlier at boot time
Date: Fri, 30 Apr 2021 10:02:31 +0200
> There is an option in the port to have named start later, but up to now,
> it was starting early enough.
>
> The only way I can see is modify the named rc script
From: b56...@oldach.net (Helge Oldach)
Subject: Re: How to make 'named' rc script invokded earlier at boot time
Date: Fri, 30 Apr 2021 10:01:47 +0200 (CEST)
> Can you try rcorder -p? That will group equally ranked scripts on the same
> line.
>
> On 13, I'm seeing:
>
> (snip)
>
On Fri, Apr 30, 2021 at 04:30:54PM +0900, Yasuhiro Kimura wrote:
> Then is there any way to make 'named' rc script invoked earlier at
> boot time on 13.0-RELEASE?
There is an option in the port to have named start later, but up to now,
it was starting early enough.
The only way I can see is
I installed dns/bind916 on my home server and configured it so it
worked as both authoritative and recursor. Then I added
'nameserver 127.0.0.1' to /etc/resolv.conf and everything worked fine.
But after updating OS from 12.2-RELEASE to 13.0-RELEASE I noticed
execution of some rc scripts fails at
On Wed, 28 Apr 2021, parv/freebsd wrote:
Solved the issue via ...
% sysctl hw.efi.poweroff=0
... after that shudown went on as expected. Got that from ...
https://forums.freebsd.org/threads/freebsd-13-does-not-shut-down-my-laptop.79853/
Well, this also solved my problem described in a
I did 2 test buildworld's based on:
# ~/fbsd-based-on-what-freebsd.sh
branch: releng/13.0
merge-base: ea31abc261ffc01b6ff5671bffb15cf910a07f4b
merge-base: CommitDate: 2021-04-09 00:14:30 +
ea31abc261ff (HEAD -> releng/13.0, tag: release/13.0.0, freebsd/releng/13.0)
13.0: update to RELEASE
(Changed my email address to the one I used to subscribe to the mailing
list.)
On Wed, Apr 28, 2021 at 10:05 AM Guido Falsi wrote:
Hi,
On 28/04/21 00:12, parv wrote:
> > I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from
> > 12-STABLE
> > to 13-STABLE; upgraded the ZFS pools &
On 28/04/21 00:12, parv wrote:
Hi there,
I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from
12-STABLE
to 13-STABLE; upgraded the ZFS pools & the EFI boot loader. Currently
testing with 13 GENERIC kernel.
You mean you enabled EFI inside virtualbox? Why do you need that? EFI
Hi there,
I had updated FreeBSD, in VirtualBox 5.22 on Windows with EFI, from
12-STABLE
to 13-STABLE; upgraded the ZFS pools & the EFI boot loader. Currently
testing with 13 GENERIC kernel.
Now on shutdown, "shutdown -p now" (in single user mode, after manually
unmounting
ZFS datasets via "zfs
1 - 100 of 88298 matches
Mail list logo
