all 100 cards, yet no
>one (pardon me if I missed those) asks for 10. So how about making this
>proposal cover only 10 cards,
What is the purpose in keeping unused FastEthernet cards in the tree?
>if you can't resist the itch to remove
>something from the tree?
Again, that lang
h ashift=9
* The initial disks reported 512B native (I think this is most likely)
* That version of ZFS was using logical, rather than native blocksize.
My guess (given that only ada1 is reporting a blocksize mismatch) is that
your disks reported a 512B native blocksize. In the absence of any override,
ZFS will
>root: /etc/rc: WARNING: failed to start unbound
I have seen unbound fail to start for a variety of reasons but in all cases, it
has
written a useful hint to the console. Can you confirm that it's not writing
anything
to your console. Are you able to share your configuration?
--
Peter Jeremy
On 2019-Aug-20 14:36:14 +0200, Trond Endrestøl
wrote:
>Maybe NFS is to blame, particularly if file locks cannot be obtained.
Yes, it is. SVN tries to obtain locks, even for read-only commands like
"svn info". My solution is to mount /usr/src with the option "nolockd&q
lock set correctly).
--
Peter Jeremy
signature.asc
Description: PGP signature
t relevant but it would be useful for you to say up front
which ntpd you are having problems with and which version of the port you
have installed.
--
Peter Jeremy
signature.asc
Description: PGP signature
decides to switch away from
the clock for any reason (eg a burst of jitter), it may get stuck on
the local clock as it drifts further from "real" time.
--
Peter Jeremy
signature.asc
Description: PGP signature
ntry says that it's switched from devd to udev. There's no
mention of evdev or that the keycodes have been roto-tilled. It's basically
a vanilla "things have been changed, see the documentation" entry. Given
that entry, it's hardly surprising that people are confused.
--
Peter Jer
On 2020-Jul-19 14:48:28 +0300, Konstantin Belousov wrote:
>On Sun, Jul 19, 2020 at 09:21:02PM +1000, Peter Jeremy wrote:
>> I'm sending this to -stable, rather than the src groups because I
>> don't believe the problem is the commit itself, rather the commit
>> has uncov
blems.
That said, I notice that the first log file suggests you were building
3 ports in parallel, and each port build was running 3 jobs - that's 9
jobs in parallel on a low-spec CPU with 4 threads. You should limit
the number of CPU-bound processes to the number of CPU threads you have.
[1
uot; messages
generally mean that this number is too low, rather than there being a
shortage of swap - particularly if your swap device is rather slow.
--
Peter Jeremy
signature.asc
Description: PGP signature
Does anyone have any ideas?
--
Peter Jeremy
signature.asc
Description: PGP signature
On 2020-Jul-21 00:47:23 +0300, Konstantin Belousov wrote:
>On Tue, Jul 21, 2020 at 07:20:44AM +1000, Peter Jeremy wrote:
>> On 2020-Jul-19 14:48:28 +0300, Konstantin Belousov
>> wrote:
>> >On Sun, Jul 19, 2020 at 09:21:02PM +1000, Peter Jeremy wrote:
>>
TL;DR: Ensure you explicitly destroy all ZFS labels on disused root pools.
On 2020-Jul-19 21:21:02 +1000, Peter Jeremy wrote:
>I'm sending this to -stable, rather than the src groups because I
>don't believe the problem is the commit itself, rather the commit
>has uncovered a laten
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/servi
din, stdout and stderr are open. Whilst it
probably doesn't make sense to call tail without stdout open. there's
no obvious reason to require that stdin or stderr must be open.
--
Peter Jeremy
signature.asc
Description: PGP signature
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,
e's no
way to change the processes capabilities.
--
Peter Jeremy
signature.asc
Description: PGP signature
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:
&g
-GCM,
it does a reasonable job of roto-tilling the entire armv8crypto stack.
I notice that there are a fixes to f76393a6305b that don't seem to
have made it into releng/13.0 and I will continue to investigate.
--
Peter Jeremy
signature.asc
Description: PGP signature
On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable
wrote:
>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4
>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 -
>RK3399, arm64) has changed so that a geli-encrypted partition (using
>
[Adding arm@ and making it clearer that this is armv8-only]
On 2021-Mar-06 20:26:19 +1100, Peter Jeremy wrote:
>On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable
> wrote:
>>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4
>>(releng/13.0-n244592-
On 2021-Mar-06 10:39:02 -0800, Oleksandr Tymoshenko wrote:
>Peter Jeremy via freebsd-current (freebsd-curr...@freebsd.org) wrote:
>> [Adding arm@ and making it clearer that this is armv8-only]
>>
>> On 2021-Mar-06 20:26:19 +1100, Peter Jeremy
>> wrote:
>> >
a FreeBSD test
system that's running ZFS in <1GB RAM and rebuilding itself daily for
multiple years and haven't run into any ZFS corruption issues.
--
Peter Jeremy
signature.asc
Description: PGP signature
601 - 624 of 624 matches
Mail list logo
