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 dif
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 t
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 how
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 f
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
>> the
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 a
[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 /us
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 -
___
From: Mark Millard
Sent: Friday, May 21, 2021 12:40 AM
To: Rick Macklem
Cc: FreeBSD-STABLE Mailing List
Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in
a zfs file systems context)
CAUTION: This email originated from outside of the University of Gue
gt;> I'll have to figure out how to experiment with such. Things
>>> are at defaults rather generally on the systems. I'm not
>>> literate in the subject areas.
>>>
>>> I'm the only user of the machines and network. It is not
>>> ou
r of the machines and network. It is not
>> outward facing. It is a rather small EtherNet network.
>>
>>> rick
>>>
>>>
>>> From: owner-freebsd-sta...@freebsd.org
>>> on behalf of Rick Macklem
&
not
> literate in the subject areas.
>
> I'm the only user of the machines and network. It is not
> outward facing. It is a rather small EtherNet network.
>
>> rick
>>
>>
>> From: owner-freebsd-sta...@freebsd.org
ebsd.org on
> behalf of Rick Macklem
> Sent: Thursday, May 20, 2021 8:55 PM
> To: FreeBSD-STABLE Mailing List; Mark Millard
> Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs
> (in a zfs file systems context)
>
> Mark Millard wrote:
>> [I wa
ner-freebsd-sta...@freebsd.org on
behalf of Rick Macklem
Sent: Thursday, May 20, 2021 8:55 PM
To: FreeBSD-STABLE Mailing List; Mark Millard
Subject: Re: releng/13 release/13.0.0 : odd/incorrect diff result over nfs (in
a zfs file systems context)
Mark Millard wrote:
>[I warn that I'm a fairly mini
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 notes
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:
>openat(AT_FD
> 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, apa
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
___
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"
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 tel
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 Ctrl-
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.
&
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 loadi
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 condition
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 cases
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 build
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
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 t
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 tha
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
_
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: (p
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
> /usr/src
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 251658
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 da0p
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
>>> . . .
>>> zroot/DE
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
> > do
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 sh
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
>>> unlike
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 1
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
zroot
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 ba
[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. Thi
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= make
[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 bu
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: diffoscope.
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 "tlsh"
> 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 "privat
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
> 4:0,virtio-blk,/dev/zvol/zroot/data/minio/host0/roo
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 - its
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
>>> Files
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
> Fi
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 thought
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 game,
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 alignment
> 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 f
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 n
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 13.0-RELEAS
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
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 t
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 t
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
___
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 modi
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 seei
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 modif
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 mess
(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
su
On 2021-04-27 11:28, Ian Lepore wrote:
On Tue, 2021-04-27 at 19:22 +0100, tech-lists wrote:
Hi,
Not sure where to put this. system is amd64/stable/13. It's running
powerd but with no additional flags.
CPU is Intel(R) Core(TM) i7-4770K CPU. Has 32GB RAM
The system is clocked in the bios at 4.2
On Tue, Apr 27, 2021 at 12:28:53PM -0600, Ian Lepore wrote:
The same is true on my system:
CPU: Intel(R) Xeon(R) CPU W3680 @ 3.33GHz (4250.09-MHz K8-class CPU)
Thank you Ian for confirming
--
J.
signature.asc
Description: PGP signature
On Tue, 2021-04-27 at 19:22 +0100, tech-lists wrote:
> Hi,
>
> Not sure where to put this. system is amd64/stable/13. It's running
> powerd but with no additional flags.
>
> CPU is Intel(R) Core(TM) i7-4770K CPU. Has 32GB RAM
>
> The system is clocked in the bios at 4.251 GHz. I never see this
>
For me too. I upgraded a server from 12.2-p5 to 13.0 2 weeks ago and the only
thing “extra” I had ti do we import my ZFS pool which is expected as it was a
different version :)
More servers to do soon!
\\Clay
> On 27 Apr 2021, at 07:51, Chris wrote:
>
> Great
>>>
>> I can
>> It looks like there’s some confusion inside pfctl about the network group.
>> It ends up in pfctl_parser.c, append_addr_host(), and expects an AF_INET or
>> AF_INET6, but instead gets an AF_LINK.
>>
>> It’s probably related to 250994 or possibly
>> d2568b024da283bd2b88a633eec
On 16 Apr 2021, at 17:58, Kristof Provost wrote:
On 14 Apr 2021, at 16:16, Peter Ankerstål wrote:
In pf I use the interface group syntax alot to make the configuration
more readable. All interfaces are assigned to a group representing
its use/vlan name.
For example:
ifconfig_igb1_102="172.22
On Mon, Apr 26, 2021 at 3:04 PM mike tancsa wrote:
> On 4/23/2021 11:47 PM, Peter Libassi wrote:
> > Yes, I’ve come to the same conclusion. This should be used on a
> > data-zpool and not on the system-pool (zroot). Encryption is per
> > dataset. Also if found that if the encrypted dataset is not
On 4/23/2021 11:47 PM, Peter Libassi wrote:
> Yes, I’ve come to the same conclusion. This should be used on a
> data-zpool and not on the system-pool (zroot). Encryption is per
> dataset. Also if found that if the encrypted dataset is not mounted of
> some reason you will be writing to the parent u
On 4/23/2021 5:23 PM, Xin Li wrote:
> On 4/23/21 13:53, mike tancsa wrote:
>> Starting to play around with RELENG_13 and wanted explore ZFS' built in
>> encryption. Is there a best practices doc on how to do full disk
>> encryption anywhere thats not GELI based ? There are lots for
>> GELI,
>>
On 4/24/21 12:22 PM, Mark Millard via freebsd-current wrote:
# etcupdate -?
Illegal option -?
usage: etcupdate [-npBF] [-d workdir] [-r | -s source | -t tarball]
[-A patterns] [-D destdir] [-I patterns] [-L logfile]
[-M options]
etcupdate build [-B] [-
On Mon, Apr 26, 2021 at 8:34 PM 宋立杰 wrote:
>
> > 在 2021年4月25日，23:04，Li-Wen Hsu 写道：
> >
> > On Sun, Apr 25, 2021 at 9:55 PM 宋立杰 wrote:
> >>
> >> Yes, there is no ue0. And I made a mistake, it is 12.2-RELEASE other
> than STABLE. Sorry for that. Do I need to install STABLE to keep up with
> the
> 在 2021年4月25日，23:04，Li-Wen Hsu 写道：
>
> On Sun, Apr 25, 2021 at 9:55 PM 宋立杰 wrote:
>>
>> Yes, there is no ue0. And I made a mistake, it is 12.2-RELEASE other than
>> STABLE. Sorry for that. Do I need to install STABLE to keep up with the
>> newest development?
>>
>> This time usbmuxd works
On 2021-Apr-25, at 08:14, Graham Perrin wrote:
> On 23/04/2021 08:39, Mark Millard via freebsd-current wrote:
>
>> [3]
>
>
> With regard to mounting ZFS file systems in single user mode
>
> What's currently footnote 3 will probably become footnote 4, please see
On Sun, Apr 25, 2021 at 9:55 PM 宋立杰 wrote:
>
>
> > 在 2021年4月25日，19:08，Li-Wen Hsu 写道：
> >
> >
> >
> > I didn't see behavior before, previously if there is no ue0 found,
> > other than usbconfig set_config, I use `/usr/local/sbin/usbmuxd -U
> > root -f` from usbmuxd pkg.
> >
> > For iOS 14, this
> Am 24.04.2021 um 15:03 schrieb Jeff Love :
>
> I'm running 12.2 and 13.0 on KVM using virtio and zfs. I am not having disk
> I/O issues.
UFS or ZFS does not make a difference for me.
ZFS is faster on read due to compression - that’s why back in the XenServer
days I didn’t even realize it
On Sun, Apr 25, 2021 at 10:00 AM 宋立杰 via freebsd-stable
wrote:
>
>
> I tried to connect my iPhone SE2 (iOS 13.7) to FreeBSD 12.2-stable. After
> loaded the kernel module if_ipheth, I connected my phone.
> > ugen0.2: at usbus0
>
> Then I typed usbconfig -u 0 -a 2 set_config 3
> > ipeth0 on uhub6
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.
I wonder how I didn't notice this earlier because I had 12.0, 12.2 base images
and now that I retested them they had the exact sam
I'm running 12.2 and 13.0 on KVM using virtio and zfs. I am not having
disk I/O issues.
Jeff Love
On 4/24/21 5:25 AM, dashdruid via freebsd-stable wrote:
Hello List,
I hope some other folks out there running FreeBSD on KVM as well. I set up a
base VM while doing so I noticed that the disk op
> I hope some other folks out there running FreeBSD on KVM as well. I set
up a base VM while doing so I noticed that the disk operations are very
slow. Many times I edit a file in vim or try to run a command there is a
huge lag.
I noticed this on Ramnode--my VPS--and tech support there has told me
We have over 50 FreeBSD VM on KVM for years, several Proxmox (5x,6x) and
Centos (6.x,7.x) servers, and never experienced performance problem like
this.
Your example on fresh new 13 VM:
# time -p find / -name cacert.pem
real 0.28
user 0.00
sys 0.13
12.2 our syslog server:
# time -p find / -na
> Am 24.04.2021 um 11:25 schrieb dashdruid via freebsd-stable
> :
>
> Hello List,
>
> I hope some other folks out there running FreeBSD on KVM as well. I set up a
> base VM while doing so I noticed that the disk operations are very slow. Many
> times I edit a file in vim or try to run a comm
On 4/23/21 11:23 PM, Xin Li via freebsd-stable wrote:
I think loader do not support the native OpenZFS encryption yet.
However, you can encrypt non-essential datasets on a boot pool (that is,
if com.datto:encryption is "active" AND the bootfs dataset is not
encrypted, you can still boot from it)
> 23 apr. 2021 kl. 23:23 skrev Xin Li via freebsd-stable
> :
>
> On 4/23/21 13:53, mike tancsa wrote:
>> Starting to play around with RELENG_13 and wanted explore ZFS' built in
>> encryption. Is there a best practices doc on how to do full disk
>> encryption anywhere thats not GELI based ? T
1 - 100 of 70585 matches
Mail list logo
